asap asdf calext cbor cellar dispatch dmarc ecrit emailcore extra jmap mailmaint mediaman mimi mlcodec regext satp sipcore sml stir vcon wimse gendispatch 6lo 6man add bpf deleg dhc dmm dnssd dprive drip dtn intarea madinas ntp schc snac tictoc anima bmwg dnsop grow iotops ippm ivy mboned mops netconf netmod nmop opsawg sidrops srv6ops v6ops babel bess bfd bier cats ccamp detnet idr lisp lsr lsvr manet mpls nvo3 pals pce pim rift roll rtgwg savnet spring teas tvr ace acme cose dance dult emu gnap ipsecme jose keytrans kitten lake lamps mls oauth ohai openpgp ppm pquip privacypass radext rats scim scitt secdispatch spice suit teep tls uta avtcore ccwg cdni core httpapi httpbis masque moq nfsv4 quic taps tcpm tsvwg webtrans wish Automatic SIP trunking And Peering (asap) ----------------------------------------- Charter Last Modified: 2022-05-03 Current Status: Active Chairs: Gonzalo Salgueiro Jean Mahoney Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: asap@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/asap Archive: https://mailarchive.ietf.org/arch/browse/asap/ Description of Working Group: The deployment of a Session Initiation Protocol (SIP)-based infrastructure in enterprise and service provider communication networks has been gradually increasing over the last few years. Consequently, direct IP peering between enterprise and service provider networks is replacing traditional methods of interconnection between these networks, such as analog lines and time-division multiplexing (TDM)-based digital circuits. Currently published standards provide a strong foundation over which direct IP peering can be realized. However, given the sheer number of these standards, it is often unclear which behavioural subsets, extensions to baseline protocols and operating principles ought to be configured by the enterprise network administrator to ensure successful IP peering with a SIP service provider network. This lack of context often leads to interoperability issues between enterprise and service provider SIP networks. As a result, a significant amount of time is spent by enterprise network administrators in troubleshooting these interoperability issues individually or with enterprise equipment manufacturer and service provider support teams. Consequently, there is an increase in the time taken to deploy SIP trunking between enterprise and service provider networks. The ASAP working group will define a descriptive capability set, which is populated by a SIP service provider, and which, when communicated to an enterprise network, encapsulates sufficient information to set up SIP trunking with the service provider network. In addition to defining a descriptive capability set, the ASAP working group will define a data model for the capability set, a service discovery mechanism and a transport mechanism for the capability set. The aforementioned deliverables of the ASAP working group are collectively referred to as “SIP Auto Peer”. The scope of the ASAP working group is: * A capability set that encapsulates sufficient information to ensure smooth IP peering between enterprise and service provider SIP networks. * A data model for the capability set. * An HTTPS-based transport mechanism for the capability set. * A mechanism to discover the server(s) in the SIP service provider network that hosts the capability set. * A mechanism to extend the data model to allow the encoding of proprietary parameters. The following are out of scope: * Extensions to SIP that enable an enterprise network to solicit and obtain a descriptive capability set from a SIP service provider. * A workflow/mechanism that allows service providers to directly configure devices in the enterprise network. The group will produce: * Specification for SIP Auto Peer This group will co-ordinate with the SIPCORE working group and the SIPConnect efforts carried out by the SIP Forum. Goals and Milestones: Jun 2021 - SIP Automatic Peering specification submitted for publication to the IESG. Internet-Drafts: - Automatic Peering for SIP Trunks [draft-ietf-asap-sip-auto-peer-12] (41 pages) - The 'sip-trunking-capability' Link Relation Type [draft-ietf-asap-siptrunkingcapability-link-05] (5 pages) - Automatic Peering for SIP Trunks [draft-kinamdar-dispatch-sip-auto-peer-05] (32 pages) Requests for Comments: RFC9409: The 'sip-trunking-capability' Link Relation Type (5 pages) A Semantic Definition Format for Data and Interactions of Things (asdf) ----------------------------------------------------------------------- Charter Last Modified: 2022-05-03 Current Status: Active Chairs: Michael Richardson Niklas Widell Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Francesca Palombini Mailing Lists: General Discussion: asdf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/asdf Archive: https://mailarchive.ietf.org/arch/browse/asdf/ Description of Working Group: ## Background In 2019 One Data Model (OneDM) was started to bring several IoT SDOs and IoT device and platform vendors together under a broad, multi-party liaison agreement, with a goal of arriving at a common set of data and interaction models that describe IoT devices. After some exploratory work this resulted in a successful proposal to create the ASDF WG. As a common language for writing down these models, the Semantic Definition Format went through the IETF process, producing (draft-ietf-asdf-sdf). This SDF Base specification has now reached WG Consensus, to be published. SDF represents these models in JSON, enabling re-use of specification formats such as CDDL (RFC 8610) and the formats proposed at json-schema.org and their tooling, for describing both the SDF format itself and the structure of the data to be modelled in SDF. SDF does not directly address data serialization. Instead, SDF focuses solely on modeling the structure and semantics of the data being exchanged. Consequently, the task of data serialization (including RPC semantics) is delegated to other standards, which are typically established by existing IoT SDOs. ## The ASDF Working Group The ASDF WG has developed SDF into a standards-track specification for thing interaction and data modeling. In the process of developing this specification, further functional requirements have emerged that can be addressed as extensions to the base SDF specification. The ASDF WG will liaise with OneDM and other relevant organizations. ASDF will extend SDF to cover the following standard track extensions: * modeling of links and relationships between elements of models, * modeling of non-affordance attribute (e.g., location) information/interaction for digital twins where the corresponding physical objects can be described with SDF, * additional SDF modeling mechanisms to enable property mapping between additional IoT SDOs' objects (including instances, and types), and * information/interaction modeling and protocol mappings to enable gateway interactions between IP and non-IP transports, with draft-brinckman-nipc-00 as a starting point. To increase ease of use, ASDF WG will also complete work on the proposal for a Compact Notation for SDF. As work evolves, ASDF will observe and may want to interact with IRTF Research Groups such as the Usable Formal Methods Research Group (UFMRG). ASDF will work with Thing-to-Thing Research Group (T2TRG) and its WISHI (Work on IoT Semantic/Hypermedia Interoperability, https://wishi.space) program to engage researchers and other SDOs in this space, such as W3C Web of Things, which is working on Thing Models and related specifications. Goals and Milestones: Sep 2024 - Submit to the IESG a standards track extension to SDF to describe sdfTyped links. Nov 2024 - Submit to the IESG a standards track extension to SDF to describe relationships between elements of models (beyond sdfRef). Jan 2025 - Submit to the IESG a standards track document on Compact Notation for SDF. May 2025 - Submit to the IESG a standards track specification on how to use SDF to communicate over IP with non-IP based devices. Aug 2025 - Submit to the IESG a standards track extension which allows for industry specific attributes to be associated with a common SDF model. Aug 2025 - Submit to the IESG a standards track specification on describing instances that are based on SDF models. Sep 2025 - Submit to the IESG a standards track extension to SDF to allow for inclusion of physical information and other non-affordance attribute information/interactions as an SDF attribute (e.g., to provide modeling support for digital twins). Internet-Drafts: - Semantic Definition Format (SDF) for Data and Interactions of Things: Compact Notation [draft-bormann-asdf-sdf-compact-06] (8 pages) - Semantic Definition Format (SDF): Mapping files [draft-bormann-asdf-sdf-mapping-04] (11 pages) - An sdfType for Links [draft-bormann-asdf-sdftype-link-03] (5 pages) - An Application Layer Interface for Non-IP device control (NIPC) [draft-brinckman-nipc-01] (109 pages) - An Application Layer Interface for Non-IP device control (NIPC) [draft-ietf-asdf-nipc-01] (101 pages) - Semantic Definition Format (SDF) for Data and Interactions of Things [draft-ietf-asdf-sdf-18] (103 pages) - Extended information of Semantic Definition Format (SDF) for Digital Twin [draft-lee-asdf-digital-twin-03] (12 pages) - Semantic Definition Format (SDF) for Data and Interactions of Things [draft-onedm-t2trg-sdf-00] (51 pages) No Requests for Comments Calendaring Extensions (calext) ------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Bron Gondwana Daniel Migault Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Orie Steele Mailing Lists: General Discussion: calsify@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/calsify Archive: https://mailarchive.ietf.org/arch/browse/calsify/ Description of Working Group: The CALEXT working group is chartered to maintain and extend the specifications for formats and protocols related to calendaring and contacts within the IETF, starting from the basis of: - CalDAV (RFC 4791) - iCalendar (RFC 5545) - iTIP (RFC 5546) - iMIP (RFC 6047) - VCARD (RFC 6350) - CardDAV (RFC 6352) - JSCalendar (RFC 8984) - JSContact (draft-ietf-jmap-jscontact) and the many existing extensions and companion documents to these. This working group is envisaged to be long-running, and deal with a steady flow of changes. Experience has shown that these specifications are still seeing significant need for updates, as new use-cases are identified and user requirements change. This working group will do the following: - maintain existing standards and proposed standards, processing errata and refreshing them as required - evaluate and develop extensions to the existing standards to provide for new use-cases where there is demand - generate documents describing existing vendor extensions which are in common usage, and likely to be encountered in the wild. The working group will work under the following parameters: - The extensions developed are expected to be backwards-compatible with the existing standards. Incompatibilities must be identified, minimized, and justified. - Any extensions to icalendar or jscalendar must include a representation in both formats, and define a robust mapping between them. - Any extensions to vcard or jscontact must include a representation in both formats, and define a robust mapping between them. - All calendar extensions must examine their impact on the iTIP protocol (RFC 5546), and define any necessary extensions to iTIP to accommodate such impact. The working group will maintain relationships with other working groups: - HTTPBIS and HTTPAPI: when extending the CalDAV or CardDAV protocols to ensure that changes are consistent with good http practices. - JMAP: when making updates to JSCalendar and JSContact to ensure that the changes are compatible with the JMAP methods for managing data in these formats. - EXTRA, DMARC and EMAILCORE: for changes related to iTIP delivery via email. - TZDIST and SEDATE for date, time, and timezone related issues. - Other IETF working groups as appropriate, when their work interacts with ours. - Other standards organisations like CalConnect and M3AAWG that are doing work in the same fields. The following are out of scope for the working group: - Any attempt to develop non-Gregorian calendar systems/calculations. - Work which is in scope for any other ART area working group, and better suited to that group. - Work which is unrelated to anything that this group is currently maintaining. Goals and Milestones: Apr 2024 - Submit subscription upgrade document to IESG Apr 2024 - Submit task draft to IESG Jul 2024 - Submit vpoll document to IESG for publication Nov 2024 - Submit JSCalendar mapping document to IESG for publication Nov 2024 - Submit calendar series document to IESG for publication Done - Submit JSON Contact document to IESG on hold - Adopt a draft updating iTIP Internet-Drafts: - Calendar Availability [draft-daboo-calendar-availability-05] (22 pages) - New Properties for iCalendar [draft-daboo-icalendar-extensions-09] (21 pages) - Non-Gregorian Recurrence Rules in iCalendar [draft-daboo-icalendar-rscale-04] (15 pages) - Calendar Availability [draft-ietf-calext-availability-04] (24 pages) - Calendaring Extensions to WebDAV (CalDAV): Managed Attachments [draft-ietf-calext-caldav-attachments-04] (34 pages) - CalDAV Extension for scheduling controls [draft-ietf-calext-caldav-scheduling-controls-00] (6 pages) - Event Publishing Extensions to iCalendar [draft-ietf-calext-eventpub-extensions-19] (29 pages) - New Properties for iCalendar [draft-ietf-calext-extensions-05] (23 pages) - iCalendar Format Extension for JSCalendar [draft-ietf-calext-icalendar-jscalendar-extensions-00] (9 pages) - Support for Series in iCalendar [draft-ietf-calext-icalendar-series-03] (28 pages) - Support for iCalendar Relationships [draft-ietf-calext-ical-relations-11] (19 pages) - Task Extensions to iCalendar [draft-ietf-calext-ical-tasks-10] (33 pages) - JSCalendar: A JSON Representation of Calendar Data [draft-ietf-calext-jscalendar-32] (73 pages) - JSCalendar: A JSON Representation of Calendar Data [draft-ietf-calext-jscalendarbis-01] (88 pages) - JSCalendar: Converting from and to iCalendar [draft-ietf-calext-jscalendar-icalendar-07] (67 pages) - JSContact: A JSON representation of contact data [draft-ietf-calext-jscontact-17] (87 pages) - JSContact: Converting from and to vCard [draft-ietf-calext-jscontact-vcard-15] (65 pages) - Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar) [draft-ietf-calext-rscale-04] (21 pages) - Serverside Subscriptions [draft-ietf-calext-serverside-subscriptions-02] (11 pages) - Calendar subscription upgrades [draft-ietf-calext-subscription-upgrade-11] (15 pages) - "VALARM" Extensions for iCalendar [draft-ietf-calext-valarm-extensions-07] (18 pages) - vCard Format Extension for JSContact [draft-ietf-calext-vcard-jscontact-extensions-12] (22 pages) - VPOLL: Consensus Scheduling Component for iCalendar [draft-ietf-calext-vpoll-06] (61 pages) - JSContact: A JSON representation of contact data [draft-ietf-jmap-jscontact-10] (26 pages) - JSContact: Converting from and to vCard [draft-ietf-jmap-jscontact-vcard-09] (41 pages) - JSCalendar: A JSON representation of calendar data [draft-jenkins-jscalendar-05] (51 pages) Requests for Comments: RFC7529: Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar) (21 pages) RFC7953: Calendar Availability (24 pages) RFC7986: New Properties for iCalendar (23 pages) RFC8607: Calendaring Extensions to WebDAV (CalDAV): Managed Attachments (34 pages) RFC8984: JSCalendar: A JSON Representation of Calendar Data (73 pages) RFC9073: Event Publishing Extensions to iCalendar (29 pages) RFC9074: "VALARM" Extensions for iCalendar (18 pages) RFC9253: Support for iCalendar Relationships (19 pages) RFC9553: JSContact: A JSON Representation of Contact Data (73 pages) RFC9554: vCard Format Extensions for JSContact (21 pages) RFC9555: JSContact: Converting from and to vCard (60 pages) Concise Binary Object Representation Maintenance and Extensions (cbor) ---------------------------------------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Barry Leiba Christian Amsüss Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Orie Steele Mailing Lists: General Discussion: cbor@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cbor Archive: https://www.ietf.org/mail-archive/web/cbor/current/maillist.html Description of Working Group: Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript Object Notation (JSON, RFC 8259) data interchange format to include binary data and an extensibility model, using a binary representation format that is easy to parse correctly. It has been picked up by a number of IETF efforts (e.g., CORE, ANIMA GRASP) as a message format. The CBOR working group has updated RFC 7049 to deal with existing errata, and the new version, draft-ietf-cbor-7049bis, is in the RFC Editor queue to become an Internet Standard. Similar to the way ABNF (RFC 5234/7405) can be used to describe the set of valid messages in a text representation, it is useful for protocol specifications to use a description format for the data in CBOR-encoded messages. The Concise Data Definition Language (CDDL) is such a description technique that has already been used in CORE, ANIMA, CDNI, and efforts outside the IETF. CDDL has been published as RFC 8610. While this specification has been completed, several new features were raised during the update process that were not included, in order not to delay publication, and to allow publication in the Standards Track. One example of such a feature is the ability to combine multiple CDDL files together using a mechanism other than manually concatenating them together for processing. The working group will collect these features as well as other features that are raised by users of CDDL, evaluate their utility and, where warranted, progress them either in a standalone document or as part of a new edition of the specification. The working group will define the approach to further evolving CDDL as a sequence of editions, which might also add further extension points, probably as part of the introduction of the next edition of the CDDL base specification. The body of existing specifications that make use of CDDL is considered precious, and the WG will set out not to damage their value. The working group will evaluate the necessity of providing advice and guidance for developers using CBOR and CDDL. It is currently expected that this would be done using a Wiki of some type. This work would not be expected to be published by the IETF as an RFC. There are a number of additional CBOR tagged types and CBOR related media type specifications that are currently adopted by the working group, are work items in other working groups, or exist as individual submissions. Additionally, there are expected to be other such documents that will come to the attention of the working group. In some cases, the working group expects to adopt and publish these proposals, and for those the working group will evaluate them individually and decide about adoption and milestones. Proposals that are deemed to be out of scope for the working group, for example because they are too narrow in purpose, may still be published as individual submissions or in another groups if there is a specific need. The CBOR group will review these proposals on request. Goals and Milestones: Jun 2027 - Updated version of CDDL, replacing RFC 8610 and its updates, submitted to IESG Internet-Drafts: - Additional Control Operators for CDDL [draft-bormann-cbor-cddl-control-02] (10 pages) - CDDL Module Structure [draft-bormann-cbor-cddl-modules-00] (12 pages) - More Control Operators for CDDL [draft-bormann-cbor-cddl-more-control-01] (11 pages) - CBOR Common Deterministic Encoding (CDE) [draft-bormann-cbor-cde-00] (9 pages) - Application-Oriented Literals in CBOR Extended Diagnostic Notation [draft-bormann-cbor-edn-literals-02] (8 pages) - External References to Values in CBOR Diagnostic Notation (EDN) [draft-bormann-cbor-e-ref-00] (9 pages) - Packed CBOR [draft-bormann-cbor-packed-01] (9 pages) - Concise Binary Object Representation (CBOR) Tags for Object Identifiers [draft-bormann-cbor-tags-oid-07] (14 pages) - Concise Binary Object Representation (CBOR) Tags for Time, Duration, and Period [draft-bormann-cbor-time-tag-04] (11 pages) - Updates to the CDDL grammar of RFC 8610 [draft-bormann-cbor-update-8610-grammar-00] (12 pages) - Concise Binary Object Representation (CBOR) [draft-ietf-cbor-7049bis-16] (66 pages) - Concise Binary Object Representation (CBOR) Tags for Typed Arrays [draft-ietf-cbor-array-tags-08] (13 pages) - Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures [draft-ietf-cbor-cddl-08] (64 pages) - Additional Control Operators for the Concise Data Definition Language (CDDL) [draft-ietf-cbor-cddl-control-07] (11 pages) - CDDL Module Structure [draft-ietf-cbor-cddl-modules-03] (14 pages) - More Control Operators for CDDL [draft-ietf-cbor-cddl-more-control-06] (13 pages) - CBOR Common Deterministic Encoding (CDE) [draft-ietf-cbor-cde-05] (15 pages) - Concise Binary Object Representation (CBOR) Tags for Date [draft-ietf-cbor-date-tag-07] (6 pages) - External References to Values in CBOR Diagnostic Notation (EDN) [draft-ietf-cbor-edn-e-ref-00] (10 pages) - CBOR Extended Diagnostic Notation (EDN) [draft-ietf-cbor-edn-literals-12] (42 pages) - On Stable Storage for Items in Concise Binary Object Representation (CBOR) [draft-ietf-cbor-file-magic-12] (18 pages) - Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes [draft-ietf-cbor-network-addresses-13] (10 pages) - Packed CBOR [draft-ietf-cbor-packed-13] (30 pages) - Concise Binary Object Representation (CBOR) Sequences [draft-ietf-cbor-sequence-02] (10 pages) - Concise Binary Object Representation (CBOR) Tags for Object Identifiers [draft-ietf-cbor-tags-oid-08] (13 pages) - Concise Binary Object Representation (CBOR) Tags for Time, Duration, and Period [draft-ietf-cbor-time-tag-12] (24 pages) - Updates to the CDDL grammar of RFC 8610 [draft-ietf-cbor-update-8610-grammar-06] (15 pages) - Concise Binary Object Representation (CBOR) Tags for Date [draft-jones-cbor-date-tag-01] (5 pages) - On storing CBOR encoded items on stable storage [draft-richardson-cbor-file-magic-01] (5 pages) - CBOR tags for IPv4 and IPv6 addresses and prefixes [draft-richardson-cbor-network-addresses-01] (4 pages) Requests for Comments: RFC8610: Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures (64 pages) RFC8742: Concise Binary Object Representation (CBOR) Sequences (10 pages) RFC8746: Concise Binary Object Representation (CBOR) Tags for Typed Arrays (13 pages) RFC8943: Concise Binary Object Representation (CBOR) Tags for Date (6 pages) RFC8949: Concise Binary Object Representation (CBOR) (66 pages) RFC9090: Concise Binary Object Representation (CBOR) Tags for Object Identifiers (13 pages) RFC9164: Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes (10 pages) RFC9165: Additional Control Operators for the Concise Data Definition Language (CDDL) (11 pages) RFC9277: On Stable Storage for Items in Concise Binary Object Representation (CBOR) (18 pages) RFC9581: Concise Binary Object Representation (CBOR) Tags for Time, Duration, and Period (21 pages) Codec Encoding for LossLess Archiving and Realtime transmission (cellar) ------------------------------------------------------------------------ Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Michael Richardson Spencer Dawkins Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Orie Steele Mailing Lists: General Discussion: cellar@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cellar Archive: https://mailarchive.ietf.org/arch/browse/cellar/ Description of Working Group: The preservation of audiovisual materials faces challenges from technological obsolescence, analog media deterioration, and the use of proprietary formats that lack formal open standards. While obsolescence and material degradation are widely addressed, the standardization of open, transparent, self-descriptive, lossless formats remains an important mission to be undertaken by the open source community. FFV1 is a lossless video codec and Matroska is an extensible media container based on EBML (Extensible Binary Meta Language), a binary XML format. There are open source implementations of both formats, and an increasing interest in and support for use of FFV1 and Matroska. However, there are concerns about the sustainability and credibility of existing specifications for the long-term use of these formats. These existing specifications require broader review and formalization in order to encourage widespread adoption. There is also a need for a lossless audio format to complement the lossless video codec and container format. FLAC is a lossless audio codec that has seen widespread adoption in a number of different applications including archival applications. While there are open source implementations of the codec, no formal standards for either the codec itself or its use in container formats currently exist. Review and formalization of the FLAC codec standard and its use in Matroska container formats is needed for wider adoption. Using existing work done by the development communities of Matroska, FFV1, and FLAC, the Working Group will formalize specifications for these open and lossless formats. In order to provide authoritative, standardized specifications for users and developers, the Working Group will seek consensus throughout the process of refining and formalizing these standards. Initial specifications can be accessed here: Specifications: - FFV1: https://mediaarea.net/temp/ffv1.html - Matroska: http://matroska.org/technical/specs/index.html - EBML: http://matroska-org.github.io/libebml/specs.html - FLAC: https://xiph.org/flac/format.html Development Versions: - FFV1: https://github.com/ffmpeg/ffv1 - Matroska: https://github.com/Matroska-Org/foundation-source/blob/master/spectool/specdata.xml - EBML: https://github.com/Matroska-Org/ebml-specification The Working Group will seek consensus and refinements for specifications for both FFV1 and Matroska in order to provide authoritative, standardized specifications for users and developers. Backward compatibility with existing versions 0-3 of the FFV1 and Matroska specifications will be an important goal, while also reviewing and refining the current version 4 under active development. Although not encouraged, non-backwards-compatible changes to the input specifications will be acceptable if the Working Group determines that the modifications are required to meet the group's technical objectives, provided that the reasons for these changes are clearly documented. Deliverables: - Informational specification for Matroska container format versions 1, 2 and 3 to IESG for publication - Standards Track specification for Matroska container format version 4 to IESG for publication - Informational specification for FFV1 video codec versions 0, 1 and 3 to IESG for publication - Standards Track specification for FFV1 video codec version 4 to IESG for publication - Standards Track specification for FLAC audio codec to IESG for publication Goals and Milestones: Jul 2022 - Submit specification for FFV1 video codec version 4 to IESG (Standards Track) Dec 2024 - Submit Matroska Media Container Tag Specifications to IESG (Standards Track) Jun 2025 - Submit specification for Matroska Media Container Codec Specifications to IESG (Standards Track) Done - Adopt matroska specifications as WG documents Done - Adopt matroska specifications as WG documents Done - Submit specification for EBML to IESG (Standards Track) Done - Submit informational specification for FFV1 video codec versions 0, 1 and 3 to IESG for publication Done - Submit specification for Matroska container to IESG (Standards Track) Done - Submit specification for FLAC audio codec to IESG (Standards Track) Internet-Drafts: - Matroska Media Container Chapter Codecs Specifications [draft-ietf-cellar-chapter-codecs-05] (8 pages) - Matroska Media Container Codec Specifications [draft-ietf-cellar-codec-13] (56 pages) - Matroska Media Container Control Track Specifications [draft-ietf-cellar-control-05] (10 pages) - Extensible Binary Meta Language [draft-ietf-cellar-ebml-17] (51 pages) - FFV1 Video Coding Format Versions 0, 1, and 3 [draft-ietf-cellar-ffv1-20] (51 pages) - FFV1 Video Coding Format Version 4 [draft-ietf-cellar-ffv1-v4-22] (57 pages) - Free Lossless Audio Codec [draft-ietf-cellar-flac-14] (96 pages) - Matroska Media Container Format Specification [draft-ietf-cellar-matroska-23] (179 pages) - Matroska Media Container Tag Specifications [draft-ietf-cellar-tags-13] (30 pages) - FF Video Codec 1 [draft-niedermayer-cellar-ffv1-02] (36 pages) - Free Lossless Audio Codec [draft-weaver-cellar-flac-00] (31 pages) Requests for Comments: RFC8794: Extensible Binary Meta Language (51 pages) RFC9043: FFV1 Video Coding Format Versions 0, 1, and 3 (51 pages) Dispatch (dispatch) ------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Jim Fenton Shuping Peng Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: dispatch@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dispatch Archive: https://mailarchive.ietf.org/arch/browse/dispatch/ Description of Working Group: The Dispatch working group is chartered to consider proposals for new work in the ART area and identify, or help create, an appropriate venue for the work. Guiding principles for the proposed new work include: 1. Providing a clear problem statement, motivation and deliverables for the proposed new work. 2. Ensuring there has been adequate mailing list discussion reflecting sufficient interest, individuals have expressed a willingness to contribute and there is WG consensus before new work is dispatched. 3. Looking for and identifying commonalities and overlap amongst published or ongoing protocol work. Such commonalities may indicate the possibility of reusing existing protocols or elements thereof published by other WGs, or expanding and/or refactoring the scope of deliverables in an active WG. 4. Protecting the architectural integrity of IETF protocols and ensuring that new work has general applicability. 5. Ensuring that the new work considers and seeks to improve security and privacy. Options for handling new work include: - Directing the work to an existing WG. - Developing a proposal for a BOF. - Developing a charter for a new WG. - Making recommendations that documents be AD-sponsored (which ADs may or may not choose to follow). - By agreement with ART ADs, processing simple administrative documents. - Deferring the decision for the new work. - Rejecting the new work. If the group decides that a particular topic needs to be addressed by a new WG, the normal IETF chartering process will be followed, including, for instance, IETF-wide review of the proposed charter. Proposals for large work efforts SHOULD lead to a BOF where the topic can be discussed in front of the entire IETF community. The DISPATCH WG will not do any protocol work. Specifically, DISPATCH will always opt to find a location for technical work; the only work that DISPATCH is not required to delegate (or defer, or reject) is administrative work such as IANA actions. Documents progressed as AD-sponsored would typically include those that do not have general applicability to IETF protocols, but rather are only applicable to specific use cases and network deployments, for which the scope must be clearly specified. Proposed new work may be deferred in cases where the WG does not have enough information for the chairs to determine consensus. New work may be rejected in cases where there is not sufficient WG interest or the proposal has been considered and rejected in the past, unless a substantially revised proposal is put forth, including compelling new reasons for accepting the work. A major objective of the DISPATCH WG is to provide timely, clear dispositions of new efforts. Thus, where there is consensus to take on new work, the WG will strive to quickly find a home for it. While most new work in the ART area is expected to be considered in the DISPATCH working group, there may be times where that is not appropriate. At the discretion of the area directors, new efforts may follow other paths. For example work may go directly to BoFs, may be initiated in other working groups when it clearly belongs in that group, or may be directly AD sponsored. Goals and Milestones: Internet-Drafts: - Updates to ECMAScript Media Types [draft-ietf-dispatch-javascript-mjs-17] (13 pages) Requests for Comments: RFC9239: Updates to ECMAScript Media Types (13 pages) Domain-based Message Authentication, Reporting & Conformance (dmarc) -------------------------------------------------------------------- Charter Last Modified: 2023-07-25 Current Status: Active Chairs: Barry Leiba Seth Blank Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: dmarc@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dmarc Archive: https://mailarchive.ietf.org/arch/browse/dmarc/ Description of Working Group: Domain-based Message Authentication, Reporting & Conformance (DMARC) uses existing mail authentication technologies (SPF and DKIM) to extend validation to the RFC5322.From field. DMARC uses DNS records to add policy-related requests for receivers and defines a feedback mechanism from receivers back to domain owners. This allows a domain owner to advertise that mail can safely receive differential handling, such as rejection, when the use of the domain name in the From field is not authenticated. Existing deployment of DMARC has demonstrated utility at internet scale, in dealing with significant email abuse, and has permitted simplifying some mail handling processes. However, DMARC is problematic for mail that does not flow from operators having a relationship with the domain owner, directly to receivers operating the destination mailbox (for example, mailing lists, publish-to-friend functionality, mailbox forwarding via ".forward", and third-party services that send on behalf of clients). The working group will explore possible updates and extensions to the specifications in order to address limitations and/or add capabilities. It will also provide technical implementation guidance and review possible enhancements elsewhere in the mail handling sequence that could improve DMARC compatibility. The existing DMARC base specification is published as Informational RFC 7489 in the Independent Stream. Specifications produced by the working group will ensure preservation of DMARC utility for detecting unauthorized use of domain names, while improving the identification of legitimate sources that do not currently conform to DMARC requirements. Issues based on operational experience and/or data aggregated from multiple sources will be given priority. The working group will seek to preserve interoperability with the installed base of DMARC systems, and provide detailed justification for any non-interoperability. As the working group develops solutions to deal with indirect mail flows, it will seek to maintain the end-to-end nature of existing identifier fields in mail, in particular avoiding solutions that require rewriting of originator fields. Working group activities will pursue four tracks: 1. Addressing the issues with indirect mail flows The working group will specify mechanisms for reducing or eliminating the DMARC's effects on indirect mail flows, including deployed behaviors of many different intermediaries, such as mailing list managers, automated mailbox forwarding services, and MTAs that perform enhanced message handling that results in message modification. Among the choices for addressing these issues are: - A form of DKIM signature that is better able to survive transit through intermediaries. - Collaborative or passive transitive mechanisms that enable an intermediary to participate in the trust sequence, propagating authentication directly or reporting its results. - Message modification by an intermediary, to avoid authentication failures, such as by using specified conventions for changing the aligned identity. Consideration also will be given to survivable authentication through sequences of multiple intermediaries. 2. Reviewing and improving the base DMARC specification The working group will not develop additional mail authentication technologies, but may document desirable uses of existing authentication technologies. The base specification relies on the ability of an email receiver to determine the organizational domain responsible for sending mail. An organizational domain is the 'base' name that is allocated from a public registry; examples of registries include ".com" or ".co.uk". While the common practice is to use a "public suffix" list to determine organizational domain, it is widely recognized that this solution will not scale, and that the current list often is inaccurate. The task of defining a standard mechanism for identifying organizational domain is out of scope for this working group. However the working group can consider extending the base DMARC specification to accommodate such a standard, should it be developed during the life of this working group. Improvements in DMARC features (identifier alignment, reporting, policy preferences) will be considered, such as: - Enumeration of data elements required in "Failure" reports (specifically to address privacy issues) - Handling potential reporting abuse - Aggregate reporting to support additional reporting scenarios - Alternate reporting channels - Utility of arbitrary identifier alignment - Utility of a formalized policy exception mechanism 3. DMARC Usage The working group will document operational practices in terms of configuration, installation, monitoring, diagnosis and reporting. It will catalog currently prevailing guidelines as well as developing advice on practices that are not yet well-established but which are believed to be appropriate. The group will consider separating configuration and other deployment information that needs to be in the base spec, from information that should be in a separate guide. Among the topics anticipated to be included in the document are: - Identifier alignment configuration options - Implementation decisions regarding "pct" - Determining effective RUA sending frequency - Leveraging policy caching - Various options for integrating within an existing flow - Defining a useful, common set of options for the addresses to which feedback reports are to be sent - When and how to use local policy override options 4. Related work Extensions to SPF/DKIM/DMARC that do not already fit under the charter of any existing working group can be considered for adoption by DMARC Working Group after consultation with the responsible AD. A prime example is draft-levine-appsarea-eaiauth, which provides EAI-related updates to DMARC and the protocols upon which it depends. Any such work needs to carefully consider interoperability implications. Work Items ---------- Phase I: Draft description of interoperability issues for indirect mail flows and plausible methods for reducing them. This is now complete and published as RFC 7960. Phase II: Specification of DMARC improvements to support indirect mail flows; this is now complete as draft-ietf-dmarc-arc-protocol (ARC). Draft Guide on DMARC Usage. Phase III: Review and refinement of the DMARC specification. Completion of Guide on DMARC and ARC Usage. References ---------- DMARC - http://dmarc.org SPF - RFC7208 Authentication-Results Header Field - RFC7001 DKIM - RFC6376 Internet Message Format - RFC5322 OAR / Original Authentication Results - draft-kucherawy-original-authres Using DMARC - draft-crocker-dmarc-bcp-03 Delegating DKIM Signing Authority - draft-kucherawy-dkim-delegate-00 DKIM Third-Party Authorization Label - draft-otis-dkim-tpa-label-03 Goals and Milestones: Done - Complete Authenticated Received Chain (ARC) protocol spec Internet-Drafts: - DMARC Use of the RFC5322.Sender Header Field [draft-crocker-dmarc-sender-01] (8 pages) - Interoperability Issues Between DMARC and Indirect Email Flows [draft-dmarc-interoperability-00] (16 pages) - Domain-based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting [draft-ietf-dmarc-aggregate-reporting-19] (29 pages) - Using Multiple Signing Algorithms with the ARC (Authenticated Received Chain) Protocol [draft-ietf-dmarc-arc-multi-03] (6 pages) - The Authenticated Received Chain (ARC) Protocol [draft-ietf-dmarc-arc-protocol-23] (35 pages) - Recommended Usage of the Authenticated Received Chain (ARC) [draft-ietf-dmarc-arc-usage-09] (19 pages) - Domain-based Message Authentication, Reporting, and Conformance (DMARC) [draft-ietf-dmarc-dmarcbis-33] (77 pages) - Email Authentication for Internationalized Mail [draft-ietf-dmarc-eaiauth-06] (6 pages) - Domain-based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting [draft-ietf-dmarc-failure-reporting-11] (14 pages) - Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows [draft-ietf-dmarc-interoperability-18] (27 pages) - Experimental Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Extension for Public Suffix Domains [draft-ietf-dmarc-psd-15] (14 pages) - Message Header Field for Indicating Message Authentication Status [draft-ietf-dmarc-rfc7601bis-06] (54 pages) - DMARC Use of the RFC5322.Sender Header Field [draft-ietf-dmarc-sender-00] (8 pages) Requests for Comments: RFC7960: Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows (27 pages) RFC8601: Message Header Field for Indicating Message Authentication Status (54 pages) RFC8616: Email Authentication for Internationalized Mail (6 pages) RFC8617: The Authenticated Received Chain (ARC) Protocol (35 pages) RFC9091: Experimental Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Extension for Public Suffix Domains (14 pages) Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- Charter Last Modified: 2023-09-08 Current Status: Active Chairs: Allison Mankin Randall Gellens Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: ecrit@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ecrit Archive: https://mailarchive.ietf.org/arch/browse/ecrit/ Description of Working Group: In a number of areas, the public switched telephone network (PSTN) has been configured to recognize an explicitly specified number (usually one that is short and easily memorized) as a request for emergency services. These numbers (e.g., 911, 112) are related to an emergency service context and depend on a broad, regional configuration of service contact methods and a geographically-constrained approach for service delivery. These calls are intended to be delivered to special call centers equipped to manage emergency response. Successful delivery of an emergency service call within those systems requires an association of both the physical location of the originating device along with appropriate call routing to an emergency service center. Calls placed using Internet technologies do not use the same systems mentioned above to achieve those same goals, and the common use of overlay networks and tunnels (either as VPNs or for mobility) makes meeting these goals even more challenging. There are, however, Internet technologies available to manage location and to perform call routing. This working group has described where and how these mechanisms may be used. The group specified how location data and call routing information are used to enable communication between a user and a relevant emergency response center [RFC6443,RFC6444]. Though the term "call routing" is used, it should be understood that some of the mechanisms described might be used to enable other types of media streams. Beyond human initiated emergency call request mechanisms, this group will develop new methods to enable non-human-initiated requests for emergency assistance, such as sensor initiated emergency requests. The working group will also address topics required for the operation of emergency calling systems, such as: authentication of location, management of the service URN namespace, augmented information that could assist emergency call takers or responders. Explicitly outside the scope of this group is the question of pre- emption or prioritization of emergency services traffic in the network. This group is considering emergency services calls which might be made by any user of the Internet, as opposed to government or military services that may impose very different authentication and routing requirements. While this group anticipates a close working relationship with groups such as NENA, EENA, 3GPP, and ETSI , any solution presented must be general enough to be potentially useful in or across multiple regions or jurisdictions, and it must be possible to use without requiring a single, central authority. Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, things such as call routing for specific emergency types, media types, language contents, etc., may be routed differently depending on established policies and availability. This working group will address privacy and security concerns within its documents. Goals and Milestones: Nov 2022 - Submit 'Validation of Locations Around a Planned Change' to the IESG for consideration as a Standards Track RFC Done - An Informational document describing the threats and security considerations Done - A Standards Track RFC describing how to identify a session set-up request is to an emergency response center Done - Informational RFC containing terminology definitions and the requirements Done - An Informational document describing the Mapping Protocol Architecture Done - A Standards Track RFC describing how to route an emergency call based on location information Done - Submit 'Location Hiding: Problem Statement and Requirements' to the IESG for consideration as an Informational RFC. Done - Submit 'Best Current Practice for Communications Services in support of Emergency Calling' to the IESG for consideration as a BCP document Done - Submit 'Framework for Emergency Calling using Internet Multimedia' to the IESG for consideration as an Informational RFC. Done - Submit 'LoST Extension for returning Boundary Information for Services' to the IESG for consideration as an Experimental RFC Done - Submit 'Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements' to the IESG for consideration as an Experimental RFC Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG for consideration as an Informational RFC Done - Submit 'Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices' to the IESG for consideration as a Standards Track RFC Done - Submit 'Trustworthy Location Information' to the IESG for consideration as an Informational RFC Done - Submit a draft 'URN For Country Specific Emergency Services' to the IESG for consideration as a Standards Track RFC Done - Submit 'A Routing Request Extension for the HELD Protocol' to the IESG for consideration as a Standards Track RFC Done - Submit 'Additional Data related to a Call for Emergency Call Purposes' to the IESG for consideration as a Standards Track RFC Done - Submit ‘Internet Protocol-based In-Vehicle Emergency Calls‘ to the IESG for consideration as an Informational RFC Done - Submit ‘Next-Generation Pan-European eCall‘ to the IESG for consideration as an Informational RFC Done - Submit ‘A LoST extension to return complete and similar location info‘ to the IESG for consideration as an Informational RFC Done - Submit 'Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG for consideration as an Experimental RFC Internet-Drafts: - Validation of Locations Around a Planned Change [draft-ecrit-lost-planned-changes-00] (10 pages) - Additional Data Related to an Emergency Call [draft-ietf-ecrit-additional-data-38] (113 pages) - Next-Generation Vehicle-Initiated Emergency Calls [draft-ietf-ecrit-car-crash-23] (40 pages) - URN for Country-Specific Emergency Services [draft-ietf-ecrit-country-emg-urn-03] (4 pages) - Non-interactive Emergency Calls [draft-ietf-ecrit-data-only-ea-22] (25 pages) - Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP) [draft-ietf-ecrit-dhc-lost-discovery-03] (8 pages) - Next-Generation Pan-European eCall [draft-ietf-ecrit-ecall-27] (43 pages) - Framework for Emergency Calling Using Internet Multimedia [draft-ietf-ecrit-framework-13] (38 pages) - A Routing Request Extension for the HTTP-Enabled Location Delivery (HELD) Protocol [draft-ietf-ecrit-held-routing-05] (16 pages) - IANA Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications [draft-ietf-ecrit-local-emergency-rph-namespace-04] (8 pages) - Location Hiding: Problem Statement and Requirements [draft-ietf-ecrit-location-hiding-req-04] (9 pages) - Changing the Location-to-Service Translation (LoST) Location Profiles Registry Policy [draft-ietf-ecrit-location-profile-registry-policy-02] (4 pages) - LoST: A Location-to-Service Translation Protocol [draft-ietf-ecrit-lost-10] (69 pages) - Validation of Locations Around a Planned Change [draft-ietf-ecrit-lost-planned-changes-09] (21 pages) - Location-to-Service Translation (LoST) Service List Boundary Extension [draft-ietf-ecrit-lost-servicelistboundary-05] (15 pages) - Synchronizing Service Boundaries and Elements Based on the Location-to-Service Translation (LoST) Protocol [draft-ietf-ecrit-lost-sync-18] (25 pages) - Location-to-URL Mapping Architecture and Framework [draft-ietf-ecrit-mapping-arch-04] (17 pages) - Best Current Practice for Communications Services in Support of Emergency Calling [draft-ietf-ecrit-phonebcp-20] (28 pages) - Public Safety Answering Point (PSAP) Callback [draft-ietf-ecrit-psap-callback-13] (18 pages) - Requirements for Emergency Context Resolution with Internet Technologies [draft-ietf-ecrit-requirements-13] (23 pages) - Using Imprecise Location for Emergency Context Resolution [draft-ietf-ecrit-rough-loc-05] (19 pages) - Security Threats and Requirements for Emergency Call Marking and Mapping [draft-ietf-ecrit-security-threats-05] (12 pages) - A Uniform Resource Name (URN) for Emergency and Other Well-Known Services [draft-ietf-ecrit-service-urn-07] (14 pages) - Policy for defining new service-identifying labels [draft-ietf-ecrit-service-urn-policy-04] (4 pages) - A LoST extension to return complete and similar location info [draft-ietf-ecrit-similar-location-19] (19 pages) - Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries [draft-ietf-ecrit-specifying-holes-03] (11 pages) - Trustworthy Location [draft-ietf-ecrit-trustworthy-location-14] (31 pages) - Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices [draft-ietf-ecrit-unauthenticated-access-10] (25 pages) - Emergency Registries [draft-rosen-ecrit-emergency-registries-01] (53 pages) Requests for Comments: RFC5012: Requirements for Emergency Context Resolution with Internet Technologies (23 pages) RFC5031: A Uniform Resource Name (URN) for Emergency and Other Well-Known Services (14 pages) * Updates RFC7163 RFC5069: Security Threats and Requirements for Emergency Call Marking and Mapping (12 pages) RFC5222: LoST: A Location-to-Service Translation Protocol (69 pages) * Updates RFC6848 * Updates RFC8917 * Updates RFC9036 RFC5223: Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP) (8 pages) RFC5582: Location-to-URL Mapping Architecture and Framework (17 pages) RFC5964: Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries (11 pages) RFC6197: Location-to-Service Translation (LoST) Service List Boundary Extension (15 pages) RFC6443: Framework for Emergency Calling Using Internet Multimedia (38 pages) * Updates RFC7852 RFC6444: Location Hiding: Problem Statement and Requirements (9 pages) RFC6739: Synchronizing Service Boundaries and Elements Based on the Location-to-Service Translation (LoST) Protocol (25 pages) * Updates RFC8996 RFC6881: Best Current Practice for Communications Services in Support of Emergency Calling (28 pages) * Updates RFC7840 * Updates RFC7852 RFC7090: Public Safety Answering Point (PSAP) Callback (18 pages) RFC7163: URN for Country-Specific Emergency Services (4 pages) RFC7378: Trustworthy Location (31 pages) RFC7406: Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices (25 pages) RFC7840: A Routing Request Extension for the HTTP-Enabled Location Delivery (HELD) Protocol (16 pages) RFC7852: Additional Data Related to an Emergency Call (113 pages) RFC8147: Next-Generation Pan-European eCall (43 pages) RFC8148: Next-Generation Vehicle-Initiated Emergency Calls (40 pages) RFC8876: Non-interactive Emergency Calls (25 pages) RFC9036: Changing the Location-to-Service Translation (LoST) Location Profiles Registry Policy (4 pages) Revision of core Email specifications (emailcore) ------------------------------------------------- Charter Last Modified: 2023-07-06 Current Status: Active Chairs: Alexey Melnikov Todd Herr Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: emailcore@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/emailcore Archive: https://mailarchive.ietf.org/arch/browse/emailcore/ Description of Working Group: The base documents defining Internet messaging — colloquially, email -- are RFC 5321 (protocol) and RFC 5322 (format). These are revisions and consolidations of prior documents and were last published in 2008. They currently sit at Draft Standard status, a status that no longer exists according to the current IETF procedure. Since then some errata have accumulated (both submitted to IETF and reported directly to editors), as have comments made about these documents not necessarily describing best email practices. There is now sufficient critical mass to undertake a limited review and revision of these documents for the purpose of advancing them to Internet Standard status. This working group will conduct a limited review and revision to the base email specifications, and will publish new versions of these documents at Internet Standard status, per RFC 6410. The limited review is restricted to corrections and clarifications only, with a strong emphasis on keeping these minimal and avoiding broader changes to terminology or document organization. In addition to processing existing, verified errata and errata marked as "held for document update", the WG may address newly-offered errata. However, no new protocol extensions or amendments will be considered for inclusion into 5321bis and 5322bis documents, unless they are already published as IETF Stream RFCs and are at sufficient maturity level to move to Internet Standard. The working group will also work on an Applicability Statement in parallel with 5321bis and 5322bis, to capture relationships to other documented and widely deployed work (recommended extensions, transport security and other issues from the UTA working group's output, and such) and current email practices. 5321bis and 5322bis will be submitted for publication before this document is finalized, and the "bis" documents will have priority for the working group's attention until they are finished. Upon completion of these three milestones, and assuming there is still the momentum to do so, the working group may undertake similar review and revision of other email specifications. Such future work will require rechartering. Goals and Milestones: May 2024 - Submit RFC5322bis to the IESG for publication at Internet Standard Jul 2024 - Submit RFC5321bis to the IESG for publication at Internet Standard Nov 2024 - Submit Applicability Statment to the IESG for publication at Proposed Standard Internet-Drafts: - Applicability Statement for IETF Core Email Protocols [draft-ietf-emailcore-as-11] (19 pages) - Simple Mail Transfer Protocol [draft-ietf-emailcore-rfc5321bis-31] (114 pages) - Internet Message Format [draft-ietf-emailcore-rfc5322bis-12] (59 pages) No Requests for Comments Email mailstore and eXtensions To Revise or Amend (extra) --------------------------------------------------------- Charter Last Modified: 2024-07-09 Current Status: Active Chairs: Bron Gondwana Jiankang Yao Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Murray Kucherawy Secretary: Kenneth Murchison Mailing Lists: General Discussion: extra@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/extra Archive: https://mailarchive.ietf.org/arch/browse/extra/ Description of Working Group: The IETF maintains several key email related protocols that relate to message delivery to mailstores and mailstore access. These include the following: IMAP (RFC3501) SIEVE (RFC5228) ManageSieve (RFC5804) From time to time, there are bursts of work to do and the motivation and critical mass to do it. When such bursts coincide, it's important to give them a home. This working group provides such a venue. The WG will work on updates, extensions, and revisions to the above email protocols. Upon formation, the working group will consider any existing Internet Drafts that could be appropriate for its processing. While an interest poll for a new related idea is fine, the WG should avoid detailed discussion of work items lacking an Internet-Draft. The working group will start with processing the backlog of IMAP/Sieve extensions. Once this is done it will continue processing submitted IMAP/Sieve extensions, as well as work on a revision of IMAP (RFC 3501). Work on updating this RFC will include appropriate corrections, clarifications, or amplifications to reflect existing practice or to address problems that have been identified through experience with IMAP as currently specified. Also eligible for consideration is the incorporation of accumulated errata or consolidation with newer documents that have updated and/or extended the base specification. However, any new functionality is expected to be pursued via extensions rather than changes to the base protocol wherever possible. If there is interest in revising SIEVE (RFC5228) and ManageSieve (RFC5804), the WG will recharter. Expressly excluded from this charter is work on any protocol for which a dedicated working group already exists, such as DMARC, DCRUP or JMAP, as well as any work on POP3, SMTP/LMTP and email format/MIME. However, each working group should endeavor to remain aware of the activities of the other and collaborate as needed. Goals and Milestones: Dec 2023 - Submit IMAP UIDONLY draft to IESG Apr 2024 - Submit process imip draft to IESG Apr 2024 - Adopt a document for EAI with Sieve Apr 2024 - Submit Sieve Calendar processing draft to IESG Apr 2024 - Adopt a document for RFC6855-bis Jun 2024 - Submit Sieve EAI to IESG Done - Submit "Sieve Email Filtering: Delivering to Special-Use Mailboxes" to IESG as a Proposed Standard Done - Submit "IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST" to IESG as a Proposed Standard Done - Adopt a QUOTA-BIS document Done - Adopt a sieve-snooze document Done - Submit sieve-mailboxid to the IESG as a proposed standard Done - Submit "IMAP4rev2" to IESG as a Proposed Standard Done - Submit "Quota BIS" to IESG as a Proposed Standard Done - Adopt a document creating a sieve actions registry Done - Adopt a document for returning metadata in list responses Done - Submit MESSAGELIMIT draft Done - Submit IMAP INPROGRESS draft to IESG Done - Submit LIST-METADATA draft to IESG Internet-Drafts: - Internet Message Access Protocol (IMAP) - SAVEDATE Extension [draft-bosch-imap-savedate-00] (6 pages) - Internet Message Access Protocol (IMAP) - STATUS=SIZE Extension [draft-bosch-imap-status-size-00] (5 pages) - IMAP REPLACE Extension [draft-brandt-imap-replace-03] (10 pages) - IMAP Extension for unique identifiers [draft-extra-imap-uniqueid-00] (10 pages) - IMAP Support for UTF-8 [draft-ietf-extra-6855bis-03] (12 pages) - Snoozing Email with IMAP, JMAP, and Sieve [draft-ietf-extra-email-snooze-00] (21 pages) - Internet Message Access Protocol (IMAP) - Version 4rev2 [draft-ietf-extra-imap4rev2-30] (163 pages) - 64bit body part and message sizes in IMAP4 [draft-ietf-extra-imap-64bit-03] (7 pages) - IMAP4 Extension: Message Preview Generation [draft-ietf-extra-imap-fetch-preview-10] (10 pages) - IMAP4 Extension: Message Snippet Generation [draft-ietf-extra-imap-fetch-snippet-00] (10 pages) - IMAP4 Response Code for Command Progress Notifications. [draft-ietf-extra-imap-inprogress-06] (7 pages) - IMAP4 Extension for Returning Mailbox METADATA in Extended LIST [draft-ietf-extra-imap-list-metadata-05] (7 pages) - IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST [draft-ietf-extra-imap-list-myrights-07] (6 pages) - IMAP MESSAGELIMIT Extension [draft-ietf-extra-imap-messagelimit-10] (12 pages) - IMAP Extension for Object Identifiers [draft-ietf-extra-imap-objectid-08] (16 pages) - IMAP PARTIAL Extension for Paged SEARCH and FETCH [draft-ietf-extra-imap-partial-04] (10 pages) - IMAP REPLACE Extension [draft-ietf-extra-imap-replace-03] (11 pages) - Internet Message Access Protocol (IMAP) - SAVEDATE Extension [draft-ietf-extra-imap-savedate-01] (7 pages) - IMAP Extension for STATUS=SIZE [draft-ietf-extra-imap-status-size-02] (6 pages) - IMAP Extension for only using and returning UIDs [draft-ietf-extra-imap-uidonly-08] (9 pages) - IMAP UNAUTHENTICATE Extension for Connection Reuse [draft-ietf-extra-imap-unauth-01] (11 pages) - IMAP Extension for unique identifiers [draft-ietf-extra-imap-uniqueid-00] (10 pages) - The JMAPACCESS Extension for IMAP [draft-ietf-extra-jmapaccess-09] (7 pages) - Sieve Email Filtering: Extension for Processing Calendar Attachments [draft-ietf-extra-processimip-09] (15 pages) - IMAP QUOTA Extension [draft-ietf-extra-quota-10] (19 pages) - IANA Registry for Sieve Actions [draft-ietf-extra-sieve-action-registry-06] (9 pages) - Sieve Extension: File Carbon Copy (FCC) [draft-ietf-extra-sieve-fcc-09] (12 pages) - Sieve Email Filtering: Delivery by MAILBOXID [draft-ietf-extra-sieve-mailboxid-09] (8 pages) - Sieve Email Filtering: Snooze Extension [draft-ietf-extra-sieve-snooze-07] (14 pages) - Sieve Email Filtering: Delivering to Special-Use Mailboxes [draft-ietf-extra-sieve-special-use-05] (12 pages) - IMAP "$Important" Keyword and "\Important" Special-Use Attribute [draft-ietf-extra-specialuse-important-04] (11 pages) - IMAP $Important Keyword and \Important Special-Use Attribute [draft-leiba-extra-specialuse-important-01] (9 pages) - INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2 [draft-melnikov-imap4rev2-08] (125 pages) - IMAP4 Extension: Message Snippet Generation [draft-slusarz-imap-fetch-snippet-00] (10 pages) Requests for Comments: RFC8437: IMAP UNAUTHENTICATE Extension for Connection Reuse (11 pages) RFC8438: IMAP Extension for STATUS=SIZE (6 pages) RFC8440: IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST (6 pages) RFC8457: IMAP "$Important" Keyword and "\Important" Special-Use Attribute (11 pages) RFC8474: IMAP Extension for Object Identifiers (16 pages) RFC8508: IMAP REPLACE Extension (11 pages) RFC8514: Internet Message Access Protocol (IMAP) - SAVEDATE Extension (7 pages) RFC8579: Sieve Email Filtering: Delivering to Special-Use Mailboxes (12 pages) RFC8580: Sieve Extension: File Carbon Copy (FCC) (12 pages) RFC8970: IMAP4 Extension: Message Preview Generation (10 pages) RFC9042: Sieve Email Filtering: Delivery by MAILBOXID (8 pages) RFC9051: Internet Message Access Protocol (IMAP) - Version 4rev2 (163 pages) RFC9122: IANA Registry for Sieve Actions (9 pages) RFC9208: IMAP QUOTA Extension (19 pages) RFC9394: IMAP PARTIAL Extension for Paged SEARCH and FETCH (10 pages) RFC9585: IMAP Response Code for Command Progress Notifications (6 pages) RFC9586: IMAP Extension for Using and Returning Unique Identifiers (UIDs) Only (9 pages) RFC9590: IMAP Extension for Returning Mailbox METADATA in Extended LIS (6 pages) JSON Mail Access Protocol (jmap) -------------------------------- Charter Last Modified: 2022-05-03 Current Status: Active Chairs: Bron Gondwana Jim Fenton Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: jmap@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/jmap Archive: https://mailarchive.ietf.org/arch/browse/jmap Description of Working Group: The JMAP protocol defined in draft-ietf-jmap-core is designed to be extensible to multiple datatypes which are useful for personal information management related to email stores. Now that draft-ietf-jmap-mail is completed, the working group will produce specifications for related data types, beginning with calendars and contacts. The calendar work will be based on draft-ietf-calext-jscalandar as the data format. This working group will consult with the CALEXT working group to ensure that calendar access via JMAP remains compatible with existing calendar standards. The contact work will begin with a JSON format for contact data based upon the work begun in draft-stepanek-jscontact, and in consultation with other users of contact data within the IETF and outside to build an extensible format. Where possible, this format will retain the ability to convert backwards and forwards to RFC6350 vCard format. This format will then be used as the basis of JMAP object types for contacts. Extensions to the existing core and mail JMAP specifications are also within scope for this working group, for example any additional parts of SIEVE, IMAP, SMTP submission, as well as transport of JMAP over WSS (WebSocket over TLS, RFC 6455). Work on JMAP extensions will be bound by the following constraints: 1) The work of this group is limited to developing protocols for a client synchronising data with a server. Any server-to-server issues are out of scope for this working group. 2) Object models will use existing IETF work where possible. 3) JMAP Extensions will be built following the core principles: 3.1) The server will not be required to perform work not explicitly requested by the client, and the default should always be the mode which requires the least server work. 3.2) The client can discover limits enforced by the server on resources or request complexity. 3.3) Where side effects generated by the server are optional, the protocol will default to no side effects, and the client must explicitly request that those side effects happen (for example: sending a calendar invitation or reply when updating an event) The working group will deliver documents for the following: - JMAP access to calendars using the JSCalendar format - JSON formats for representing contacts and groups of contacts (JSContact) - JMAP access to addressbooks using the JSContact format - Accessing JMAP over Websockets - Handling of S/MIME email messages (e.g. signature verification) over JMAP - Message Disposition Notifications (RFC 8098) via JMAP - Other extensions which the working group considers related to email and compatible with the constraints listed above Also within scope for this working group are informational documents for converting between JMAP data representation and other formats already in wide use which can be used to specify the same underlying data. Goals and Milestones: Sep 2024 - Submit Webpush Vapid document to IESG Oct 2024 - Adopt a document for JMAP Archive format Nov 2024 - Submit Portability Guide (Minimal Profile) to IESG Nov 2024 - Submit Portability Extensions to IESG Feb 2025 - Submit REST Mapping document to IESG Feb 2025 - Submit JMAP Tasks document to IESG Feb 2025 - Submit SMIME Sender Extensions document to the IESG Done - Adopt a document for a JSON Contact format (after recharter) Done - Adopt a document defining mappings between VCARD and JSContact Done - Submit Message Disposition Notification document to the IESG Done - Adopt a document for managing Sieve via JMAP Done - Submit JMAP S/MIME signature validation document to the IESG Done - Adopt a document for creating Blobs via JMAP method call Done - Adopt a document for S/MIME key management and server side signing/encryption Done - Submit document for Blobs via JMAP to the IESG Done - Submit JMAP Quotas document to the IESG Done - Adopt a document defining JMAP access to addressbooks Done - Coordinate with extra wg and potentially adopt document for snooze Done - Submit Sieve document to the IESG Done - Adopt a document for JMAP REST mapping Done - Adopt a document for Server info and debug Done - Adopt a draft for a basic migration simplified endpoint Done - Submit JMAP Sharing document to IESG Done - Submit Contacts document to the IESG Done - Submit JMAP Calendars document to the IESG Internet-Drafts: - JMAP Migration and Portability Extensions [draft-baum-jmap-portability-extensions-00] (8 pages) - JMAP Guide for Migration and Data Portability [draft-baum-jmap-portability-guide-00] (19 pages) - JMAP REST Mapping [draft-baum-jmap-rest-01] (7 pages) - JMAP for Tasks [draft-baum-jmap-tasks-00] (16 pages) - JMAP Blob management extension [draft-gondwana-jmap-blob-02] (10 pages) - Use of VAPID in JMAP WebPush [draft-gultsch-jmap-webpush-vapid-02] (4 pages) - JSON Meta Application Protocol (JMAP) Blob Management Extension [draft-ietf-jmap-blob-18] (24 pages) - JMAP for Calendars [draft-ietf-jmap-calendars-20] (64 pages) - JMAP for Contacts [draft-ietf-jmap-contacts-10] (18 pages) - The JSON Meta Application Protocol (JMAP) [draft-ietf-jmap-core-17] (90 pages) - JMAP Essential Profile [draft-ietf-jmap-essential-01] (20 pages) - The JSON Meta Application Protocol (JMAP) for Mail [draft-ietf-jmap-mail-16] (108 pages) - Handling Message Disposition Notification with the JSON Meta Application Protocol (JMAP) [draft-ietf-jmap-mdn-17] (13 pages) - JMAP Migration and Portability Extensions [draft-ietf-jmap-portability-extensions-01] (9 pages) - JMAP Guide for Migration and Data Portability [draft-ietf-jmap-portability-guide-00] (19 pages) - JSON Meta Application Protocol (JMAP) for Quotas [draft-ietf-jmap-quotas-12] (11 pages) - JMAP REST Mapping [draft-ietf-jmap-rest-00] (7 pages) - JMAP Sharing [draft-ietf-jmap-sharing-09] (18 pages) - JMAP for Sieve Scripts [draft-ietf-jmap-sieve-22] (27 pages) - S/MIME Signature Verification Extension to the JSON Meta Application Protocol (JMAP) [draft-ietf-jmap-smime-12] (10 pages) - JMAP extension for S/MIME signing and encryption [draft-ietf-jmap-smime-sender-extensions-04] (9 pages) - JMAP for Tasks [draft-ietf-jmap-tasks-06] (26 pages) - Use of VAPID in JMAP WebPush [draft-ietf-jmap-webpush-vapid-03] (5 pages) - A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket [draft-ietf-jmap-websocket-07] (13 pages) Requests for Comments: RFC8620: The JSON Meta Application Protocol (JMAP) (90 pages) * Updates RFC9404 RFC8621: The JSON Meta Application Protocol (JMAP) for Mail (108 pages) RFC8887: A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket (13 pages) RFC9007: Handling Message Disposition Notification with the JSON Meta Application Protocol (JMAP) (13 pages) RFC9219: S/MIME Signature Verification Extension to the JSON Meta Application Protocol (JMAP) (10 pages) RFC9404: JSON Meta Application Protocol (JMAP) Blob Management Extension (24 pages) RFC9425: JSON Meta Application Protocol (JMAP) for Quotas (11 pages) Mail Maintenance (mailmaint) ---------------------------- Charter Last Modified: 2024-08-28 Current Status: Active Chair: Kenneth Murchison Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: mailmaint@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mailmaint Archive: https://mailarchive.ietf.org/arch/browse/mailmaint/ Description of Working Group: Internet Messaging (“email”) is one of the oldest applications still supported by the IETF. It consists of numerous layers and extensions that support the robust construction, transport, retrieval, and interpretation of messages. (For the purposes of this charter, “email” starts in RFC 5321 which covers transport and RFC 5322 which covers message format, and extends into specifications based on those documents and their antecedents. It also includes related protocols such as IMAP [RFC 9051] and JMAP [RFC 8620, et seq].) From time to time, new work in the email space is brought to the IETF for consideration and development. Where there is enough critical mass to create a working group to develop and publish the work, this is the preferred case. More often, however, a proposal is brought that lacks enough critical mass to independently support chartering of a working group, but would still be useful to publish as a standard. Such projects must then either seek the assent of an Area Director willing to sponsor it as a standards track document, or support via the Independent Stream Editor (ISE) without standards track status. The MAILMAINT (“Mail Maintenance”) working group will consider projects in the email space that are too small to warrant construction of a dedicated working group. This will take advantage of a common community to consider these proposals rather than forming a series of disparate but related communities. Work proposed for MAILMAINT may arrive via direct proposals, or it may be referred via one or more DISPATCH-style working groups. Recorded Calls for Adoption are required for all work proposals. Proponents of work that is not taken up within the IETF may, of course, decide to bring their proposal to the Independent Stream. The working group should discuss such proposals with the ISE and share the results of the working group’s consideration. Further, MAILMAINT will observe the following constraints when considering the adoption of new work directly: * Prior to accepting any Standards Track document for development, there must be a commitment to implement the resulting proposed standard from at least two independent parties, as recorded on a related IETF mailing list. * When deciding to send any Standards Track work to the IESG, there must first be produced a report documenting at least two (preferably more) independent implementations with at least partial interoperation based on the developed specification. * The above constraints do not apply to documents that are not intended for the Standards Track. * Chartering of a dedicated working group with a custom charter is strongly preferred when engaging any work that updates any base email documents, including but not limited to those identified above. All work will be announced to appropriate non-WG lists such as ietf-822, ietf-smtp, ietf-dkim, etc., at the time a Call For Adoption or Working Group Last Call begins. Standards work being taken up by MAILMAINT should be checked with other relevant areas (mainly Security) to confirm appropriate oversight or possible assignment to that area. Milestones will be used to track all approved work, including during chartering and rechartering. Goals and Milestones: Jul 2024 - Discuss where work on updating/clarifying SMTPUTF8 should be done Feb 2025 - WGLC on draft-ietf-mailmaint-wrong-recipient Feb 2025 - WGLC on draft-ietf-mailmaint-expires Done - Call For Adoption of draft-dweekly-wrong-recipient Done - Call for Adoption of draft-billon-expires Done - Call for Adoption of draft-bucksch-autoconfig Internet-Drafts: - Aggregate Reports for DKIM Signers [draft-brotman-dkim-aggregate-reporting-01] (11 pages) - Email Feedback Reports for DKIM Signers [draft-brotman-dkim-fbl-03] (11 pages) - Mail Autoconfig [draft-bucksch-autoconfig-04] (21 pages) - Adding a Wrong Recipient URL for Handling Misdirected Emails [draft-dweekly-wrong-recipient-06] (9 pages) - Nice Email Addresses for SMTPUTF8 [draft-gulbrandsen-smtputf8-nice-addresses-00] (12 pages) - Updated Use of the Expires Message Header Field [draft-ietf-mailmaint-expires-00] (6 pages) - Adding a Wrong Recipient URL for Handling Misdirected Emails [draft-ietf-mailmaint-wrong-recipient-00] (9 pages) - SMTP Service Extension for Client Identity [draft-storey-smtp-client-id-17] (16 pages) - IMAP Service Extension for Client Identity [draft-yu-imap-client-id-12] (13 pages) No Requests for Comments Media Type Maintenance (mediaman) --------------------------------- Charter Last Modified: 2024-05-30 Current Status: Active Chairs: A.J. Stein Harald T. Alvestrand Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: media-types@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/media-types Archive: https://mailarchive.ietf.org/arch/browse/media-types/ Description of Working Group: IANA maintains a registry of media types and subtypes that are used to identify particular payloads and their semantics as they are transported via application level protocols such as messaging (“email”) and the web (HTTP). The core structure and use of media types is the MIME framework, defined in RFCs 2045 through 2049, and amended by various later documents. Registration of new media types is defined by BCP 13, which was last updated in 2013. The registration of a top-level media type is a rare event. BCP 13 describes the process for doing so, as was used in RFC 8081, but it does not provide any guidance or criteria regarding what constitutes an appropriate registration. Several other topics have appeared in the interim that are large enough in scope and importance to warrant the formation of a working group to develop and process them. This working group will therefore take up the following items, in this order (or as otherwise negotiated with the supervising Area Director): * Determine whether any specific criteria or guidance are warranted to handle registration of future top-level media types, and publish any such guidance. * Develop and process the pending ‘haptics’ top-level media type request, based on draft-muthusamy-dispatch-haptics, and the outcome of the previous work item. * Consider whether and how to permit multiple media type suffixes. * Develop a reviewer’s checklist regarding Security Considerations sections in media type applications. * Consider any issues around media types for programming languages and data definition languages such as YANG. * Review the format of the media types registry itself. * Evaluate the registry policies and procedures in the context of how media types are currently used, and modify them if necessary. This last item will consider the existing use of GitHub for managing registrations and the processing queues for the “link relations” and “well known URIs” registries as examples. Input Document(s): * draft-muthusamy-dispatch-haptics * draft-w3cdidwg-media-types-with-multiple-suffixes Proposed milestones (target dates TBD): * Publish any specific criteria or guidance for handling registration of future top-level media types, either as an RFC or a wiki page. * draft-muthusamy-dispatch-haptics (or equivalent) to the IESG for approval (Proposed Standard) * A draft about handling multiple suffixes to the IESG for approval (BCP) * Publish a reviewer’s checklist about Security Considerations in media type applications, either as an RFC or a wiki page. * Deliver recommendations about the media types registry format. * Deliver any recommendations about future registration and queue management. Goals and Milestones: Oct 2024 - Draft about handling multiple suffixes to the IESG for approval (BCP) Dec 2024 - Publish a reviewer’s checklist about Security Considerations in media type applications, either as an RFC or a wiki page Dec 2024 - Deliver any recommendations about future registration and queue management Jul 2025 - Deliver an updated media type registration procedures RFC Done - Publish any specific criteria or guidance for handling registration of future top-level media types, either as an RFC or a wiki page. Done - Registration of the "haptics" top-level type to the IESG for approval (Proposed Standard) Internet-Drafts: - The 'haptics' Top-level Media Type [draft-ietf-mediaman-haptics-05] (13 pages) - Allowing Community Registrations in the Standards Tree [draft-ietf-mediaman-standards-tree-01] (5 pages) - Media Type Suffixes [draft-ietf-mediaman-suffixes-08] (8 pages) - Guidelines for the Definition of New Top-Level Media Types [draft-ietf-mediaman-toplevel-06] (14 pages) - Allowing Community Registrations in the Standards Tree [draft-nottingham-mediaman-standards-tree-00] (5 pages) No Requests for Comments More Instant Messaging Interoperability (mimi) ---------------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Alissa Cooper Tim Geoghegan Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Orie Steele Mailing Lists: General Discussion: mimi@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mimi Archive: https://mailarchive.ietf.org/arch/browse/mimi/ Description of Working Group: The More Instant Messaging Interoperability (MIMI) working group will specify the minimal set of mechanisms required to make modern Internet messaging services interoperable. Over time, messaging services have achieved widespread use, their feature sets have broadened, and their adoption of end-to-end encryption (E2EE) has grown, but the lack of interoperability between these services continues to create a suboptimal user experience. The standards produced by the MIMI working group will allow for E2EE messaging services for both consumer and enterprise to interoperate without undermining the security guarantees that they provide. The working group will aim to achieve the strongest usable security and privacy properties for each targeted functional requirement. Recognizing the need for a standardized security protocol to support group key establishment, authentication, and confidentiality services for messaging, the IETF has specified the Messaging Layer Security (MLS) protocol [I-D.ietf-mls-protocol] and architecture [I-D.ietf-mls-architecture]. MLS is agnostic to the identity system used within any given messaging service; it provides confidentiality of sessions once the participants in a conversation have been identified. To achieve interoperable messaging, the MIMI working group will specify how one or more identity building block technologies (for example, X.509 certificates or Verifiable Credentials) can be used to establish end-to-end cryptographic identity across messaging services, assuming the use of MLS for key establishment. Interoperable messaging in federated environments requires consensus on a common delivery service and a transport protocol between federated domains. Specifically, the MLS protocol requires ordering of handshake messages within groups to ensure clients can synchronize despite asynchronous message delivery. This working group will specify a flexible solution for transport and delivery that takes into account typical requirements and best practices from the industry. Achieving interoperable messaging among MIMI-compliant services requires a solution for the introduction problem, i.e., the ability for a user in one application to take an identity of a target user along with the associated application, be granted permission to initiate communications, and be able to establish communications with the target. The working group will specify a solution to the introduction problem, together with best practice recommendations for functionality, configuration options, and other aspects. The working group may also choose to specify a solution to discover the set of preferred messaging services associated with a given identity. Express and implied user preferences about discoverability and reachability must be respected. Modern messaging services commonly support numerous features including plain and rich text, delivery notifications, read receipts, replies, reactions, presence, and many more. The working group will identify an extensible baseline set of messaging features and specify a content format to allow this feature set to be implemented interoperably. This format must be usable in the presence of E2EE. In defining the format, the working group will seek to reuse existing primitives (especially existing semantics) including previously defined message headers, MIME types, and URIs where practical. In its initial phase, the working group will focus on solutions for messaging. The working group will aim for general-purpose designs fit for both 1:1 and multiparty messaging. The working group will not standardize new audio/video signaling or media protocols but may recommend the use of existing protocols and suites such as SIP and WebRTC. The following are out of scope for the working group: * Metadata processing to manage spam and abuse * Interoperable mechanisms for group administration or moderation across systems * Extensions to the MLS protocol. If needed, requirements will be referred to the MLS working group or other relevant working groups in the security area. * Definition of completely new identity formats or protocols. * Extensions to SIP, SDP, MSRP, or WebRTC. * Development of anti-spam or anti-abuse algorithms. * Oracle or look-up services that reveal the list of messaging services associated with a given user identity without the user's permission. Numerous prior attempts have been made to address messaging interoperability, including the IETF's extensive prior work on XMPP, SIP/SIMPLE, and their related messaging formats. The MIMI working group will draw lessons from these prior attempts, seek to avoid re-hashing old debates, and will focus on the minimal standards suite necessary to facilitate interoperability given the feature set of modern messaging applications. MIMI will communicate with related working groups as needed, including MLS, STIR, OAUTH, GNAP, and the W3C Verifiable Credentials WG. Goals and Milestones: Mar 2024 - WG adoption of MIMI protocol specification Mar 2024 - WG adoption of architecture document for messaging interoperability Nov 2024 - WG adoption of specification for identifier naming conventions Nov 2024 - WG adoption of specification for user discovery mechanism Nov 2024 - WG adoption of user discovery requirements document (decision about whether to forward to IESG for publication to be made later, by WG consensus) Mar 2025 - Forward specification for identifier naming conventions to IESG Mar 2025 - Forward specification of MIMI protocol to IESG Mar 2025 - Forward specification for messaging content format to IESG Nov 2025 - Forward specification for user discovery mechanism to IESG Done - WG adoption of specification for messaging content format Internet-Drafts: - An Architecture for More Instant Messaging Interoperability (MIMI) [draft-barnes-mimi-arch-03] (16 pages) - An Architecture for More Instant Messaging Interoperability (MIMI) [draft-ietf-mimi-arch-00] (16 pages) - More Instant Messaging Interoperability (MIMI) message content [draft-ietf-mimi-content-04] (55 pages) - More Instant Messaging Interoperability (MIMI) using HTTPS and MLS [draft-ietf-mimi-protocol-01] (42 pages) - More Instant Messaging Interoperability (MIMI) message content [draft-mahy-mimi-content-02] (23 pages) - More Instant Messaging Interoperability (MIMI) using HTTPS and MLS [draft-ralston-mimi-protocol-02] (40 pages) No Requests for Comments Machine Learning for Audio Coding (mlcodec) ------------------------------------------- Charter Last Modified: 2023-07-26 Current Status: Active Chairs: Greg Maxwell Mo Zanaty Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: mlcodec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mlcodec/ Archive: https://mailarchive.ietf.org/arch/browse/mlcodec/ Description of Working Group: Problem Statement The Opus codec (RFC 6716) was adopted by the IETF in 2012. Since then, speech and audio processing technology has made significant progress, thanks in large part to deep learning techniques. It is desirable to update the existing Opus codec to benefit from recent advances without breaking compatibility with RFC 6716. Opus has achieved a wide degree of interoperability by using in-band signaling to avoid negotiation failure. Implementing new coding technology within Opus would allow incremental compatible deployment of the updated specification, while preserving interoperability with the existing billions of Opus-enabled devices. In doing so, we wish to retain the original qualities that drove the original Opus development to develop codecs that (quoting from codec WG charter): 1. Are optimized for use in interactive Internet applications. 2. Are published by a recognized standards development organization (SDO) and therefore subject to clear change control. 3. Can be widely implemented and easily distributed among application developers, service operators, and end users. Objectives The goals of this working group are: 1) Improving the robustness to packet loss of Opus through efficient redundancy transmission 2) Improving the speech coding quality at low bitrates 3) Improving the music coding quality at low bitrates The working group may also consider other improvements to Opus. The group will only consider solutions that result in bitstreams that are forwards and backwards compatible with RFC6716, and thus decodable by any decoder. Although it is likely that machine learning will be required to meet the objectives above, classical solutions will also be considered if they can achieve similar performance. As was the case with the original codec WG, this work will primarily focus on interactive, real-time applications over the Internet and will ensure interoperability with existing IETF real-time protocols, including RTP, SIP/SDP, and WebRTC. Given the widespread deployment of WebRTC, ensuring that the work improves WebRTC experience is of particular importance. Other applications, such as non-real-time streaming will be considered too, but only so long as their requirements do not interfere with those of real-time applications. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, consistent with BCP 78 and BCP 79, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to redistribute and use. Deliverables 1. A specification for a generic Opus extension mechanism that can be used not only for the other proposed deliverables, but can also sustain further extensions to Opus in the future. This document shall be a Proposed Standard document. 2. A specification for coding large amounts of very low bitrate redundancy information for the purpose of significantly improving the robustness of Opus to bursts of packet loss. This document shall be a Proposed Standard document. 3. A specification for improving the quality of SILK- and hybrid-coded speech through decoder changes, with and without side information provided by the encoder. This will be done in a way that does not affect interoperability between original and extended implementations. This document shall be a Proposed Standard document. 4. A specification for improving the quality of CELT-coded audio (both speech and music) through decoder changes, with and without side information provided by the encoder. This will be done in a way that does not affect interoperability between original and extended implementations. This document shall be a Proposed Standard document. Goals and Milestones: Dec 2023 - Submit generic Opus extension mechanism to the IESG as Proposed Standard. Mar 2024 - Submit specification for Opus resiliency against packet loss to the IESG as Proposed Standard. Jun 2024 - Submit specification for improving the quality SILK- and hybrid-coded speech to the IESG as Proposed Standard. Sep 2024 - Sunmit specification for improving the quality of CELT-coded audio to the IESG as Proposed Standard. Internet-Drafts: - Deep Audio Redundancy (DRED) Extension for the Opus Codec [draft-ietf-mlcodec-opus-dred-01] (22 pages) - Extension Formatting for the Opus Codec [draft-ietf-mlcodec-opus-extension-02] (7 pages) No Requests for Comments Registration Protocols Extensions (regext) ------------------------------------------ Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Antoin Verschuren James Galvin Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Orie Steele Mailing Lists: General Discussion: regext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/regext Archive: https://mailarchive.ietf.org/arch/browse/regext/ Description of Working Group: Charter for Working Group The Extensible Provisioning Protocol (EPP, Standard 69) is the standard domain name provisioning protocol for top-level domain name registries. To avoid many separate EPP extensions that provide the same functions, it's important to coordinate and standardize EPP extensions. The EPP Extensions (EPPEXT) working group completed its first goal of creating an IANA registry of EPP extensions. The registration process of the registry is documented in RFC 7451. Extensions may be registered for informational purposes as long as there is a published specification that has been reviewed by a designated expert. The Registration Data Access Protocol (RDAP, RFCs 7480-7484) is the proposed standard for retrieving registration metadata from both domain name and Regional Internet Registries. To ensure interoperable implementations it's important to coordinate and standardize extensions and profiles to be used by registries. Extensions in both cases that are targeted for the Standards Track are subject to more thorough review and open discussion within the IETF. In addition, commonality may be discovered in related extensions, especially EPP extensions listed on the EPP extension registry, for which it would makes sense to merge them into a single standard extension everybody agrees on. The REGEXT working group is the home of the coordination effort for standards track extensions. The selection of extensions for standards track shall incorporate the following guidelines. 1. Proprietary documented extensions and individual submissions of informational or experimental EPP extensions will follow the expert review process as described in RFC 7451 for inclusion in the EPP extensions registry. These documents will not be part of the REGEXT working group work or milestones. The working group may discuss or advise on these documents. 2. Extensions that seek standards track status can be suggested for WG adoption. If accepted by the working group then the development of the standard may proceed. 3. When there are no more proposals for Standards-Track extensions, the working group will either close or become dormant, with the decision made in consultation with the responsible AD. In any case, the mailing list will remain open and available for the use of the expert review process as described in RFC 7451. The working group may also take on work to develop specifications that describe the following types of information exchanged between entities involved in Internet identifier registration that are using the RDAP or EPP protocols: * Uniform representation formats for publishing local policy or configuration options regarding EPP and RDAP use. * Data formats for files exchanged between registration entities that need insertion in or extraction from EPP or RDAP. * Technical guidance for registration processes that are supported by EPP or RDAP. Goals and Milestones: Mar 2023 - Submit for publication "Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses" Jun 2023 - Submit for publication "DNS Data Dictionary" Mar 2024 - Submit for publication "RDAP RIR Search" Jul 2024 - Submit for publication "An RDAP Extension for Geofeed Data" Sep 2024 - Submit for publication "Best Practices for Deletion of Domain and Host Objects in the Extensible Provisioning Protocol (EPP)" Done - Submit for publication "Registry Fee Extension for EPP" Done - Submit for publication "Change Poll Extension for EPP" Done - Submit for publication "EPP Domain Name Mapping Extension for Bundling Registration" Done - Submit for publication "Login Security Extension for the Extensible Provisioning Protocol (EPP)" Done - Submit for publication "Domain Name Registration Data (DNRD) Objects Mapping" Done - Submit for publication "Registry Data Escrow Specification" Done - Submit for publication "Registration Data Access Protocol (RDAP) Partial Response" Done - Submit for publication "Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging" Done - Submit for publication "EPP Secure Authorization Information for Transfer" Done - Submit for publication "EPP Unhandled Namespaces" Done - Submit for publication "JSON Responses for the Registration Data Access Protocol (RDAP)" Done - Submit for publication "Registration Data Access Protocol (RDAP) Query Format" Done - Submit for publication "Registry Maintenance Notifications for the EPP" Done - Submit for publication "Finding the Authoritative Registration Data (RDAP) Service" Done - Submit for publication "Use of Internationalized Email Addresses in EPP protocol" Done - Submit for publication "Registration Data Access Protocol (RDAP) Reverse search capabilities" Done - Submit for publication "Redacted Fields in the Registration Data Access Protocol (RDAP) Response" Done - Submit for publication "Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect" Done - Submit for publication "Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) values" Internet-Drafts: - Use of Internationalized Email Addresses in EPP protocol [draft-belyavskiy-epp-eai-04] (10 pages) - Finding the Authoritative Registration Data (RDAP) Service [draft-blanchet-regext-rfc7484bis-00] (17 pages) - DNS Data Dictionary [draft-flanagan-regext-datadictionary-01] (13 pages) - Extensible Provisioning Protocol (EPP) Unhandled Namespaces [draft-gould-casanova-regext-unhandled-namespaces-02] (18 pages) - Versioning in the Registration Data Access Protocol (RDAP) [draft-gould-regext-rdap-versioning-02] (30 pages) - Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer [draft-gould-regext-secure-authinfo-transfer-03] (24 pages) - RDAP RIR Search [draft-harrison-regext-rdap-rir-search-00] (8 pages) - Best Practices for Deletion of Domain and Host Objects in the Extensible Provisioning Protocol (EPP) [draft-hollenbeck-regext-epp-delete-bcp-03] (19 pages) - Registration Data Access Protocol (RDAP) Query Format [draft-hollenbeck-regext-rfc7482bis-06] (25 pages) - JSON Responses for the Registration Data Access Protocol (RDAP) [draft-hollenbeck-regext-rfc7483bis-01] (85 pages) - Key Relay Mapping for the Extensible Provisioning Protocol [draft-ietf-eppext-keyrelay-12] (16 pages) - Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) [draft-ietf-eppext-launchphase-07] (61 pages) - ICANN TMCH functional specifications [draft-ietf-eppext-tmch-func-spec-01] (60 pages) - Allocation Token Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-allocation-token-12] (17 pages) - Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration [draft-ietf-regext-bundling-registration-11] (25 pages) - Change Poll Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-change-poll-12] (20 pages) - Registration Data Dictionary [draft-ietf-regext-datadictionary-03] (14 pages) - Registry Data Escrow Specification [draft-ietf-regext-data-escrow-10] (16 pages) - Domain Name Registration Data (DNRD) Objects Mapping [draft-ietf-regext-dnrd-objects-mapping-11] (169 pages) - Third Party DNS operator to Registrars/Registries Protocol [draft-ietf-regext-dnsoperator-to-rrr-protocol-05] (15 pages) - Best Practices for Deletion of Domain and Host Objects in the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-epp-delete-bcp-08] (23 pages) - Use of Internationalized Email Addresses in the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-epp-eai-21] (24 pages) - Registry Fee Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-epp-fees-20] (30 pages) - Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping [draft-ietf-regext-epp-rdap-status-mapping-04] (11 pages) - Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-epp-registry-maintenance-19] (22 pages) - Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) values [draft-ietf-regext-epp-ttl-16] (30 pages) - Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-launchphase-07] (58 pages) - Login Security Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-login-security-10] (21 pages) - Extensible Provisioning Protocol (EPP) China Name Verification Mapping [draft-ietf-regext-nv-mapping-00] (37 pages) - Extensible Provisioning Protocol (EPP) Organization Mapping [draft-ietf-regext-org-12] (43 pages) - Organization Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-org-ext-11] (22 pages) - RDAP Extensions [draft-ietf-regext-rdap-extensions-02] (22 pages) - An RDAP Extension for Geofeed Data [draft-ietf-regext-rdap-geofeed-07] (11 pages) - Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses [draft-ietf-regext-rdap-jscontact-18] (26 pages) - Registration Data Access Protocol (RDAP) Object Tagging [draft-ietf-regext-rdap-object-tag-05] (13 pages) - Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect [draft-ietf-regext-rdap-openid-27] (50 pages) - Registration Data Access Protocol (RDAP) Partial Response [draft-ietf-regext-rdap-partial-response-16] (12 pages) - Redacted Fields in the Registration Data Access Protocol (RDAP) Response [draft-ietf-regext-rdap-redacted-16] (43 pages) - Registration Data Access Protocol (RDAP) Reverse Search [draft-ietf-regext-rdap-reverse-search-26] (20 pages) - RDAP RIR Search [draft-ietf-regext-rdap-rir-search-09] (27 pages) - Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging [draft-ietf-regext-rdap-sorting-and-paging-20] (23 pages) - Versioning in the Registration Data Access Protocol (RDAP) [draft-ietf-regext-rdap-versioning-01] (31 pages) - An RDAP With Extensions Media Type [draft-ietf-regext-rdap-x-media-type-01] (13 pages) - Extensible Provisioning Protocol (EPP) Reseller Mapping [draft-ietf-regext-reseller-01] (30 pages) - Reseller Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-reseller-ext-01] (18 pages) - Registration Data Access Protocol (RDAP) Query Format [draft-ietf-regext-rfc7482bis-03] (18 pages) - JSON Responses for the Registration Data Access Protocol (RDAP) [draft-ietf-regext-rfc7483bis-05] (81 pages) - Finding the Authoritative Registration Data Access Protocol (RDAP) Service [draft-ietf-regext-rfc7484bis-06] (15 pages) - Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer [draft-ietf-regext-secure-authinfo-transfer-07] (22 pages) - Simple Registration Reporting [draft-ietf-regext-simple-registration-reporting-07] (35 pages) - Extensible Provisioning Protocol (EPP) Unhandled Namespaces [draft-ietf-regext-unhandled-namespaces-08] (21 pages) - Validate Mapping for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-validate-04] (16 pages) - Verification Code Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-verificationcode-06] (38 pages) - An RDAP Extension for Geofeed Data [draft-jasdips-regext-rdap-geofeed-00] (5 pages) - Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses [draft-loffredo-regext-rdap-jcard-deprecation-04] (16 pages) - RDAP Extensions [draft-newton-regext-rdap-extensions-01] (11 pages) - RDAP Simple Contact [draft-newton-regext-rdap-simple-contact-01] (11 pages) - An RDAP With Extensions Media Type [draft-newton-regext-rdap-x-media-type-01] (10 pages) - Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) values [draft-regext-brown-epp-ttl-04] (15 pages) - Registry Maintenance Notifications for the Extensible Provisioning Protocol (EPP) [draft-sattler-epp-registry-maintenance-10] (22 pages) - Simple Registration Reporting [draft-yee-regext-simple-registration-reporting-01] (16 pages) Requests for Comments: RFC8056: Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping (11 pages) RFC8063: Key Relay Mapping for the Extensible Provisioning Protocol (16 pages) RFC8334: Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) (58 pages) RFC8495: Allocation Token Extension for the Extensible Provisioning Protocol (EPP) (17 pages) RFC8521: Registration Data Access Protocol (RDAP) Object Tagging (13 pages) RFC8543: Extensible Provisioning Protocol (EPP) Organization Mapping (43 pages) RFC8544: Organization Extension for the Extensible Provisioning Protocol (EPP) (22 pages) RFC8590: Change Poll Extension for the Extensible Provisioning Protocol (EPP) (20 pages) RFC8748: Registry Fee Extension for the Extensible Provisioning Protocol (EPP) (30 pages) RFC8807: Login Security Extension for the Extensible Provisioning Protocol (EPP) (21 pages) RFC8909: Registry Data Escrow Specification (16 pages) RFC8977: Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging (23 pages) RFC8982: Registration Data Access Protocol (RDAP) Partial Response (12 pages) RFC9022: Domain Name Registration Data (DNRD) Objects Mapping (169 pages) RFC9038: Extensible Provisioning Protocol (EPP) Unhandled Namespaces (21 pages) RFC9082: Registration Data Access Protocol (RDAP) Query Format (18 pages) RFC9083: JSON Responses for the Registration Data Access Protocol (RDAP) (81 pages) RFC9154: Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer (22 pages) RFC9167: Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP) (22 pages) RFC9224: Finding the Authoritative Registration Data Access Protocol (RDAP) Service (15 pages) RFC9536: Registration Data Access Protocol (RDAP) Reverse Search (17 pages) RFC9537: Redacted Fields in the Registration Data Access Protocol (RDAP) Response (31 pages) RFC9560: Federated Authentication for the Registration Data Access Protocol (RDAP) Using OpenID Connect (40 pages) Secure Asset Transfer Protocol (satp) ------------------------------------- Charter Last Modified: 2024-04-09 Current Status: Active Chairs: Claire Wes Hardaker Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Orie Steele Mailing Lists: General Discussion: sat@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sat Archive: https://mailarchive.ietf.org/arch/browse/sat/ Description of Working Group: Objective There is currently an interoperability problem in many digital asset networks (frequently shortened to "network" below for simplicity), where assets in one network cannot be moved easily to another network. The problem is more acute in the case of private asset networks, where external entities have no visibility into the state of an asset in the private network. An example is regulated digital representations of real-world private assets, such as property ownership certificates, and regulated government-issued digital currencies. The goal of the Secure Asset Transfer Protocol (SATP) working group will be to develop a standard protocol which operates between two peer gateways for the purpose of transferring digital assets between an originator in the origin network to a beneficiary in a destination network. The resulting protocol shall be agnostic with respect to the type of asset being transferred. Problem space and architecture To begin addressing these challenges, SATP will employ the gateway paradigm as a means for digital assets to be moved from one network to another through a standardized asset transfer protocol implemented between peer gateways. Each gateway represents one digital asset network, and SATP allows gateways to perform a voluntary transfer of a digital asset from the origin network to a destination network in such a way that evidence of the transfer can be verified by a third-party audit in the case of disputes. Both the origin and destination networks are assumed to share a common understanding of the digital asset. There might be several gateways representing the same digital asset network. It is assumed that the same peer gateways representing the networks are participating in the entire asset transfer sequence from the beginning to the end. A key requirement for transferring assets is ensuring that the digital asset is valid in one network only at any given time. This means that SATP must ensure that the properties of atomicity, consistency, isolation, and durability (ACID) of the underlying networks are satisfied in an asset transfer. Commitments and rollbacks must be supported in the case of an asset mid-transfer failure. Relationship with other IETF Working Groups The Transfer dIGital cREdentialS Securely (TIGRESS) working group is focused on transferring digital credentials, which is akin to but not equal to SATP's goals of transferring digital assets. An additional difference is TIGRESS is a wallet-to-wallet transfer, while SATP's proposed solution involves a gateway-to-gateway transfer. The SATP working group will work with TIGRESS proponents to ensure reuse of existing TIGRESS outputs are used within SATP to promote technology reuse. Deliverables The deliverables of the SATP Working Group will be as follows: SATP Architecture: The immediate scope of work for SATP will be a base architecture that utilizes the gateway paradigm that ensures a common semantic understanding to be shared among the modes of asset transfers, data sharing and coordinated asset exchanges. The starting point for the architecture document will be draft-hardjono-sat-architecture. Secure Asset Transfer Protocol: Concurrent with the development of the SATP architecture will be the Secure Asset Transfer Protocol that implements the transfer of a digital asset from one gateway to another, satisfying the ACID properties. SATP Use-Cases: Various real-world use-cases will be collected and described succinctly, with the goal of providing the background to the SATP work. SATP will define common identifiers, message flows and payloads for transferring digital assets. A common terminology will be defined in the architecture document. SATP will reuse existing IETF standards for various aspects of the protocol modes, including but not limited to secure channel establishment (TLS), payload formats (e.g., JSON, CBOR, etc.), digital signature and encryption (e.g., JOSE, COSE, etc.), digital certificates and tokens (e.g., PKIX, JWT, etc.), and others. SATP may also reuse existing standards from other organizations (e.g., W3C with DIDs). Note that for the protocol to work, agreements will likely be needed between participating digital asset networks that intend to use SATP; these legal or other frameworks, along with proof of their proper implementation, are outside of the scope of the SATP. This assumption is akin to how the BGP protocol is frequently run between parties that have previously agreed to route IP packets. Goals and Milestones: Dec 2024 - SATP Use-Cases document Dec 2024 - ATP Asset Transfer Protocol document Jul 2025 - SATP Architecture document Internet-Drafts: - Secure Asset Transfer (SAT) Interoperability Architecture [draft-hardjono-sat-architecture-03] (21 pages) - Secure Asset Transfer Protocol (SATP) [draft-hargreaves-sat-core-02] (29 pages) - Secure Asset Transfer (SAT) Interoperability Architecture [draft-ietf-satp-architecture-05] (27 pages) - Secure Asset Transfer Protocol (SATP) Core [draft-ietf-satp-core-05] (34 pages) - Secure Asset Transfer (SAT) Use Cases [draft-ietf-satp-usecases-03] (19 pages) - Secure Asset Transfer (SAT) Use Cases [draft-ramakrishna-sat-use-cases-02] (12 pages) No Requests for Comments Session Initiation Protocol Core (sipcore) ------------------------------------------ Charter Last Modified: 2023-09-13 Current Status: Active Chairs: Brian Rosen Jean Mahoney Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: sipcore@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sipcore Archive: https://mailarchive.ietf.org/arch/browse/sipcore/ Description of Working Group: The Session Initiation Protocol Core (SIPCore) working group is chartered to maintain and continue the development of the SIP protocol, currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, and 6665. The SIPCore working group will concentrate on specifications that update or replace the core SIP specifications named above as well as specifications pertaining to small, self-contained SIP protocol extensions. The process and requirements for new SIP extensions are documented in RFC5727, "Change Process for the Session Initiation Protocol". Throughout its work, the group will strive to maintain the basic model and architecture defined by SIP. In particular: 1. Services and features are provided end-to-end whenever possible. 2. Reuse of existing Internet protocols and architectures and integrating with other Internet applications is crucial. 3. Standards-track extensions and new features must be generally applicable, and not applicable only to a specific set of session types. 4. Simpler solutions that solve a given problem should be favored over more complex solutions. The primary source of change requirements to the core SIP specifications (enumerated above) will be a) interoperability problems that stem from ambiguous, or under-defined specification, and b) requirements from other working groups in the ART Area. The primary source of new protocol extensions is the DISPATCH working group, which will generally make the determination regarding whether new SIP-related work warrants a new working group or belongs in an existing one. Goals and Milestones: Dec 2017 - Request publication of mechanisms for rapid dual-stack protocol selection in SIP Jun 2023 - Multiple Reasons values per protocol (PS) to the IESG Done - INFO package framework to IESG (PS) Done - Termination of early dialog prior to final response to IESG (PS) Done - Extension for use in etags in conditional notification to IESG (PS) Done - Invite Transaction Handling Correction to IESG (PS) Done - SIP Events throttling mechanism to IESG (PS) Done - Presence Scaling Requirements to IESG as Info Done - Mechanism for indicating support for keep-alives (PS) Done - Example security flows to IESG (Informational) Done - Location Conveyance with SIP to IESG (PS) Done - Error corrections and clarifications to RFC3265 to IESG (PS) Done - Delivering request-URI and parameters to UAS via proxy to IESG (PS) Done - Mechanism to indicate proxy capabilities to both endpoints and other intermediaries in the path of a REGISTER transaction or dialog-forming transaction to IESG (PS) Done - WebSockets transport definition for SIP to the IESG (proposed standard) Done - Request publication of DNS look-up procedures for dual-stack client and server handling of SIP URIs Done - Request publication of a SIP response code for unwanted communications Done - Request publication of a mechanism for labeling the nature of SIP calls Done - Request publication of a clarification of the use of Content-ID as a SIP header field Done - Request publication of a clarification of the use of the "name-addr" production in SIP header fields Dropped - WGLC on requirements for a mechanism to indicate proxy capabilities to both endpoints and other proxies in the path of a REGISTER transaction or a dialog-forming transaction. Internet-Drafts: - Session Timers in the Session Initiation Protocol (SIP) [draft-holmberg-sipcore-rfc4028bis-00] (26 pages) - Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog [draft-ietf-sipcore-199-06] (14 pages) - A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework [draft-ietf-sipcore-6665-clarification-00] (4 pages) - SIP Call-Info Parameters for Rich Call Data [draft-ietf-sipcore-callinfo-rcd-12] (31 pages) - SIP Call-Info Parameters for Labeling Calls [draft-ietf-sipcore-callinfo-spam-04] (11 pages) - Content-ID Header Field in the Session Initiation Protocol (SIP) [draft-ietf-sipcore-content-id-10] (14 pages) - The Session Initiation Protocol (SIP) Digest Access Authentication Scheme [draft-ietf-sipcore-digest-scheme-15] (9 pages) - Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network [draft-ietf-sipcore-dns-dual-stack-08] (10 pages) - Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control [draft-ietf-sipcore-event-rate-control-09] (25 pages) - Session Initiation Protocol (SIP) INFO Method and Package Framework [draft-ietf-sipcore-info-events-10] (36 pages) - Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests [draft-ietf-sipcore-invfix-01] (20 pages) - Indication of Support for Keep-Alive [draft-ietf-sipcore-keep-12] (18 pages) - Location Conveyance for the Session Initiation Protocol [draft-ietf-sipcore-location-conveyance-09] (35 pages) - Location Source Parameter for the SIP Geolocation Header Field [draft-ietf-sipcore-locparam-06] (8 pages) - Multiple SIP Reason Header Field Values [draft-ietf-sipcore-multiple-reasons-01] (4 pages) - Clarifications for When to Use the name-addr Production in SIP Messages [draft-ietf-sipcore-name-addr-guidance-02] (6 pages) - A P-Served-User Header Field Parameter for an Originating Call Diversion (CDIV) Session Case in the Session Initiation Protocol (SIP) [draft-ietf-sipcore-originating-cdiv-parameter-08] (15 pages) - Scaling Requirements for Presence in SIP/SIMPLE [draft-ietf-sipcore-presence-scaling-requirements-02] (9 pages) - IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field [draft-ietf-sipcore-priority-00] (3 pages) - Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP) [draft-ietf-sipcore-proxy-feature-12] (19 pages) - Requirements for indication of features supported by a SIP proxy [draft-ietf-sipcore-proxy-feature-reqs-03] (9 pages) - ISDN User Part (ISUP) Cause Location Parameter for the SIP Reason Header Field [draft-ietf-sipcore-reason-q850-loc-07] (7 pages) - Clarifications for the Use of REFER with RFC 6665 [draft-ietf-sipcore-refer-clarifications-04] (6 pages) - Explicit Subscriptions for the REFER Method [draft-ietf-sipcore-refer-explicit-subscription-03] (14 pages) - Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP) [draft-ietf-sipcore-reinvite-08] (26 pages) - A Session Initiation Protocol (SIP) Response Code for Rejected Calls [draft-ietf-sipcore-rejected-09] (22 pages) - SIP-Specific Event Notification [draft-ietf-sipcore-rfc3265bis-09] (53 pages) - Session Timers in the Session Initiation Protocol (SIP) [draft-ietf-sipcore-rfc4028bis-06] (26 pages) - An Extension to the Session Initiation Protocol (SIP) for Request History Information [draft-ietf-sipcore-rfc4244bis-12] (36 pages) - Session Initiation Protocol (SIP) History-Info Header Call Flow Examples [draft-ietf-sipcore-rfc4244bis-callflows-08] (52 pages) - Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses [draft-ietf-sipcore-rfc7976bis-00] (8 pages) - Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms [draft-ietf-sipcore-sec-flows-09] (67 pages) - Session Initiation Protocol (SIP) Session Timer Glare Handling [draft-ietf-sipcore-sessiontimer-race-02] (7 pages) - Third-Party Authentication for Session Initiation Protocol (SIP) [draft-ietf-sipcore-sip-authn-02] (17 pages) - Push Notification with the Session Initiation Protocol (SIP) [draft-ietf-sipcore-sip-push-29] (40 pages) - Third-Party Token-Based Authentication and Authorization for Session Initiation Protocol (SIP) [draft-ietf-sipcore-sip-token-authnz-17] (15 pages) - The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) [draft-ietf-sipcore-sip-websocket-10] (25 pages) - A SIP Response Code for Unwanted Calls [draft-ietf-sipcore-status-unwanted-06] (8 pages) - An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification [draft-ietf-sipcore-subnot-etags-04] (25 pages) - The Management Policy of the Resource Priority Header (RPH) Registry Changed to "IETF Review" [draft-rosen-rph-reg-policy-01] (2 pages) - The Session Initiation Protocol (SIP) Digest Authentication Scheme [draft-yusef-sipcore-digest-scheme-07] (8 pages) Requests for Comments: RFC5839: An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification (25 pages) RFC6026: Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests (20 pages) RFC6086: Session Initiation Protocol (SIP) INFO Method and Package Framework (36 pages) RFC6141: Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP) (26 pages) RFC6216: Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms (67 pages) RFC6223: Indication of Support for Keep-Alive (18 pages) RFC6228: Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog (14 pages) RFC6442: Location Conveyance for the Session Initiation Protocol (35 pages) * Updates RFC8262 * Updates RFC8787 RFC6446: Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control (25 pages) RFC6665: SIP-Specific Event Notification (53 pages) * Updates RFC7621 RFC6809: Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP) (19 pages) RFC6878: IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field (3 pages) RFC7044: An Extension to the Session Initiation Protocol (SIP) for Request History Information (36 pages) RFC7118: The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) (25 pages) RFC7131: Session Initiation Protocol (SIP) History-Info Header Call Flow Examples (52 pages) RFC7134: The Management Policy of the Resource Priority Header (RPH) Registry Changed to "IETF Review" (2 pages) RFC7614: Explicit Subscriptions for the REFER Method (14 pages) RFC7621: A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework (4 pages) RFC7647: Clarifications for the Use of REFER with RFC 6665 (6 pages) RFC7984: Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network (10 pages) RFC8197: A SIP Response Code for Unwanted Calls (8 pages) RFC8217: Clarifications for When to Use the name-addr Production in SIP Messages (6 pages) RFC8262: Content-ID Header Field in the Session Initiation Protocol (SIP) (14 pages) RFC8498: A P-Served-User Header Field Parameter for an Originating Call Diversion (CDIV) Session Case in the Session Initiation Protocol (SIP) (15 pages) RFC8599: Push Notification with the Session Initiation Protocol (SIP) (40 pages) RFC8606: ISDN User Part (ISUP) Cause Location Parameter for the SIP Reason Header Field (7 pages) RFC8688: A Session Initiation Protocol (SIP) Response Code for Rejected Calls (22 pages) RFC8760: The Session Initiation Protocol (SIP) Digest Access Authentication Scheme (9 pages) RFC8787: Location Source Parameter for the SIP Geolocation Header Field (8 pages) RFC8898: Third-Party Token-Based Authentication and Authorization for Session Initiation Protocol (SIP) (15 pages) RFC9366: Multiple SIP Reason Header Field Values (4 pages) Structured Email (sml) ---------------------- Charter Last Modified: 2024-04-16 Current Status: Active Chairs: Alexey Melnikov Arnt Gulbrandsen Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: sml@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sml Archive: https://mailarchive.ietf.org/arch/browse/sml/ Description of Working Group: Today, the content of many email messages is not manually written by users but generated by software. Those messages often have a transactional nature, such as notifications, confirmations, or receipts. Based on templates, their content typically follows a certain structure, even if written in natural language. Solutions like the Sieve filtering language [RFC5228] leverage such patterns in email structure, allowing users to deal with their emails in a more useful and efficient way. More recently, approaches to annotate text-based information on the Web with a machine-readable variant (e.g., SchemaOrgWeb) have been applied in the email domain (e.g., email markup). While some major vendors support this approach, adoption is still rather low and vendor implementations differ in various aspects. The Structured Email (SML) working group will develop standards track specifications for: * annotating human-readable email content with a machine-readable version, to allow for more reliable and accurate content analysis and processing; and * recommendations for security and trust mechanisms that should be applied when processing machine-readable content in email messages. It may also opt to publish a document illustrating and explaining relevant use cases. RDF/Schema.org will be the foundation for this work, since it is already used by vendors. The working group will specify how to use RDF/Schema.org in email messages to annotate email content. Vendors currently embed RDF/Schema.org data in a script tag within the text/html MIME body part. The working group needs to decide if this practice will be adopted, or if structured data should be added as a dedicated MIME part. This might be determined for both, the case that the machine-readable version is intended to be a partial representation of the human-readable content (similar to multipart-related) and for the case of providing a full representation (multipart/alternative). Hence, machine-readable data might essentially be added to a message by using MIME body parts. Different from conventional MIME body parts such as images, email clients will need additional specification about how to deal with this data, since it is intended for automated processing. Towards this end, the working group needs to discuss: * Which RDF encoding to use in which part of email messages * The usage and sharing of RDF vocabulary for actual annotation * How email clients should handle scenarios such as replying, forwarding, or embedded messages * Extensions (e.g., to email message formats [RFC5322,RFC2045] or IMAP flags [RFC9051]) that enable tools to efficiently determine if a message or parts of it are machine-readable * Security and trust recommendations to prevent abuse of structured email Structured email should leverage capabilities of the Internet Message Format [RFC5322] and ensure downwards-compatibility with legacy email clients. Users must still be able to consume email content, even if a machine-readable variant exists in parallel. The following points are out of scope for the working group: * Modeling RDF vocabulary for particular use cases or domains. Exceptions might only be made for vocabulary directly related to the email domain itself. If required, such work should be carried out in cooperation with appropriate bodies such as the Schema.org W3C Community Group. * The specification will not define how email recipient systems will use structured data once extracted from email messages. Specifications such as adding support for structured email to the Sieve language could however be addressed by a rechartering, once initial work has been finished. The working group aims to coordinate efforts with at least these related groups as required: * Active IETF working groups that deal with most of the IETF’s email activities * The Schema.org W3C Community Group (Schema.orgCG) * M3AAWG (in particular its Dynamic Email Security SIG) Goals and Milestones: Jun 2024 - Submit use case document to illustrate potential applications of this work to the IESG (Informational) Aug 2024 - WG adoption of a document discussing and recommending security and trust mechanisms that should be applied when processing machine-readable content in email messages Dec 2024 - Submit document that specifies core conventions on how machine-readable content should be included in email messages and how email clients and servers should interact in their processing to the IESG (Proposed Standard) Dec 2024 - Submit document document discussing and recommending security and trust mechanisms that should be applied when processing machine-readable content in email messages to the IESG (Proposed Standard) Done - WG adoption of a use case document to illustrate potential applications of this work Done - WG adoption of a document that specifies core conventions on how machine-readable content should be included in email messages and how email clients and servers should interact in their processing Internet-Drafts: - Structured vacation notices [draft-happel-sml-structured-vacation-notices-01] (11 pages) - Structured Email [draft-happel-structured-email-00] (11 pages) - Structured Email: Use cases [draft-happel-structured-email-use-cases-00] (9 pages) - Structured Email [draft-ietf-sml-structured-email-02] (13 pages) - Structured Email: Use cases [draft-ietf-sml-structured-email-use-cases-01] (12 pages) No Requests for Comments Secure Telephone Identity Revisited (stir) ------------------------------------------ Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Ben Campbell Robert Sparks Russ Housley Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Orie Steele Mailing Lists: General Discussion: stir@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/stir Archive: https://mailarchive.ietf.org/arch/browse/stir/ Description of Working Group: The STIR working group will specify Internet-based mechanisms that allow verification of the calling party's authorization to use a particular telephone number for an incoming call. Since it has become fairly easy to present an incorrect source telephone number, a growing set of problems have emerged over the last decade. As with email, the claimed source identity of a SIP request is not verified, permitting unauthorized use of the source identity as part of deceptive and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments). In addition, use of an incorrect source telephone number facilitates wire fraud or can lead to a return call at premium rates. SIP is one of the main VoIP technologies used by parties that want to present an incorrect origin, in this context an origin telephone number. Several previous efforts have tried to secure the origins of SIP communications, including RFC 3325, RFC 4474 (replaced by RFC 8224), and the VIPR working group. To date, however, true validation of the source of SIP calls has not seen any appreciable deployment. Several factors contributed to this lack of success, including: failure of the problem to be seen as critical at the time; lack of any technical means of producing a proof of authorization to use telephone numbers; misalignment of the mechanisms proposed by RFC 4474 with the complex deployment environment that has emerged for SIP; lack of end-to-end SIP session establishment; and inherent operational problems with a transitive trust model. To make deployment of this solution more likely, consideration must be given to latency, real-time performance, computational overhead, and administrative overhead for the legitimate call source and all verifiers. As its priority mechanism work item, the working group will specify and maintain a SIP header-based mechanism for verification that the originator of a SIP session is authorized to use the claimed source telephone number, where the session is established with SIP end to end. This is called an in-band mechanism. The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation. The working group will consider choices for protecting identity information and credentials used. This protection will likely be based on a digital signature mechanism that covers a set of information in the SIP header fields, and verification will employ a credential that contains the public key that is associated with the one or more telephone numbers. Credentials used with this mechanism will be derived from existing telephone number assignment and delegation models. That is, when a telephone number or range of telephone numbers is delegated to an entity, relevant credentials will be generated (or modified) to reflect such delegation. The mechanism must allow a telephone number holder to further delegate and revoke use of a telephone number without compromising the global delegation scheme. In addition to its priority mechanism work item, the working group will work on mechanisms for verification of the originator during session establishment in an environment with one or more non-SIP hops, most likely requiring an out-of-band authorization mechanism. It is important to note that while the main focus of this working group is telephone numbers, the STIR working group will not develop any mechanisms that require changes to circuit-switched technologies. Moreover, the work of this group is limited to developing a solution for telephone numbers. Expansion of the authorization mechanism to identities using the user@domain or other name forms is out of scope. The group will also consider extensions that leverage STIR to solve related identity problems around telephone calls and other telephone-number based communication, including call diversion and forwarding, rich identity presentation for delivery to a called party, messaging that uses telephone numbers, connected identity (mechanisms that identify the called party reached to the calling party), and similar use cases related to fraud and security. The working group will coordinate with the Security Area on credential management and signature mechanics. The working group will coordinate with other working groups in the ART Area regarding signaling through existing deployments. The working group welcomes input from potential implementors or operators of technologies developed by this working group. For example, national numbering authorities might consider acting as credential authorities for telephone numbers within their purview. Authentication and authorization of identity is closely linked to privacy, and these security features sometimes come at the cost of privacy. Anonymous calls are already defined in SIP standards, and this working group will not propose changes to these standards. In order to support anonymity, the working group will provide a solution in which the called party receives an indication that the source telephone number is unavailable. This working group, to the extent feasible, will specify privacy-friendly mechanisms that do not reveal any more information to user agents or third parties than a call that does not make use of secure telephone identification mechanisms. Goals and Milestones: - Identity Header Error Handling - Connected Identity for STIR - Messaging Use Cases and Extensions for STIR Nov 2019 - Submit PASSPorT Extension for rich call data for publication as Proposed Standard Mar 2020 - Submit Privacy analysis for Informational Done - Submit Assertion Values for a Resource Priority Header Claim in Support of Emergency Services Networks as Proposed Standard Done - Submit STIR Certificate Delegation as Proposed Standard Internet-Drafts: - Assertion Values for a Resource Priority Header Claim in Support of Emergency Services Networks [draft-dolly-stir-rph-emergency-services-00] (6 pages) - Enhanced JWT Claim Constraints for STIR Certificates [draft-housley-stir-enhance-rfc8226-00] (8 pages) - Secure Telephone Identity Revisited (STIR) Certificate Delegation [draft-ietf-stir-cert-delegation-04] (12 pages) - Secure Telephone Identity Credentials: Certificates [draft-ietf-stir-certificates-18] (24 pages) - OCSP Usage for Secure Telephone Identity Certificates [draft-ietf-stir-certificates-ocsp-08] (23 pages) - Short-Lived Certificates for Secure Telephone Identity [draft-ietf-stir-certificates-shortlived-00] (11 pages) - Enhanced JSON Web Token (JWT) Claim Constraints for Secure Telephone Identity Revisited (STIR) Certificates [draft-ietf-stir-enhance-rfc8226-05] (12 pages) - Handling of Identity Header Errors for Secure Telephone Identity Revisited (STIR) [draft-ietf-stir-identity-header-errors-handling-08] (7 pages) - Messaging Use Cases and Extensions for STIR [draft-ietf-stir-messaging-08] (12 pages) - Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and Use Cases [draft-ietf-stir-oob-07] (24 pages) - PASSporT: Personal Assertion Token [draft-ietf-stir-passport-11] (25 pages) - Personal Assertion Token (PASSporT) Extension for Diverted Calls [draft-ietf-stir-passport-divert-09] (17 pages) - PASSporT Extension for Rich Call Data [draft-ietf-stir-passport-rcd-26] (34 pages) - Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN) [draft-ietf-stir-passport-shaken-08] (9 pages) - Secure Telephone Identity Problem Statement and Requirements [draft-ietf-stir-problem-statement-05] (25 pages) - Authenticated Identity Management in the Session Initiation Protocol (SIP) [draft-ietf-stir-rfc4474bis-16] (46 pages) - Connected Identity for STIR [draft-ietf-stir-rfc4916-update-05] (15 pages) - Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization [draft-ietf-stir-rph-06] (10 pages) - Assertion Values for Resource Priority Header and SIP Priority Header Claims in Support of Emergency Services Networks [draft-ietf-stir-rph-emergency-services-07] (7 pages) - Out-of-Band STIR for Service Providers [draft-ietf-stir-servprovider-oob-06] (10 pages) - Secure Telephone Identity Threat Model [draft-ietf-stir-threats-04] (13 pages) - STIR Certificate Delegation [draft-peterson-stir-cert-delegation-00] (9 pages) - Messaging Use Cases and Extensions for STIR [draft-peterson-stir-messaging-01] (10 pages) - Out-of-Band STIR for Service Providers [draft-peterson-stir-servprovider-oob-01] (8 pages) Requests for Comments: RFC7340: Secure Telephone Identity Problem Statement and Requirements (25 pages) RFC7375: Secure Telephone Identity Threat Model (13 pages) RFC8224: Authenticated Identity Management in the Session Initiation Protocol (SIP) (46 pages) * Updates RFC8946 RFC8225: PASSporT: Personal Assertion Token (25 pages) RFC8226: Secure Telephone Identity Credentials: Certificates (24 pages) * Updates RFC9118 RFC8443: Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization (10 pages) RFC8588: Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN) (9 pages) RFC8816: Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and Use Cases (24 pages) RFC8946: Personal Assertion Token (PASSporT) Extension for Diverted Calls (17 pages) RFC9027: Assertion Values for Resource Priority Header and SIP Priority Header Claims in Support of Emergency Services Networks (7 pages) RFC9060: Secure Telephone Identity Revisited (STIR) Certificate Delegation (12 pages) RFC9118: Enhanced JSON Web Token (JWT) Claim Constraints for Secure Telephone Identity Revisited (STIR) Certificates (12 pages) RFC9410: Handling of Identity Header Errors for Secure Telephone Identity Revisited (STIR) (7 pages) RFC9475: Messaging Use Cases and Extensions for Secure Telephone Identity Revisited (STIR) (10 pages) Virtualized Conversations (vcon) -------------------------------- Charter Last Modified: 2023-12-06 Current Status: Active Chairs: Brian Rosen Chris Wendt Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: vcon@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/vcon Archive: https://mailarchive.ietf.org/arch/browse/vcon/ Description of Working Group: [https://github.com/dgpetrie/draft-petrie-vcon/blob/main/vcon_charter.md] Introduction and Group Overview The vCon ("Virtualized Conversations") working group is about passing conversational data. Such data is commonly generated and collected in business environments, from chat logs to transcripts to recordings. Most systems provide a way to store such information, but there are not many standards or interoperability within the storage or transmission mechanisms or formats. The two opposing forces influencing such information passing are trying to enforce privacy of personal data and providing the ability and interest to use conversations in various ways, e.g., AI analysis. For the first, the key is knowing what information exists, where it comes from, and being able to protect it appropriately; or being able to refer to conversations without exposing their contents or assure suitable redaction has been performed. For the second, the key is being able to integrate data between multiple systems (phones, chat systems, email, etc.), move data when transitioning from one software or provider to another, and so on. There is a lot of conversational data already being exchanged, but using proprietary formats and per-case engineered exchange solutions, from using FTP and other legacy components, to file naming conventions, and so on. There are also open source systems implementing vCon which may yield input to the requirements. The use of a standard for a conversation data container will focus on the following data exchange scenarios: * Communication System to Data Owner/Consumer * Data Owner/Consumer to Analysis or Storage Services * Analysis Services to Data Consumer The Communication System is an application, service or system which is able to capture the conversation metadata and the conversation. The Analysis Services will add data to an existing conversation data container. It should be noted that these entities are not always distinct. For example, the Communications System may also provide some analysis data. It should also be noted that these entities may also exist in multitude. For example, an enterprise may have a communication system for each mode (e.g., text, message, voice, video) or for each corporate product or division. In Scope The scope of the VCON working group is: (a) Standards Track RFC Output * Define a JSON based standard container and Media type to contain and/or reference conversational data, including call style metadata, recordings, data exchanged or presented in the conversations, conversation analysis, transcriptions, translations and annotations * Define/specify the use of an existing mechanism for proving integrity and optionally authenticity of the conversation data * Define/specify the use of an existing mechanism for encrypting of the objects enclosed in the vCon conversation data container to provide privacy of the participants and/or confidentiality of the data independent of transport such that some parts of the vCon may be disclosed to different parties * Determine if there is need for defining media types and standard containers for some small set of analysis, annotation or transcription data (b) Informational Internet Draft Output The Working Group may develop use cases in drafts for reference, but there is no expectation they will be published as an RFC. The use cases should include considerations for data minimization. The Working Group may consider the following as well as other use cases: * Contact Center Data Exchange * Non-Contact Center Data Exchange with Customer Relationship Management (CRM) * Conversations of Record including ECRIT Environments * Message History Data Exchange Out of Scope The following are out of scope: * Algorithms or methodologies for transcription, translation, redaction, analysis or annotation of call data * Real-time streaming or updating of conversational data * Transport mechanisms * Storage or databases specifications * Key management * API definitions * Definition of a new object security model. (It is expected that JOSE or other existing IETF technology is sufficient.) Privacy There are privacy matters relevant to transcripts of the sort VCON is meant to standardize. VCON itself does not attempt to address these concerns directly, as that is intended to be handled by metadata in the layers above VCON itself. However, the documents produced by this working group will discuss such considerations, and will not preclude support for conveying important notions such as user consent. Milestones * Specification for a JSON based container for conversation data * Recommendations or analysis of missing (not defined) data containers and media types for components of the conversation data Goals and Milestones: Dec 2023 - Adopt a draft to provide a specification for a JSON based container for conversation data (Proposed Standard) Dec 2023 - Adopt a draft containing recommendations or analysis of undefined data containers and media types for components of conversation data (Informational) Jun 2024 - Submit draft to provide a specification for a JSON based container for conversation data to the IESG (Proposed Standard) Jun 2024 - Submit draft containing recommendations or analysis of undefined data containers and media types for components of conversation data to the IESG (Informational) Internet-Drafts: - The CDDL format for vCon - Conversation Data Container [draft-ietf-vcon-vcon-container-00] (73 pages) No Requests for Comments Workload Identity in Multi System Environments (wimse) ------------------------------------------------------ Charter Last Modified: 2024-03-17 Current Status: Active Chairs: Justin Richer Pieter Kasselman Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Murray Kucherawy Tech Advisor: Paul Wouters Mailing Lists: General Discussion: wimse@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/wimse Archive: https://mailarchive.ietf.org/arch/browse/wimse/ Description of Working Group: Background & Motivation The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as a running instance of software executing for a specific purpose. This working group will focus on the unique identity and access management aspects of workloads at runtime and their execution context, particularly focusing on the propagation, representation, and processing of workload identities. Though the following items are relevant to the context of workloads, these items are not workloads and this working group will not define: * Static software identities and provenance, such as software bill of materials (SBOM) * Personal identities * Deployment chains * Supply chain management The rise of diverse service platforms and the drive for business flexibility, cost-efficiency, resilience, and compliance make maintaining least privilege access for workloads increasingly complex. As a result of the adoption of microservice architectures, services are composed of multiple workloads that need to authenticate to each other while making authorization decisions based on the original caller, their context, and the actions of other workloads that acted on a transaction. These workloads are often distributed across trust boundaries, without a single centralized controller managing the different identities or authorization policies. Workloads are often associated with complex context, including user identity, software origin, and hardware-based attestation. Communicating this context involves a unique set of challenges across different scenarios including multi-hop, long-lived and asynchronous transactions. While several standards and open-source projects offer foundational elements for secure workload identity, there remains a lack of clarity in their interoperation and combination. These technologies (specifically: OAuth, JWT, and SPIFFE) have been combined in a variety of ways in practice, but the solutions have existed in relative isolation. This ambiguity can lead to inconsistencies, interoperability issues, and potential security vulnerabilities. Goals The Workload Identity in Multi-Service Environments (WIMSE) working group is chartered to address the challenges associated with implementing fine-grained, least privilege access control for workloads deployed across multiple service platforms, spanning both public and private clouds. The work will build on existing standards, open source projects, and community practices, focusing on combining them in a coherent manner to address multi-service workload identity use cases such as those identified in the Workload Identity Use Cases I-D (draft-gilman-wimse-use-cases). The goal of the WIMSE working group is to identify, articulate, and bridge the gaps and ambiguities in workload identity problems and define solutions across a diverse set of platforms and deployments, building on various protocols used in workload environments. The WG will standardize solutions (as proposed standard) and document existing or best practices (as informational or BCP) per the Program of Work. While recognizing that the broader workload ecosystem uses a variety of application protocols (e.g., gRPC, Kafka and GraphQL), the WG will focus on only specific REST-based technologies using HTTP. WIMSE will also serve as a standing venue to discuss operational experience and requirements with workload identity. These discussions need not be restricted to technologies currently in scope to this charter. Dependencies and Liaisons The WIMSE working group will closely collaborate with: * Other IETF working groups that address topics related to identity, authentication, and authorization, including, but not limited to, OAuth, SCIM, SCITT, and RATS. * The Cloud Native Computing Foundation (CNCF), particularly with regard to the SPIFFE/SPIRE project. * The OpenID Foundation. Program of Work The WIMSE WG will focus on the following program of work: * [I] WIMSE architecture: The group will develop a document that defines common terminology, discusses workload attestation and identity, specifies a threat model, and defines a set of architectural components and several compositions of those components. The document will describe 2-3 scenarios and for each of them, it will identify key points needed for interoperability. * [PS] Securing service-to-service traffic: a JOSE-based WIMSE token solution to protect a chain of HTTP/REST calls, within and across trust domains. The document should support identification of microservices and cryptographic binding of the token to the caller’s identity and optionally, binding to the transaction. It should support associating context with the token, including but not limited to user identity, platform attestation, and SBOM artifacts. This deliverable includes both a token format and its usage, including binding to the caller’s identity. * [PS] Token issuance: A document describing a method for local issuance of WIMSE tokens where the local issuer operates with limited authority. The local issuer can be the workload itself or another workload deployed nearby. * [PS] Token exchange: Specify a protocol for exchanging an incoming token of one format for a workload-specific WIMSE token at security boundaries (possibly based on RFC 8693). Additionally, this token exchange will require specifying as proposed standard a small set of token exchange profiles (mapping of claims) between existing and new WIMSE token formats. * [I or BCP] Document and make recommendations based on operational experience to existing token distribution practices for workloads. Goals and Milestones: Nov 2024 - Submit informational document describing considerations for filesystem-based JWT delivery in Kubernetes to the IESG Mar 2025 - Submit proposed standard for a JOSE-based WIMSE token solution to protect a chain of HTTP/REST calls for workloads to the IESG Mar 2025 - Submit proposed standard document specifying a token exchange profile that maps claims from SPIFFE-identified services to OAuth-protected resources, and vice versa to the IESG Mar 2025 - Submit a proposed standard for a token exchange profile mapping the JWT BCP [RFC9068] to the JOSE-based WIMSE token to the IESG Nov 2025 - Submit a protocol as proposed standard for exchanging an incoming token of one format for a workload-specific token at security boundaries to the IESG Jul 2026 - Submit informational document describing the WIMSE architecture to the IESG Internet-Drafts: - Workload Identity in a Multi System Environment (WIMSE) Architecture [draft-ietf-wimse-arch-01] (12 pages) - WIMSE Service to Service Authentication [draft-ietf-wimse-s2s-protocol-00] (22 pages) - Best Current Practice for OAuth 2.0 Client Authentication in Workload Environments [draft-ietf-wimse-workload-identity-bcp-01] (10 pages) - Workload Identity in a Multi System Environment (WIMSE) Architecture [draft-salowey-wimse-arch-01] (11 pages) No Requests for Comments General Area Dispatch (gendispatch) ----------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Martin Vigoureux Shuping Peng General Area Directors: Roman Danyliw General Area Advisor: Roman Danyliw Mailing Lists: General Discussion: gendispatch@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/gendispatch Archive: https://mailarchive.ietf.org/arch/browse/gendispatch/ Description of Working Group: The GENDISPATCH working group is a DISPATCH-style working group (see RFC 7957) chartered to consider proposals for new work in the GEN area, including proposals for changes or improvements to the IETF process and process documents. GENDISPATCH is chartered to identify, or to help create, an appropriate venue for new work. GENDISPATCH will not consider any technical standardization work. Guiding principles for proposed new work include: 1. Providing a clear problem statement, historical context, motivation, and deliverables for the proposed new work. 2. Ensuring there has been adequate mailing list discussion reflecting sufficient interest, enough individuals have expressed a willingness to contribute (if appropriate given the subject matter of the proposal) and there is WG consensus before new work is dispatched. 3. Looking for and identifying commonalities and overlap among published or ongoing work in the GEN area, the IESG, the IAB, the IETF LLC, the IRTF, other SDOs, or the wider technical community. Options for handling new work include: - Directing the work to an existing WG. - Developing a proposal for a BOF. - Developing a charter for a new WG. - Making recommendations that documents be AD-sponsored (which ADs may or may not choose to follow). - Requesting that relevant bodies, including but not limited to the IESG, the IAB, the IRTF, or the IETF LLC, consider taking up the work in some form. - Deferring the decision for the new work. - Rejecting the new work. If GENDISPATCH decides that a particular topic needs to be addressed by a new WG, the normal IETF chartering process will be followed, including, for instance, IETF-wide review of the proposed charter. Proposals for large work efforts SHOULD lead to a BOF where the topic can be discussed in front of the entire IETF community. Documents progressed as AD-sponsored would typically include those that are extremely simple or make minor updates to existing process documents. Proposed new work may be deferred in cases where GENDISPATCH does not have enough information for the chairs to determine consensus. New work may be rejected in cases where there is not sufficient interest in GENDISPATCH or the proposal has been considered and rejected in the past, unless a substantially revised proposal is put forth, including compelling new reasons for accepting the work. A major objective of GENDISPATCH is to provide timely, clear dispositions of new efforts. Thus, where there is consensus to take on new work, GENDISPATCH will strive to quickly find a home for it (usually within a few months). While most new work in the GEN area is expected to be considered in GENDISPATCH, there may be times when that is not appropriate. At the discretion of the GEN AD, new efforts may follow other paths. For example, work may go directly to a BOF, may be initiated in other working groups when it clearly belongs in that group, or may be directly AD-sponsored. While it is inevitable that some discussion of the merits of a proposal brought to GENDISPATCH are necessary in order to evaluate the appropriate disposition of the proposal, GENDISPATCH is not chartered to actually do the work proposed. As part of the dispatch, a venue for further discussion should be identified. The existence of GENDISPATCH does not change the IESG's responsibilities and discretion as described in RFC 3710. Work related to the IAB, IRTF, and RFC Editor processes is out of scope, but when discussions in GENDISPATCH identify such work items, they can be suggested to those bodies for action. Goals and Milestones: Internet-Drafts: No Requests for Comments IPv6 over Networks of Resource-constrained Nodes (6lo) ------------------------------------------------------ Charter Last Modified: 2024-07-22 Current Status: Active Chairs: Carles Gomez Shwetha Bhandari Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: 6lo@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/6lo Archive: https://mailarchive.ietf.org/arch/browse/6lo/ Description of Working Group: 6lo focuses on the work that facilitates IPv6 connectivity over constrained node networks with the characteristics of: * limited power, memory and processing resources * hard upper bounds on state, code space and processing cycles * optimization of energy and network bandwidth usage * lack of some layer 2 services like complete device connectivity and broadcast/multicast Specifically, 6lo will work on: 1. IPv6-over-foo adaptation layer specifications using 6LoWPAN technologies (RFC4944, RFC6282, RFC6775) for link layer technologies of interest in constrained node networks 2. Information and data models (e.g., MIB modules) for these adaptation layers for basic monitoring and troubleshooting. 3. Specifications, such as low-complexity header compression, that are applicable to more than one adaptation layer specification 4. Maintenance and informational documents required for the existing IETF specifications in this space. Only specifications targeting constrained node networks are in scope. 6lo will work closely with the 6man working group, which will continue to work on IP-over-foo documents outside the constrained node network space and will continue to be the focal point for IPv6 maintenance. For adaptation layer specifications that do not have implications on IPv6 architecture, 6man will be notified about 6lo's working group last call. Specifications that might have such an impact (e.g., by using IPv6 addresses in a specific way or by introducing new ND options or by exposing to IPv6 a link model different from either Ethernet or 6lowpan) will be closely coordinated with 6man, and/or specific parts will be fanned out to 6man documents. Beyond 6man, 6lo will also coordinate with LWIG and INTAREA. 6lo works on small, focused pieces of work, but does not take on larger cross-layer efforts. The working group will continue to reuse existing protocols and mechanisms whenever reasonable and possible. Security and management work that is not specific to the link layers being worked on is out of scope. Work related to routing is out of scope. 6lo will coordinate closely with the working groups in other areas that focus on constrained node networks, such as ROLL (RTG) and CoRE (APP). Goals and Milestones: Mar 2015 - WG last call for draft-ietf-6lo-6lobac Mar 2015 - WG LC for draft-ietf-6lo-dect-ule Apr 2015 - WG adoption call for 6lo security related draft Done - WG decision on adoption for draft-schoenw-6lo-lowpan-mib Done - WG decision on adoption for draft-bormann-6lo-ghc Done - WG decision on adoption for draft-brandt-6man-lowpanz Done - WG decision on adoption for draft-ietf-6man-6lobac Done - WG decision on adoption of draft-mariager-6lowpan-v6over-dect-ule Done - WG adoption call for draft-hong-6lo-ipv6-over-nfc Done - WG LC for draft-ietf-6lo-btle Internet-Drafts: - Transmission of IPv6 Packets over PLC Networks [draft-hou-6lo-plc-05] (20 pages) - Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks [draft-ietf-6lo-6lobac-08] (27 pages) - Address-Protected Neighbor Discovery for Low-Power and Lossy Networks [draft-ietf-6lo-ap-nd-23] (29 pages) - IPv6 Backbone Router [draft-ietf-6lo-backbone-router-20] (32 pages) - IPv6 Mesh over BLUETOOTH(R) Low Energy Using the Internet Protocol Support Profile (IPSP) [draft-ietf-6lo-blemesh-10] (14 pages) - IPv6 over BLUETOOTH(R) Low Energy [draft-ietf-6lo-btle-17] (21 pages) - Packet Delivery Deadline Time in the Routing Header for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) [draft-ietf-6lo-deadline-time-05] (19 pages) - Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) [draft-ietf-6lo-dect-ule-09] (22 pages) - IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines [draft-ietf-6lo-dispatch-iana-registry-07] (9 pages) - Assignment of an Ethertype for IPv6 with Low-Power Wireless Personal Area Network (LoWPAN) Encapsulation [draft-ietf-6lo-ethertype-request-01] (5 pages) - IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Selective Fragment Recovery [draft-ietf-6lo-fragment-recovery-21] (28 pages) - 6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) [draft-ietf-6lo-ghc-05] (24 pages) - Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) [draft-ietf-6lo-lowpan-mib-04] (27 pages) - Transmission of IPv6 Packets over ITU-T G.9959 Networks [draft-ietf-6lo-lowpanz-08] (21 pages) - Mesh Link Establishment [draft-ietf-6lo-mesh-link-establishment-00] (19 pages) - On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network [draft-ietf-6lo-minimal-fragment-15] (12 pages) - An Extension to Mesh Link Establishment (MLE) for Host Identity Protocol Diet Exchange (HIP DEX) [draft-ietf-6lo-mle-hip-dex-01] (11 pages) - IPv6 Neighbor Discovery Multicast and Anycast Address Listener Subscription [draft-ietf-6lo-multicast-registration-19] (41 pages) - Transmission of IPv6 Packets over Near Field Communication [draft-ietf-6lo-nfc-22] (17 pages) - Transmission of IPv6 Packets over Short-Range Optical Wireless Communications [draft-ietf-6lo-owc-01] (16 pages) - IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch [draft-ietf-6lo-paging-dispatch-05] (8 pages) - Path-Aware Semantic Addressing (PASA) for Low power and Lossy Networks [draft-ietf-6lo-path-aware-semantic-addressing-07] (34 pages) - Transmission of IPv6 Packets over Power Line Communication (PLC) Networks [draft-ietf-6lo-plc-11] (20 pages) - IPv6 Neighbor Discovery Prefix Registration [draft-ietf-6lo-prefix-registration-04] (24 pages) - Privacy Considerations for IPv6 Adaptation-Layer Mechanisms [draft-ietf-6lo-privacy-considerations-04] (10 pages) - Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery [draft-ietf-6lo-rfc6775-update-21] (47 pages) - 6LoWPAN Routing Header [draft-ietf-6lo-routing-dispatch-05] (33 pages) - Transmission of SCHC-compressed packets over IEEE 802.15.4 networks [draft-ietf-6lo-schc-15dot4-06] (42 pages) - Applicability and Use Cases for IPv6 over Networks of Resource-constrained Nodes (6lo) [draft-ietf-6lo-use-cases-16] (24 pages) - Packet Delivery Deadline time in 6LoWPAN Routing Header [draft-lijo-6lo-expiration-time-04] (13 pages) - 6LoWPAN Selective Fragment Recovery [draft-thubert-6lo-fragment-recovery-01] (21 pages) - An Update to 6LoWPAN ND [draft-thubert-6lo-rfc6775-update-01] (22 pages) - LLN Minimal Fragment Forwarding [draft-watteyne-6lo-minimal-fragment-02] (7 pages) Requests for Comments: RFC7388: Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) (27 pages) RFC7400: 6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) (24 pages) RFC7428: Transmission of IPv6 Packets over ITU-T G.9959 Networks (21 pages) RFC7668: IPv6 over BLUETOOTH(R) Low Energy (21 pages) RFC7973: Assignment of an Ethertype for IPv6 with Low-Power Wireless Personal Area Network (LoWPAN) Encapsulation (5 pages) RFC8025: IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch (8 pages) RFC8065: Privacy Considerations for IPv6 Adaptation-Layer Mechanisms (10 pages) RFC8066: IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines (9 pages) RFC8105: Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) (22 pages) RFC8163: Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks (27 pages) RFC8505: Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery (47 pages) * Updates RFC8928 * Updates RFC8929 * Updates RFC9010 RFC8928: Address-Protected Neighbor Discovery for Low-Power and Lossy Networks (29 pages) RFC8929: IPv6 Backbone Router (32 pages) RFC8930: On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network (12 pages) RFC8931: IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Selective Fragment Recovery (28 pages) RFC9034: Packet Delivery Deadline Time in the Routing Header for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) (19 pages) RFC9159: IPv6 Mesh over BLUETOOTH(R) Low Energy Using the Internet Protocol Support Profile (IPSP) (14 pages) RFC9354: Transmission of IPv6 Packets over Power Line Communication (PLC) Networks (20 pages) RFC9428: Transmission of IPv6 Packets over Near Field Communication (17 pages) RFC9453: Applicability and Use Cases for IPv6 over Networks of Resource-constrained Nodes (6lo) (24 pages) IPv6 Maintenance (6man) ----------------------- Charter Last Modified: 2024-07-31 Current Status: Active Chairs: Bob Hinden Jen Linkova Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Erik Kline Mailing Lists: General Discussion: ipv6@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipv6 Archive: https://mailarchive.ietf.org/arch/browse/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. 6man is the design authority for extensions and modifications to the IPv6 protocol. The working group may, at its discretion, review any document produced in another working group that extends or modifies the IPv6 protocol and, in consultation with the responsible ADs of both working groups, may recommend to the IESG that 6man working group consensus is needed before any of those documents can progress for publication. Goals and Milestones: Jun 2021 - Investigate new Routing Headers, such as compact routing headers and safe replacement for RH0 Done - Submit PPP Compression Negotiation specification to IESG as a Proposed Standard Done - Determine way forward for ULA-C specification Done - Develop approach for IPv6 Fragmentation Done - Develop approaches for IPv6 Extension Headers (Hop-by-Hop and Destination) Done - Plan for advancing core IPv6 core specifications to Internet Standard Internet-Drafts: - Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6) [draft-ali-6man-spring-srv6-oam-03] (23 pages) - IPv6 Hop-by-Hop Header Handling [draft-baker-6man-hbh-header-handling-03] (9 pages) - Host routing in a multi-prefix network [draft-baker-6man-multi-homed-host-03] (9 pages) - RFC 6296bis IPv6-to-IPv6 Network Prefix Translation [draft-bctb-6man-rfc6296-bis-02] (36 pages) - The IPv6 Compact Routing Header (CRH) [draft-bonica-6man-comp-rtg-hdr-31] (14 pages) - Deprecation Of The IPv6 Router Alert Option [draft-bonica-6man-deprecate-router-alert-02] (8 pages) - Preference for IPv6 ULAs over IPv4 addresses in RFC6724 [draft-buraglio-6man-rfc6724-update-03] (12 pages) - Clarification of IPv6 Address Assignment Policy [draft-carpenter-6man-addr-assign-02] (7 pages) - Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers [draft-carpenter-6man-rfc6874bis-03] (11 pages) - Analysis of the 64-bit Boundary in IPv6 Addressing [draft-carpenter-6man-why64-01] (20 pages) - Entering IPv6 Zone Identifiers in User Interfaces [draft-carpenter-6man-zone-ui-04] (9 pages) - IPv6 Node Requirements [draft-clw-rfc6434-bis-01] (34 pages) - Signalling DHCPv6 Prefix Delegation Availability to Hosts [draft-collink-6man-pio-pflag-03] (12 pages) - Republishing the IPV6-MIB modules as obsolete [draft-fenner-ipv6-mibs-obsolete-02] (63 pages) - ICMPv6 errors for discarding packets due to processing limits [draft-herbert-6man-icmp-limits-03] (11 pages) - IPv6 Minimum Path MTU Hop-by-Hop Option [draft-hinden-6man-mtu-option-02] (14 pages) - Path MTU Discovery for IP version 6 [draft-hinden-6man-rfc1981bis-01] (16 pages) - Internet Protocol, Version 6 (IPv6) Specification [draft-hinden-6man-rfc2460bis-07] (36 pages) - IP Version 6 Addressing Architecture [draft-hinden-6man-rfc4291bis-06] (29 pages) - IPv6 Router Advertisement IPv6-Only Flag [draft-hinden-ipv4flag-04] (9 pages) - Stub Router Flag in ICMPv6 Router Advertisement Messages [draft-hui-6man-stub-router-ra-flag-00] (4 pages) - RFC 3627 to Historic Status [draft-ietf-6man-3627-historic-01] (3 pages) - Transmission of IPv6 over MS/TP Networks [draft-ietf-6man-6lobac-01] (20 pages) - Clarification of IPv6 Address Assignment Policy [draft-ietf-6man-addr-assign-00] (7 pages) - Distributing Address Selection Policy Using DHCPv6 [draft-ietf-6man-addr-select-opt-13] (12 pages) - Solution approaches for address-selection problems [draft-ietf-6man-addr-select-sol-03] (17 pages) - The IPv6 Compact Routing Header (CRH) [draft-ietf-6man-comp-rtg-hdr-10] (16 pages) - Duplicate Address Detection Proxy [draft-ietf-6man-dad-proxy-07] (16 pages) - Recommendation on Stable IPv6 Interface Identifiers [draft-ietf-6man-default-iids-16] (9 pages) - Generation of IPv6 Atomic Fragments Considered Harmful [draft-ietf-6man-deprecate-atomfrag-generation-08] (12 pages) - Deprecation Of The IPv6 Router Alert Option [draft-ietf-6man-deprecate-router-alert-01] (9 pages) - IPv6 Router Advertisement Options for DNS Configuration [draft-ietf-6man-dns-options-bis-08] (19 pages) - Limits on Sending and Processing IPv6 Extension Headers [draft-ietf-6man-eh-limits-15] (17 pages) - Enhanced Duplicate Address Detection [draft-ietf-6man-enhanced-dad-15] (11 pages) - Carrying Network Resource Partition (NRP) Information in IPv6 Extension Header [draft-ietf-6man-enhanced-vpn-vtn-id-07] (12 pages) - A Uniform Format for IPv6 Extension Headers [draft-ietf-6man-exthdr-06] (6 pages) - Transmission and Processing of IPv6 Extension Headers [draft-ietf-6man-ext-transmit-05] (10 pages) - IPv6 Flow Label Specification [draft-ietf-6man-flow-3697bis-07] (15 pages) - Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels [draft-ietf-6man-flow-ecmp-05] (9 pages) - Rationale for Update to the IPv6 Flow Label Specification [draft-ietf-6man-flow-update-07] (13 pages) - Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers [draft-ietf-6man-grand-07] (20 pages) - IPv6 Hop-by-Hop Options Processing Procedures [draft-ietf-6man-hbh-processing-20] (23 pages) - IANA Allocation Guidelines for the IPv6 Routing Header [draft-ietf-6man-iana-routing-header-00] (3 pages) - ICMPv6 Errors for Discarding Packets Due to Processing Limits [draft-ietf-6man-icmp-limits-08] (15 pages) - IPv6 Query for Enabled In-situ OAM Capabilities [draft-ietf-6man-icmpv6-ioam-conf-state-06] (16 pages) - Neighbor Unreachability Detection Is Too Impatient [draft-ietf-6man-impatient-nud-07] (8 pages) - Security and Privacy Considerations for IPv6 Address Generation Mechanisms [draft-ietf-6man-ipv6-address-generation-privacy-08] (18 pages) - IPv6 Application of the Alternate-Marking Method [draft-ietf-6man-ipv6-alt-mark-17] (20 pages) - Processing of IPv6 "Atomic" Fragments [draft-ietf-6man-ipv6-atomic-fragments-04] (9 pages) - The IPv6-Specific MIB Modules Are Obsolete [draft-ietf-6man-ipv6-mibs-obsolete-02] (65 pages) - IPv6 Router Advertisement IPv6-Only Flag [draft-ietf-6man-ipv6only-flag-05] (15 pages) - Architecture and Framework for IPv6 over Non-Broadcast Access [draft-ietf-6man-ipv6-over-wireless-06] (56 pages) - IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes [draft-ietf-6man-ipv6-subnet-model-12] (11 pages) - The Line-Identification Option [draft-ietf-6man-lineid-08] (17 pages) - Support for Adjustable Maximum Router Lifetimes per Link [draft-ietf-6man-maxra-04] (7 pages) - IPv6 Minimum Path MTU Hop-by-Hop Option [draft-ietf-6man-mtu-option-15] (20 pages) - Updates to the IPv6 Multicast Addressing Architecture [draft-ietf-6man-multicast-addr-arch-update-08] (10 pages) - IPv6 Multicast Address Scopes [draft-ietf-6man-multicast-scopes-07] (6 pages) - First-Hop Router Selection by Hosts in a Multi-Prefix Network [draft-ietf-6man-multi-homed-host-10] (13 pages) - Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery [draft-ietf-6man-nd-extension-headers-05] (10 pages) - IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags [draft-ietf-6man-ndpioiana-04] (4 pages) - Interface Identifier Assignment in IPv6 SLAAC [draft-ietf-6man-neighbor-inform-00] (17 pages) - IPv6 Node Requirements [draft-ietf-6man-node-req-bis-11] (30 pages) - Handling of Overlapping IPv6 Fragments [draft-ietf-6man-overlap-fragment-03] (6 pages) - Implications of Oversized IPv6 Header Chains [draft-ietf-6man-oversized-header-chain-09] (8 pages) - Signalling DHCPv6 Prefix per Client Availability to Hosts [draft-ietf-6man-pio-pflag-09] (12 pages) - Security Implications of Predictable Fragment Identification Values [draft-ietf-6man-predictable-fragment-id-10] (20 pages) - Using 127-Bit IPv6 Prefixes on Inter-Router Links [draft-ietf-6man-prefixlen-p2p-01] (8 pages) - Discovering PREF64 in Router Advertisements [draft-ietf-6man-ra-pref64-09] (10 pages) - IPv6 Router Advertisement Options for DNS Configuration [draft-ietf-6man-rdnss-rfc6106bis-16] (19 pages) - Reserved IPv6 Interface Identifiers [draft-ietf-6man-reserved-iids-03] (6 pages) - Packet-Loss Resiliency for Router Solicitations [draft-ietf-6man-resilient-rs-06] (6 pages) - Path MTU Discovery for IP version 6 [draft-ietf-6man-rfc1981bis-08] (19 pages) - Internet Protocol, Version 6 (IPv6) Specification [draft-ietf-6man-rfc2460bis-13] (42 pages) - Default Address Selection for Internet Protocol Version 6 (IPv6) [draft-ietf-6man-rfc3484bis-06] (32 pages) - Update to RFC 3484 Default Address Selection for IPv6 [draft-ietf-6man-rfc3484-revise-05] (12 pages) - IP Version 6 Addressing Architecture [draft-ietf-6man-rfc4291bis-09] (35 pages) - Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 [draft-ietf-6man-rfc4941bis-12] (20 pages) - IPv6 Node Requirements [draft-ietf-6man-rfc6434-bis-09] (42 pages) - Prioritizing known-local IPv6 ULAs through address selection policy [draft-ietf-6man-rfc6724-update-09] (17 pages) - Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers [draft-ietf-6man-rfc6874bis-09] (20 pages) - The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams [draft-ietf-6man-rpl-option-06] (9 pages) - An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL) [draft-ietf-6man-rpl-routing-header-07] (13 pages) - IPv6 Segment Routing Header (SRH) [draft-ietf-6man-segment-routing-header-26] (27 pages) - SRv6 Segment Identifiers in the IPv6 Addressing Architecture [draft-ietf-6man-sids-06] (8 pages) - Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events [draft-ietf-6man-slaac-renum-07] (15 pages) - SNAC Router Flag in ICMPv6 Router Advertisement Messages [draft-ietf-6man-snac-router-ra-flag-01] (4 pages) - Operations, Administration, and Maintenance (OAM) in Segment Routing over IPv6 (SRv6) [draft-ietf-6man-spring-srv6-oam-13] (19 pages) - A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) [draft-ietf-6man-stable-privacy-addresses-17] (19 pages) - A Recommendation for IPv6 Address Text Representation [draft-ietf-6man-text-addr-representation-07] (14 pages) - IPv6 and UDP Checksums for Tunneled Packets [draft-ietf-6man-udpchecksums-08] (12 pages) - Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums [draft-ietf-6man-udpzero-12] (40 pages) - Significance of IPv6 Interface Identifiers [draft-ietf-6man-ug-06] (10 pages) - Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers [draft-ietf-6man-uri-zoneid-06] (10 pages) - Analysis of the 64-bit Boundary in IPv6 Addressing [draft-ietf-6man-why64-08] (24 pages) - Entering IPv6 Zone Identifiers in User Interfaces [draft-ietf-6man-zone-ui-03] (10 pages) - Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol [draft-ietf-ipv6-compression-nego-v2-02] (7 pages) - IPv6 Router Advertisement Options for DNS Configuration [draft-jeong-6man-rdnss-rfc6106-bis-00] (18 pages) - Support for adjustable maximum router lifetimes per-link [draft-krishnan-6man-maxra-03] (6 pages) - Packet loss resiliency for Router Solicitations [draft-krishnan-6man-resilient-rs-01] (6 pages) - Segment Identifiers in SRv6 [draft-krishnan-6man-sids-00] (7 pages) - Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers [draft-linkova-6man-grand-01] (10 pages) - Discovering PREF64 in Router Advertisements [draft-pref64folks-6man-ra-pref64-02] (8 pages) - IPv6 Segment Routing Header (SRH) [draft-previdi-6man-segment-routing-header-08] (30 pages) - IPv6 Addresses for Ad Hoc Networks [draft-templin-6man-mla-24] (12 pages) - Architecture and Framework for IPv6 over Non-Broadcast Access [draft-thubert-6man-ipv6-over-wireless-15] (50 pages) - IPv6 ND PIO Flags IANA considerations [draft-troan-6man-ndpioiana-01] (4 pages) - IPv6 Query for Enabled In-situ OAM Capabilities [draft-xiao-6man-icmpv6-ioam-conf-state-02] (15 pages) Requests for Comments: RFC5172: Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol (7 pages) RFC5453: Reserved IPv6 Interface Identifiers (6 pages) RFC5722: Handling of Overlapping IPv6 Fragments (6 pages) * Updates RFC6946 RFC5871: IANA Allocation Guidelines for the IPv6 Routing Header (3 pages) RFC5942: IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes (11 pages) RFC5952: A Recommendation for IPv6 Address Text Representation (14 pages) RFC6106: IPv6 Router Advertisement Options for DNS Configuration (19 pages) * Obsoletes RFC8106 RFC6164: Using 127-Bit IPv6 Prefixes on Inter-Router Links (8 pages) * Updates RFC6547 RFC6434: IPv6 Node Requirements (30 pages) * Obsoletes RFC8504 RFC6436: Rationale for Update to the IPv6 Flow Label Specification (13 pages) RFC6437: IPv6 Flow Label Specification (15 pages) RFC6438: Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels (9 pages) RFC6547: RFC 3627 to Historic Status (3 pages) RFC6553: The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams (9 pages) * Updates RFC9008 RFC6554: An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL) (13 pages) RFC6564: A Uniform Format for IPv6 Extension Headers (6 pages) RFC6724: Default Address Selection for Internet Protocol Version 6 (IPv6) (32 pages) RFC6788: The Line-Identification Option (17 pages) RFC6874: Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers (10 pages) RFC6935: IPv6 and UDP Checksums for Tunneled Packets (12 pages) RFC6936: Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums (40 pages) RFC6946: Processing of IPv6 "Atomic" Fragments (9 pages) RFC6957: Duplicate Address Detection Proxy (16 pages) RFC6980: Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery (10 pages) RFC7045: Transmission and Processing of IPv6 Extension Headers (10 pages) RFC7048: Neighbor Unreachability Detection Is Too Impatient (8 pages) RFC7078: Distributing Address Selection Policy Using DHCPv6 (12 pages) RFC7112: Implications of Oversized IPv6 Header Chains (8 pages) RFC7136: Significance of IPv6 Interface Identifiers (10 pages) RFC7217: A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) (19 pages) RFC7346: IPv6 Multicast Address Scopes (6 pages) RFC7371: Updates to the IPv6 Multicast Addressing Architecture (10 pages) RFC7421: Analysis of the 64-bit Boundary in IPv6 Addressing (24 pages) RFC7527: Enhanced Duplicate Address Detection (11 pages) RFC7559: Packet-Loss Resiliency for Router Solicitations (6 pages) RFC7721: Security and Privacy Considerations for IPv6 Address Generation Mechanisms (18 pages) RFC7739: Security Implications of Predictable Fragment Identification Values (20 pages) RFC8021: Generation of IPv6 Atomic Fragments Considered Harmful (12 pages) RFC8028: First-Hop Router Selection by Hosts in a Multi-Prefix Network (13 pages) RFC8064: Recommendation on Stable IPv6 Interface Identifiers (9 pages) RFC8096: The IPv6-Specific MIB Modules Are Obsolete (65 pages) RFC8106: IPv6 Router Advertisement Options for DNS Configuration (19 pages) RFC8200: Internet Protocol, Version 6 (IPv6) Specification (42 pages) RFC8201: Path MTU Discovery for IP version 6 (19 pages) RFC8319: Support for Adjustable Maximum Router Lifetimes per Link (7 pages) RFC8425: IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags (4 pages) RFC8504: IPv6 Node Requirements (42 pages) RFC8754: IPv6 Segment Routing Header (SRH) (27 pages) RFC8781: Discovering PREF64 in Router Advertisements (10 pages) RFC8883: ICMPv6 Errors for Discarding Packets Due to Processing Limits (15 pages) RFC8981: Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 (20 pages) RFC9131: Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers (20 pages) RFC9259: Operations, Administration, and Maintenance (OAM) in Segment Routing over IPv6 (SRv6) (19 pages) RFC9268: IPv6 Minimum Path MTU Hop-by-Hop Option (20 pages) RFC9343: IPv6 Application of the Alternate-Marking Method (20 pages) RFC9631: The IPv6 Compact Routing Header (CRH) (14 pages) Adaptive DNS Discovery (add) ---------------------------- Charter Last Modified: 2022-05-03 Current Status: Active Chairs: David C Lawrence Glenn Deen Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: add@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/add Archive: https://mailarchive.ietf.org/arch/browse/add/ Description of Working Group: Sending DNS messages over encrypted transports, as defined in DNS over TLS (DoT) [RFC 7858] and DNS over HTTPS (DoH) [RFC 8484], provides benefits to the security and privacy of DNS data. Clients, such as applications and host operating systems, have started adopting these protocols to provide these user benefits. This working group will focus on discovery and selection of DNS resolvers by DNS clients in a variety of networking environments, including public networks, private networks, and VPNs, supporting both encrypted and unencrypted resolvers. It is chartered solely to develop technical mechanisms. Making any recommendations about specific policies for clients or servers is out of scope. Clients adopting encrypted DNS protocols need to determine which DNS servers support those protocols, and which server to use for specific queries if multiple servers are available. These decisions can vary based on the network environment, and also based on the content and purpose of the client queries. Network operators that start offering DNS encryption on their servers also need a way to indicate this support to clients. Communicating information about resolver configuration and behavior allows clients to make more informed decisions about which DNS servers to use. For example, a resolver may be able to resolve private or local names as a split DNS server. The Adaptive DNS Discovery (ADD) working group will work on the following deliverables: - Define a mechanism that allows clients to discover DNS resolvers that support encryption and that are available to the client either on the public Internet or on private or local networks. - Define a mechanism that allows communication of DNS resolver information to clients for use in selection decisions. This could be part of the mechanism used for discovery, above. - Develop an informational document that describes mechanisms for clients to detect specific network environments (such as captive portal and split horizon) and to use that information to inform their DNS configuration. This working group will coordinate with dnsop, doh, and dprive for any changes required in DNS protocols and will make sure that those groups are included in major document reviews at appropriate times. It will also work with capport to ensure that solutions are applicable to captive networks. Goals and Milestones: Internet-Drafts: - Requirements for Discovering Designated Resolvers [draft-box-add-requirements-02] (13 pages) - DHCP and Router Advertisement Options for Encrypted DNS Discovery [draft-btw-add-home-12] (32 pages) - Discovery of Designated Resolvers [draft-ietf-add-ddr-10] (16 pages) - DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR) [draft-ietf-add-dnr-16] (23 pages) - Encrypted DNS Server Redirection [draft-ietf-add-encrypted-dns-server-redirection-00] (13 pages) - Requirements for Discovering Designated Resolvers [draft-ietf-add-requirements-00] (13 pages) - DNS Resolver Information [draft-ietf-add-resolver-info-13] (11 pages) - Establishing Local DNS Authority in Validated Split-Horizon Environments [draft-ietf-add-split-horizon-authority-14] (25 pages) - Service Binding Mapping for DNS Servers [draft-ietf-add-svcb-dns-09] (10 pages) - Handling Encrypted DNS Server Redirection [draft-jt-add-dns-server-redirection-04] (13 pages) - Discovery of Equivalent Encrypted Resolvers [draft-pauly-add-deer-00] (11 pages) - Delegated Credentials to Host Encrypted DNS Forwarders on CPEs [draft-reddy-add-delegated-credentials-03] (15 pages) - Establishing Local DNS Authority in Split-Horizon Environments [draft-reddy-add-enterprise-split-dns-10] (16 pages) - DNS Resolver Information [draft-reddy-add-resolver-info-06] (8 pages) - Reputation Verified Selection of Upstream Encrypted Resolvers [draft-schwartz-add-ddr-forwarders-02] (13 pages) - Service Binding Mapping for DNS Servers [draft-schwartz-svcb-dns-04] (9 pages) Requests for Comments: RFC9461: Service Binding Mapping for DNS Servers (10 pages) RFC9462: Discovery of Designated Resolvers (16 pages) RFC9463: DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR) (23 pages) RFC9606: DNS Resolver Information (10 pages) BPF/eBPF (bpf) -------------- Charter Last Modified: 2023-06-27 Current Status: Active Chairs: David Vernet Suresh Krishnan Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Erik Kline Tech Advisors: Alexei Starovoitov Christoph Hellwig Dave Thaler Mailing Lists: General Discussion: bpf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/bpf Archive: https://mailarchive.ietf.org/arch/browse/bpf/ Description of Working Group: eBPF (which is no longer an acronym for anything), also commonly referred to as BPF, is a technology with origins in the Linux kernel that can run untrusted programs in a privileged context such as the operating system kernel. BPF is increasingly being used beyond just the Linux kernel, with implementations in network interface cards, Microsoft Windows, etc. The BPF working group is initially tasked with documenting the existing state of the BPF ecosystem, and creating a clear process for extensions, including initial extensions that are widely useful and showcase the process. The working group will not adopt work focused on new versions or extensions until all documents required to capture the existing goals, particularly those in the bullets below, have completed IESG approval. The working group will produce one or more documents on the following work item topics (with intended document status annotations, e.g. [PS] Proposed Standard and [I] Informational): * [PS] the BPF instruction set architecture (ISA) that defines the instructions and low-level virtual machine for BPF programs, * [I] verifier expectations and building blocks for allowing safe execution of untrusted BPF programs, * [PS] the BPF Type Format (BTF) that defines debug information and introspection capabilities for BPF programs, * [I] one or more documents that recommend conventions and guidelines for producing portable BPF program binaries, * [PS] cross-platform map types allowing native data structure access from BPF programs, * [PS] cross-platform helper functions, e.g., for manipulation of maps, * [PS] cross-platform BPF program types that define the higher level execution environment for BPF programs, and * [I] an architecture and framework document. The BPF working group shall actively engage the BPF Foundation steering committee and the broader implementation community to ensure inclusion in the IETF's consensus-driven process. The working group is intended to only work on cross-platform aspects of BPF that are useful to the wider internet community and are not otherwise operating system or platform specific. Goals and Milestones: Mar 2024 - eBPF Instruction Set Specification [wg adoption] Internet-Drafts: - BPF Instruction Set Architecture (ISA) [draft-ietf-bpf-isa-04] (46 pages) No Requests for Comments DNS Delegation (deleg) ---------------------- Charter Last Modified: 2024-06-26 Current Status: Active Chairs: Brian Haberman Duane Wessels Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Warren Kumari Secretary: Tommy Jensen Mailing Lists: General Discussion: dd@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dd Archive: https://mailarchive.ietf.org/arch/browse/dd/ Description of Working Group: # Background and Problem Space The DNS protocol has limited ability for authoritative servers to signal their capabilities to recursive resolvers. In part, this stems from the lack of a mechanism for parents (often registries) to specify additional information about child delegations (often registrants) beyond NS, DS, and glue records. Further complicating matters is the similar lack of a mechanism for a registrant to signal that the operation of a delegation point is being outsourced to a different operator, leaving a challenge when operators need to update parental information that is only in the control of the child. Data is often out of synchronization between parents and children, which causes significant operational problems. # Objective and Scope To address these challenges, the DELEG working group will first document the requirements for adding a new DNS signaling mechanism that allows parents to return additional DNS delegation information about their children. This includes the requirement for the new mechanism to interoperate with the existing DNS and to not break DNS resolvers and clients that are not aware of it. In addition, this document could also list the other types of information not available today that might be provided over a designed signaling mechanism. The first use cases for the working group will be new DNS authoritative signaling mechanisms for alternative DNS transports, and delegation aliasing (where the parent returns a pointer to the service provider that will then return the needed delegation information). The working group should also consider how well different solutions can be deployed, and should study possible consequences of deploying alternative delegation mechanisms. The working group will then define the semantics of a new DNS signaling mechanism, taking future extensibility into account. The working group will specify extensions to the DNS. The initial version of the requirements document should have broad general consensus and must be adopted by the WG before work on the solution documents begins. - The WG will coordinate closely with other WGs, including DNSOP, ADD, and other working groups and directorates as appropriate. This is especially true for WG adoption and Last Calls. # Deliverables - A document listing the requirements for a new signaling mechanism allowing parents to return additional information when communicating about a delegated child. This is expected to be published as an informational RFC. - A specification defining the new delegation information distribution mechanism. The WG will carry out an operational impact assessment and include corresponding operational and deployment considerations sections in the specification. The specification will include a concept of operations that describes how both current and future systems will interact in an Internet-wide interoperable way. This is expected to be published as a standards-track RFC. - A specification for how to use the new delegation information to perform aliasing of delegation information. This is expected to be published as a standards-track RFC. - A specification for facilitating the use of additional transports for DNS. This is expected to be published as a standards-track RFC. Goals and Milestones: Dec 2024 - A document listing the requirements for a new signaling mechanism allowing parents to return additional information when communicating about a delegated child. Feb 2025 - A specification defining the new delegation information distribution mechanism. Jun 2025 - A specification for how to use the new delegation information to perform aliasing of delegation information. Dec 2025 - A specification for facilitating the use of additional transports for DNS. Internet-Drafts: - Problem Statement and Requirements for an Improved DNS Delegation Mechanism abbrev: DNS DELEG Requirements [draft-ietf-deleg-requirements-00] (6 pages) - Problem Statement and Requirements for an Improved DNS Delegation Mechanism abbrev: DNS DELEG Requirements [draft-wirelela-deleg-requirements-01] (7 pages) No Requests for Comments Dynamic Host Configuration (dhc) -------------------------------- Charter Last Modified: 2023-02-27 Current Status: Active Chairs: Bernie Volz Timothy Winters Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: dhcwg@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dhcwg Archive: https://mailarchive.ietf.org/arch/browse/dhcwg/ Description of Working Group: The Dynamic Host Configuration Working Group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses, IPv6 prefixes, IP protocol stack and other parameters. DHCPv4 is currently a Draft Standard and is documented in RFC 2131 and RFC 2132. DHCPv6 is currently a Proposed Standard and is being updated. The WG plans to advance the DHCPv6 protocol to Internet standard. The DHC WG is responsible for defining DHCP protocol extensions. Definitions of new DHCP options that are delivered using standard mechanisms with documented semantics are not considered a protocol extension and thus are generally outside of scope for the DHC WG. Such options should be defined within their respective WGs or sponsored by an appropriate AD and reviewed by DHCP experts in the Internet Area Directorate. However, if such options require protocol extensions or new semantics, the protocol extension work must be done in the DHC WG. The DHC WG has the following main objectives: 1. Work on informational documents providing operational or implementation advice about DHCPv6, as well as documents specifying standard mechanisms for operating, administering and managing DHCPv6 servers, clients, and relay agents. 2. Assist other WGs and independent submissions in defining options (that follow RFC 7227 guidelines) and to assure DHCP operational considerations are properly documented. 3. Issue an updated version of the DHCPv6 base specification, and after an appropriate interval following publication, advance to Internet standard. Goals and Milestones: Dec 2024 - Advance DHCPv6 RFC to Internet Standard Jul 2025 - Recharter or close down WG Done - WGLC draft-ietf-dhc-dhcp4o6-saddr-opt Done - WGLC SLAP quadrant selection options for DHCPv6 Done - WGLC Link-Layer Addresses Assignment Mechanism for DHCPv6 Done - Adopt IPv6-Only-Preferred Option for DHCP Done - Adopt DHCPv6 Prefix Delegating relay Done - WGLC Multi-requirement Extensions for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Done - WGLC DHCPv6 Prefix Delegating relay Done - WGLC IPv6-Only-Preferred Option for DHCP Done - WGLC draft-ietf-dhc-dhcpv6-yang Done - WGLC for Registering Self-generated IPv6 Addresses using DHCPv6 Internet-Drafts: - SLAP quadrant selection options for DHCPv6 [draft-bernardos-dhc-slap-quadrant-01] (15 pages) - Access-Network-Identifier Option in DHCP [draft-bhandari-dhc-access-network-identifier-04] (17 pages) - Link-Layer Addresses Assignment Mechanism for DHCPv6 [draft-bvtm-dhc-mac-assign-02] (18 pages) - Dynamic Allocation of Shared IPv4 Addresses [draft-csf-dhc-dynamic-shared-v4allocation-00] (13 pages) - Handling Unknown DHCPv6 Messages [draft-csl-dhc-dhcpv6-unknown-msg-3315update-00] (4 pages) - DHCPv6 Prefix Length Hint Issues [draft-cui-dhc-dhcpv6-prefix-length-hint-issue-03] (9 pages) - YANG Data Model for DHCPv6 Configuration [draft-cui-dhc-dhcpv6-yang-04] (81 pages) - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis [draft-dhcwg-dhc-rfc3315bis-04] (126 pages) - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-dhcwg-dhc-rfc8415bis-00] (135 pages) - Forcerenew Reconfiguration Extensions for DHCPv4 [draft-fang-dhc-dhcpv4-forcerenew-extensions-02] (7 pages) - DHCPv6 Prefix Delegating relay [draft-fkhp-dhc-dhcpv6-pd-relay-requirements-03] (11 pages) - DHCPv4 over DHCPv6 Source Address Option [draft-fsc-softwire-dhcp4o6-saddr-opt-07] (9 pages) - DHCP Relay Initiated Release [draft-gandhewar-dhc-relay-initiated-release-01] (11 pages) - DHCPv6 Relay Initiated Release [draft-gandhewar-dhc-v6-relay-initiated-release-01] (14 pages) - A Method for Generating Semantically Opaque Interface Identifiers with Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-gont-dhc-stable-privacy-addresses-01] (8 pages) - Anonymity profile for DHCP clients [draft-huitema-dhc-anonymity-profile-02] (19 pages) - Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) [draft-ietf-dhc-3315id-for-v4-05] (12 pages) - IEEE 802.11 parameters DHCP Option [draft-ietf-dhc-80211-option-01] (5 pages) - Triggering AAA from DHCP Relay Agents [draft-ietf-dhc-aaa-ra-00] (7 pages) - Authentication, Authorization, and Accounting Requirements for Roaming Nodes using DHCP [draft-ietf-dhc-aaa-requirements-00] (8 pages) - Access-Network-Identifier Option in DHCP [draft-ietf-dhc-access-network-identifier-13] (20 pages) - Registering Self-generated IPv6 Addresses using DHCPv6 [draft-ietf-dhc-addr-notification-13] (19 pages) - Registering Self-generated IPv6 Addresses in DNS using DHCPv6 [draft-ietf-dhc-addr-registration-07] (10 pages) - DHCP Relay Agent Information Option [draft-ietf-dhc-agent-options-11] (14 pages) - The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option [draft-ietf-dhc-agentoptions-device-class-04] (5 pages) - Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option [draft-ietf-dhc-agentopt-radius-08] (8 pages) - Link Selection sub-option for the Relay Agent Information Option for DHCPv4 [draft-ietf-dhc-agent-subnet-selection-04] (9 pages) - Virtual Subnet Selection Sub-Option for the Relay Agent Information Option for DHCPv4 [draft-ietf-dhc-agent-vpn-id-06] (11 pages) - Anonymity Profiles for DHCP Clients [draft-ietf-dhc-anonymity-profile-08] (26 pages) - The Autonomous System Option for DHCP [draft-ietf-dhc-asnum-00] (5 pages) - Authentication for DHCP Messages [draft-ietf-dhc-authentication-16] (17 pages) - DHCP RSA/DSA Authentication using DNS KEY records [draft-ietf-dhc-auth-sigzero-00] (0 pages) - The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option [draft-ietf-dhc-auth-suboption-05] (15 pages) - DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients [draft-ietf-dhc-autoconfig-04] (9 pages) - Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers [draft-ietf-dhc-bcmc-options-05] (11 pages) - DHCPv4 Options for Broadcast and Multicast Control Servers [draft-ietf-dhc-bcmcv4-option-00] (12 pages) - DHCPv6 Options for Broadcast and Multicast Control Servers [draft-ietf-dhc-bcmcv6-option-00] (14 pages) - Interoperation Between DHCP and BOOTP [draft-ietf-dhc-between-bootp-02] (4 pages) - Clarifications and Extensions for the Bootstrap Protocol [draft-ietf-dhc-bootp-01] (22 pages) - DHCP Options for Call Control Servers [draft-ietf-dhc-callcontrolserv-00] (4 pages) - Configuring Cryptographically Generated Addresses (CGA) using DHCPv6 [draft-ietf-dhc-cga-config-dhcpv6-04] (10 pages) - Client Identifier Option in DHCP Server Replies [draft-ietf-dhc-client-id-07] (5 pages) - Interpreting Client Options for the Dynamic Host Configuration Protocol [draft-ietf-dhc-client-options-00] (24 pages) - Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4) [draft-ietf-dhc-concat-05] (9 pages) - IP Connectivity Status Notifications for DHCPv6 [draft-ietf-dhc-conn-status-00] (10 pages) - Container Option for Server Configuration [draft-ietf-dhc-container-opt-07] (9 pages) - The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4 [draft-ietf-dhc-csr-07] (9 pages) - Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients [draft-ietf-dhc-ddns-resolution-12] (13 pages) - Dynamic Host Configuration Protocol [draft-ietf-dhc-dhcp-08] (45 pages) - Softwire Provisioning Using DHCPv4 over DHCPv6 [draft-ietf-dhc-dhcp4o6-saddr-opt-08] (18 pages) - Interaction between DHCP and DNS [draft-ietf-dhc-dhcp-dns-12] (19 pages) - Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications [draft-ietf-dhc-dhcpinform-clarify-06] (9 pages) - Privacy Considerations for DHCP [draft-ietf-dhc-dhcp-privacy-05] (14 pages) - Extensions to DHCP for Roaming Users [draft-ietf-dhc-dhcproam-00] (15 pages) - Active DHCPv4 Lease Query [draft-ietf-dhc-dhcpv4-active-leasequery-07] (28 pages) - DHCPv4 Bulk Leasequery [draft-ietf-dhc-dhcpv4-bulk-leasequery-07] (41 pages) - Forcerenew Reconfiguration Extensions for DHCPv4 [draft-ietf-dhc-dhcpv4-forcerenew-extensions-02] (7 pages) - DHCPv4-over-DHCPv6 (DHCP 4o6) Transport [draft-ietf-dhc-dhcpv4-over-dhcpv6-09] (16 pages) - DHCPv4 over IPv6 Transport [draft-ietf-dhc-dhcpv4-over-ipv6-09] (14 pages) - DHCPv4 Vendor-specific Message [draft-ietf-dhc-dhcpv4-vendor-message-01] (7 pages) - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ietf-dhc-dhcpv6-28] (101 pages) - DHCPv6 Active Leasequery [draft-ietf-dhc-dhcpv6-active-leasequery-04] (30 pages) - DHCPv6 Relay Agent Assignment Notification (RAAN) Option [draft-ietf-dhc-dhcpv6-agentopt-delegate-05] (9 pages) - DHCPv6 Bulk Leasequery [draft-ietf-dhc-dhcpv6-bulk-leasequery-06] (18 pages) - Clarifications on DHCPv6 Authentication [draft-ietf-dhc-dhcpv6-clarify-auth-01] (14 pages) - Client Link-Layer Address Option in DHCPv6 [draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-05] (7 pages) - Configured Tunnel End Point Option for DHCPv6 [draft-ietf-dhc-dhcpv6-ctep-opt-02] (6 pages) - DHCPv6 Relay Agent Echo Request Option [draft-ietf-dhc-dhcpv6-ero-01] (6 pages) - Extensions for the Dynamic Host Configuration Protocol for IPv6 [draft-ietf-dhc-dhcpv6exts-12] (39 pages) - DHCPv6 Failover Design [draft-ietf-dhc-dhcpv6-failover-design-04] (59 pages) - DHCPv6 Failover Protocol [draft-ietf-dhc-dhcpv6-failover-protocol-06] (96 pages) - DHCPv6 Failover Requirements [draft-ietf-dhc-dhcpv6-failover-requirements-07] (17 pages) - The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option [draft-ietf-dhc-dhcpv6-fqdn-05] (15 pages) - Results from Interoperability Tests of DHCPv6 Implementations [draft-ietf-dhc-dhcpv6-interop-01] (12 pages) - Lightweight DHCPv6 Relay Agent [draft-ietf-dhc-dhcpv6-ldra-03] (17 pages) - DHCPv6 Leasequery [draft-ietf-dhc-dhcpv6-leasequery-01] (23 pages) - Load Balancing for DHCPv6 [draft-ietf-dhc-dhcpv6-loadb-02] (6 pages) - Load Balancing for DHCPv6 [draft-ietf-dhc-dhcpv6-load-balancing-02] (6 pages) - DHCPv6 Options for LWM2M bootstrap information [draft-ietf-dhc-dhcpv6-lwm2m-bootstrap-options-00] (10 pages) - Client Preferred Prefix option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-cliprefprefix-01] (6 pages) - DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ietf-dhc-dhcpv6-opt-dnsconfig-04] (7 pages) - Domain Suffix Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-dnsdomain-04] (7 pages) - DSTM Options for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-dstm-01] (7 pages) - DSTM Ports Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-dstm-ports-01] (4 pages) - DHCPv6 Options for Network Boot [draft-ietf-dhc-dhcpv6-opt-netboot-10] (11 pages) - Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ietf-dhc-dhcpv6-opt-nisconfig-05] (7 pages) - The Name Service Search Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-nss-00] (6 pages) - IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 [draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05] (19 pages) - DHCPv6 Support for Remote Boot [draft-ietf-dhc-dhcpv6-opt-rboot-00] (6 pages) - Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-sntp-01] (5 pages) - Time Configuration Options for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-timeconfig-03] (8 pages) - Timezone Specifier Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-tz-00] (6 pages) - DHCPv6 Prefix Delegating Relay Requirements [draft-ietf-dhc-dhcpv6-pd-relay-requirements-05] (11 pages) - DHCPv6 Prefix-Length Hint Issues [draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-06] (9 pages) - Prefix Pool Option for DHCPv6 Relay Agent on the Provider Edge Routers [draft-ietf-dhc-dhcpv6-prefix-pool-opt-03] (13 pages) - Privacy Considerations for DHCPv6 [draft-ietf-dhc-dhcpv6-privacy-05] (18 pages) - RADIUS Option for the DHCPv6 Relay Agent [draft-ietf-dhc-dhcpv6-radius-opt-14] (10 pages) - Rebind Capability in DHCPv6 Reconfigure Messages [draft-ietf-dhc-dhcpv6-reconfigure-rebind-10] (10 pages) - DHCPv6 Redundancy Deployment Considerations [draft-ietf-dhc-dhcpv6-redundancy-consider-03] (16 pages) - Relay-Supplied DHCP Options [draft-ietf-dhc-dhcpv6-relay-supplied-options-09] (8 pages) - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option [draft-ietf-dhc-dhcpv6-remoteid-01] (6 pages) - Time Protocol Servers and Time Offset Options for IPv6 DHCP [draft-ietf-dhc-dhcpv6-rfc868-servers-00] (6 pages) - Modification to Default Values of SOL_MAX_RT and INF_MAX_RT [draft-ietf-dhc-dhcpv6-solmaxrt-update-05] (7 pages) - DHCPv6 Server Reply Sequence Number Option [draft-ietf-dhc-dhcpv6-srsn-option-02] (7 pages) - Issues and Recommendations with Multiple Stateful DHCPv6 Options [draft-ietf-dhc-dhcpv6-stateful-issues-12] (24 pages) - Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 [draft-ietf-dhc-dhcpv6-stateless-04] (9 pages) - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option [draft-ietf-dhc-dhcpv6-subid-01] (6 pages) - DHCPv6 through Tunnels [draft-ietf-dhc-dhcpv6-tunnel-01] (5 pages) - Handling Unknown DHCPv6 Messages [draft-ietf-dhc-dhcpv6-unknown-msg-08] (7 pages) - DHCPv6 Vendor-specific Message [draft-ietf-dhc-dhcpv6-vendor-message-01] (6 pages) - A YANG Data Model for DHCPv6 Configuration [draft-ietf-dhc-dhcpv6-yang-25] (92 pages) - DHCPv6 Leasequery [draft-ietf-dhc-dhcvp6-leasequery-01] (21 pages) - Detecting Network Attachment in IPv4 (DNAv4) [draft-ietf-dhc-dna-ipv4-18] (15 pages) - Populating the DNS Reverse Tree for DHCP Delegated Prefixes [draft-ietf-dhc-dns-pd-01] (13 pages) - The Domain Search Option for DHCP [draft-ietf-dhc-domsrch-02] (4 pages) - Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues [draft-ietf-dhc-dual-stack-04] (14 pages) - Dual-stack clients and merging of data from DHCPv4 and DHCPv6 [draft-ietf-dhc-dual-stack-merge-01] (8 pages) - Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID) [draft-ietf-dhc-duid-uuid-03] (5 pages) - Dynamic Allocation of Shared IPv4 Addresses [draft-ietf-dhc-dynamic-shared-v4allocation-09] (15 pages) - Subnet Configuration Option Set for DHCP [draft-ietf-dhc-dyn-subnet-conf-02] (14 pages) - Requirements for Extending DHCP into New Environments [draft-ietf-dhc-enhance-requirements-00] (15 pages) - Extending DHCP Options Codes [draft-ietf-dhc-extended-optioncodes-00] (9 pages) - DHCP Failover Protocol [draft-ietf-dhc-failover-12] (133 pages) - Forcerenew Nonce Authentication [draft-ietf-dhc-forcerenew-nonce-07] (12 pages) - An option for FQDNs in DHCP options [draft-ietf-dhc-fqdn-opt-03] (4 pages) - The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option [draft-ietf-dhc-fqdn-option-13] (17 pages) - Prefix Assignment in DHCPv6 [draft-ietf-dhc-host-gen-id-05] (11 pages) - Considerations for the use of the Host Name option [draft-ietf-dhc-host-option-considerations-02] (8 pages) - Implementation Issues with RFC 2131, "Dynamic Host Configuration Protocol (DHCPv4)" [draft-ietf-dhc-implementation-02] (41 pages) - An Inter-server Protocol for DHCP [draft-ietf-dhc-interserver-02] (89 pages) - An Inter-server Protocol for DHCP [draft-ietf-dhc-interserver-alt-00] (53 pages) - Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network [draft-ietf-dhc-ipv4-autoconfig-05] (8 pages) - The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service [draft-ietf-dhc-isnsoption-13] (13 pages) - Wireless Key Management using DHCP [draft-ietf-dhc-key-management-00] (0 pages) - Layer 2 Relay Agent Information [draft-ietf-dhc-l2ra-06] (13 pages) - Extensions to Layer 2 Relay Agent [draft-ietf-dhc-l2ra-extensions-01] (22 pages) - LDAP Schema for DHCP [draft-ietf-dhc-ldap-schema-00] (18 pages) - Dynamic Host Configuration Protocol (DHCP) Leasequery [draft-ietf-dhc-leasequery-09] (27 pages) - DHCPv4 Lease Query by Relay Agent Remote ID [draft-ietf-dhc-leasequery-by-remote-id-09] (13 pages) - Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ietf-dhc-lifetime-03] (8 pages) - DHC Load Balancing Algorithm [draft-ietf-dhc-loadb-03] (10 pages) - Link-Layer Address Assignment Mechanism for DHCPv6 [draft-ietf-dhc-mac-assign-09] (18 pages) - Multicast address allocation extensions to the Dynamic Host Configuration Protocol [draft-ietf-dhc-mdhcp-03] (14 pages) - The Migration Agent List Option for DHCP [draft-ietf-dhc-migagntlist-00] (4 pages) - DHCP Option for Mobile IP Mobility Agents [draft-ietf-dhc-mipadvert-opt-02] (15 pages) - Multicast Address Allocation Configuration Options [draft-ietf-dhc-multopt-03] (5 pages) - The Named Pool Request Option for DHCP [draft-ietf-dhc-namedpool-00] (4 pages) - NetWare/IP Domain Name and Information [draft-ietf-dhc-netware-options-00] (6 pages) - Procedure for Defining New DHCP Options [draft-ietf-dhc-new-options-05] (5 pages) - Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types [draft-ietf-dhc-new-opt-msg-02] (7 pages) - New Option Review Guidelines for DHCP [draft-ietf-dhc-new-opt-review-00] (8 pages) - DHCP Next Server Option [draft-ietf-dhc-nextserver-02] (0 pages) - The Name Service Search Option for DHCP [draft-ietf-dhc-nsso-05] (5 pages) - The Extended Remote Boot Option for DHCPv4 [draft-ietf-dhc-opt-extrboot-00] (7 pages) - Guidelines for Creating New DHCPv6 Options [draft-ietf-dhc-option-guidelines-17] (35 pages) - New Option Review Guidelines and Additional Option Namespace [draft-ietf-dhc-option-review-and-namespace-02] (14 pages) - DHCP Options and BOOTP Vendor Extensions [draft-ietf-dhc-options-03] (30 pages) - DHCP Options and BOOTP Vendor Extensions [draft-ietf-dhc-options-1533update-05] (34 pages) - DHCP Continuation Option Code [draft-ietf-dhc-options-cont-01] (3 pages) - An Extension to the DHCP Option Codes [draft-ietf-dhc-options-opt127-03] (3 pages) - DHCP Option for The Open Group's User Authentication Protocol [draft-ietf-dhc-options-uap-02] (4 pages) - DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents [draft-ietf-dhc-paa-option-05] (8 pages) - Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration [draft-ietf-dhc-packetcable-06] (13 pages) - Prefix Exclude Option for DHCPv6-based Prefix Delegation [draft-ietf-dhc-pd-exclude-04] (10 pages) - PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option [draft-ietf-dhc-pktc-kerb-tckt-03] (7 pages) - DHCPv6 Extension Practices and Considerations [draft-ietf-dhc-problem-statement-of-mredhcpv6-08] (15 pages) - Dynamic Configuration of Internet Hosts [draft-ietf-dhc-problem-stmt-00] (0 pages) - Dynamic Host Configuration Protocol [draft-ietf-dhc-protocol-06] (39 pages) - DHCP Option for Proxy Server Configuration [draft-ietf-dhc-proxyserver-opt-05] (8 pages) - DHCP reconfigure extension [draft-ietf-dhc-pv4-reconfigure-06] (6 pages) - Dynamic Host Configuration Protocol Options Used by PXELINUX [draft-ietf-dhc-pxelinux-03] (14 pages) - Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE) [draft-ietf-dhc-pxe-options-03] (7 pages) - The Server Range Option for DHCP [draft-ietf-dhc-range-00] (2 pages) - Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4) [draft-ietf-dhc-rapid-commit-opt-05] (10 pages) - Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options [draft-ietf-dhc-reclassify-options-01] (7 pages) - The Authentication Suboption for the DHCP Relay Agent Option [draft-ietf-dhc-relay-agent-auth-01] (16 pages) - The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption [draft-ietf-dhc-relay-agent-flags-03] (7 pages) - Authentication of DHCP Relay Agent Options Using IPsec [draft-ietf-dhc-relay-agent-ipsec-02] (10 pages) - The DHCPv4 Relay Agent Identifier Sub-Option [draft-ietf-dhc-relay-id-suboption-13] (8 pages) - Generalized UDP Source Port for DHCP Relay [draft-ietf-dhc-relay-port-10] (10 pages) - Security of Messages Exchanged between Servers and Relay Agents [draft-ietf-dhc-relay-server-security-05] (8 pages) - Graceful renumbering of networks with DHCP [draft-ietf-dhc-renumbering-00] (8 pages) - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ietf-dhc-rfc3315bis-13] (154 pages) - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ietf-dhc-rfc8415bis-05] (141 pages) - DHCP Safe Failover Protocol [draft-ietf-dhc-safe-failover-proto-00] (29 pages) - DHCP Schema for LDAP [draft-ietf-dhc-schema-02] (23 pages) - Secure DHCPv6 Using CGAs [draft-ietf-dhc-secure-dhcpv6-07] (18 pages) - Securing DHCP [draft-ietf-dhc-securing-dhc-00] (5 pages) - Security Architecture for DHCP [draft-ietf-dhc-security-arch-01] (14 pages) - Security Requirements for the DHCP protocol [draft-ietf-dhc-security-requirements-00] (12 pages) - Secure DHCPv6 [draft-ietf-dhc-sedhcpv6-21] (31 pages) - Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Server MIB [draft-ietf-dhc-server-mib-10] (37 pages) - DHCP Server Identifier Override Suboption [draft-ietf-dhc-server-override-05] (7 pages) - The Server Identification Option for DHCP [draft-ietf-dhc-sio-00] (6 pages) - Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6 [draft-ietf-dhc-slap-quadrant-12] (16 pages) - DHCP Options for Service Location Protocol [draft-ietf-dhc-slp-07] (6 pages) - Service-Oriented Address Assignment using DHCPv6 [draft-ietf-dhc-soa-option-00] (9 pages) - The Server Selection Option for DHCP [draft-ietf-dhc-sso-03] (14 pages) - A Method for Generating Semantically Opaque Interface Identifiers with Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ietf-dhc-stable-privacy-addresses-02] (10 pages) - Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ietf-dhc-stateless-dhcpv6-renumbering-02] (8 pages) - Description of Cisco Systems' Subnet Allocation Option for DHCPv4 [draft-ietf-dhc-subnet-alloc-13] (24 pages) - The IPv4 Subnet Selection Option for DHCP [draft-ietf-dhc-subnet-option-07] (7 pages) - Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option [draft-ietf-dhc-suboptions-kdc-serveraddress-04] (7 pages) - Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option [draft-ietf-dhc-subscriber-id-07] (7 pages) - Subnet Selection Option for DHCP [draft-ietf-dhc-subsel-00] (5 pages) - DHCP Option for IEEE 1003.1 POSIX Timezone Specifications [draft-ietf-dhc-timezone-03] (3 pages) - Timezone Options for DHCP [draft-ietf-dhc-timezone-option-05] (10 pages) - Customizing DHCP Configuration on the Basis of Network Topology [draft-ietf-dhc-topo-conf-09] (20 pages) - Triggering DHCPv6 Reconfiguration from Relay Agents [draft-ietf-dhc-triggered-reconfigure-07] (13 pages) - Unused Dynamic Host Configuration Protocol (DHCP) Option Codes [draft-ietf-dhc-unused-optioncodes-07] (8 pages) - DHCP Use of the User Class Option for Address Assignment [draft-ietf-dhc-useraddr-00] (5 pages) - The User Class Option for DHCP [draft-ietf-dhc-userclass-10] (6 pages) - Provisioning IPv4 Configuration Over IPv6 Only Networks [draft-ietf-dhc-v4configuration-06] (17 pages) - Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis [draft-ietf-dhc-v4-threat-analysis-03] (20 pages) - IPv6-Only Preferred Option for DHCPv4 [draft-ietf-dhc-v6only-08] (12 pages) - Options for DHCPv6 [draft-ietf-dhc-v6opts-00] (15 pages) - DHCPv6 Relay agent RADIUS Attribute Option [draft-ietf-dhc-v6-relay-radius-02] (12 pages) - Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4) [draft-ietf-dhc-vendor-03] (9 pages) - Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option [draft-ietf-dhc-vendor-suboption-00] (7 pages) - Virtual Subnet Selection Options for DHCPv4 and DHCPv6 [draft-ietf-dhc-vpn-option-15] (26 pages) - Privacy considerations for DHCP [draft-jiang-dhc-dhcp-privacy-00] (12 pages) - Secure DHCPv6 with Public Key [draft-jiang-dhc-sedhcpv6-02] (16 pages) - Privacy considerations for DHCPv6 [draft-krishnan-dhc-dhcpv6-privacy-00] (14 pages) - Customizing DHCP Configuration on the Basis of Network Topology [draft-lemon-dhc-topo-conf-01] (9 pages) - secure DHCPv6 deployment [draft-li-dhc-secure-dhcpv6-deployment-03] (7 pages) - IPv6-Only-Preferred Option for DHCP [draft-link-dhc-v6only-01] (10 pages) - DHCP Options for Novell Directory Services [draft-provan-dhcp-options-dir-serv-01] (5 pages) - Provisioning IPv4 Configuration Over IPv6 Only Networks [draft-rajtar-dhc-v4configuration-02] (13 pages) - Problem Statement of Multi-requirement Extensions for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ren-dhc-problem-statement-of-mredhcpv6-01] (11 pages) - DHCPv4 over DHCPv6 Transport [draft-scskf-dhc-dhcpv4-over-dhcpv6-01] (8 pages) - Generalized Source UDP Port of DHCP Relay [draft-shen-dhc-client-port-03] (7 pages) - The IPv6 Address-based DHCPv6 Unique Identifier (DUID-V6ADDR) [draft-templin-duid-ipv6-01] (7 pages) - Security of Messages Exchanged Between Servers and Relay Agents [draft-volz-dhc-relay-server-security-02] (8 pages) - DHCPv6 Dynamic Reconfiguration [draft-wing-dhc-dns-reconfigure-02] (9 pages) - Registering Self-generated IPv6 Addresses using DHCPv6 [draft-wkumari-dhc-addr-notification-07] (11 pages) Requests for Comments: RFC1531: Dynamic Host Configuration Protocol (39 pages) * Obsoletes RFC1541 RFC1532: Clarifications and Extensions for the Bootstrap Protocol (22 pages) * Obsoletes RFC1542 RFC1533: DHCP Options and BOOTP Vendor Extensions (30 pages) * Obsoletes RFC2132 RFC1534: Interoperation Between DHCP and BOOTP (4 pages) RFC2131: Dynamic Host Configuration Protocol (45 pages) * Updates RFC3396 * Updates RFC4361 * Updates RFC5494 * Updates RFC6842 RFC2132: DHCP Options and BOOTP Vendor Extensions (34 pages) * Updates RFC3442 * Updates RFC3942 * Updates RFC4361 * Updates RFC4833 * Updates RFC5494 RFC2241: DHCP Options for Novell Directory Services (5 pages) RFC2242: NetWare/IP Domain Name and Information (6 pages) RFC2485: DHCP Option for The Open Group's User Authentication Protocol (4 pages) RFC2489: Procedure for Defining New DHCP Options (5 pages) * Obsoletes RFC2939 RFC2563: DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients (9 pages) * Updates RFC8925 RFC2610: DHCP Options for Service Location Protocol (6 pages) RFC2937: The Name Service Search Option for DHCP (5 pages) RFC2939: Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types (7 pages) RFC3004: The User Class Option for DHCP (6 pages) RFC3011: The IPv4 Subnet Selection Option for DHCP (7 pages) RFC3046: DHCP Relay Agent Information Option (14 pages) * Updates RFC6607 RFC3074: DHC Load Balancing Algorithm (10 pages) RFC3118: Authentication for DHCP Messages (17 pages) RFC3203: DHCP reconfigure extension (6 pages) * Updates RFC6704 RFC3256: The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option (5 pages) RFC3315: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (101 pages) * Updates RFC4361 * Updates RFC5494 * Updates RFC6221 * Updates RFC6422 * Updates RFC6644 * Updates RFC7083 * Updates RFC7227 * Updates RFC7283 * Updates RFC7550 * Obsoletes RFC8415 RFC3396: Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4) (9 pages) RFC3442: The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4 (9 pages) RFC3495: Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration (13 pages) RFC3527: Link Selection sub-option for the Relay Agent Information Option for DHCPv4 (9 pages) RFC3594: PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option (7 pages) RFC3633: IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 (19 pages) * Updates RFC6603 * Updates RFC7550 * Obsoletes RFC8415 RFC3634: Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option (7 pages) RFC3646: DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (7 pages) RFC3679: Unused Dynamic Host Configuration Protocol (DHCP) Option Codes (8 pages) * Updates RFC8910 RFC3736: Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 (9 pages) * Obsoletes RFC8415 RFC3898: Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (7 pages) RFC3925: Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4) (9 pages) RFC3942: Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options (7 pages) RFC3993: Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option (7 pages) RFC4014: Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option (8 pages) * Updates RFC9445 RFC4030: The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option (15 pages) RFC4039: Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4) (10 pages) RFC4075: Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6 (5 pages) RFC4076: Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (8 pages) RFC4174: The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service (13 pages) * Updates RFC7146 RFC4242: Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (8 pages) * Obsoletes RFC8415 RFC4243: Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option (7 pages) RFC4280: Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers (11 pages) RFC4361: Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) (12 pages) * Updates RFC5494 RFC4388: Dynamic Host Configuration Protocol (DHCP) Leasequery (27 pages) * Updates RFC6148 RFC4436: Detecting Network Attachment in IPv4 (DNAv4) (15 pages) RFC4477: Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues (14 pages) RFC4578: Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE) (7 pages) RFC4580: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option (6 pages) RFC4649: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option (6 pages) RFC4702: The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option (17 pages) RFC4703: Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients (13 pages) RFC4704: The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option (15 pages) RFC4833: Timezone Options for DHCP (10 pages) RFC4994: DHCPv6 Relay Agent Echo Request Option (6 pages) RFC5007: DHCPv6 Leasequery (23 pages) RFC5010: The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption (7 pages) RFC5071: Dynamic Host Configuration Protocol Options Used by PXELINUX (14 pages) RFC5107: DHCP Server Identifier Override Suboption (7 pages) RFC5192: DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents (8 pages) RFC5460: DHCPv6 Bulk Leasequery (18 pages) * Updates RFC7653 RFC5970: DHCPv6 Options for Network Boot (11 pages) RFC6148: DHCPv4 Lease Query by Relay Agent Remote ID (13 pages) RFC6221: Lightweight DHCPv6 Relay Agent (17 pages) RFC6355: Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID) (5 pages) RFC6422: Relay-Supplied DHCP Options (8 pages) RFC6603: Prefix Exclude Option for DHCPv6-based Prefix Delegation (10 pages) RFC6607: Virtual Subnet Selection Options for DHCPv4 and DHCPv6 (26 pages) RFC6644: Rebind Capability in DHCPv6 Reconfigure Messages (10 pages) RFC6656: Description of Cisco Systems' Subnet Allocation Option for DHCPv4 (24 pages) RFC6704: Forcerenew Nonce Authentication (12 pages) RFC6842: Client Identifier Option in DHCP Server Replies (5 pages) RFC6853: DHCPv6 Redundancy Deployment Considerations (16 pages) RFC6925: The DHCPv4 Relay Agent Identifier Sub-Option (8 pages) RFC6926: DHCPv4 Bulk Leasequery (41 pages) * Updates RFC7724 RFC6939: Client Link-Layer Address Option in DHCPv6 (7 pages) RFC6977: Triggering DHCPv6 Reconfiguration from Relay Agents (13 pages) RFC7031: DHCPv6 Failover Requirements (17 pages) RFC7037: RADIUS Option for the DHCPv6 Relay Agent (10 pages) RFC7083: Modification to Default Values of SOL_MAX_RT and INF_MAX_RT (7 pages) * Obsoletes RFC8415 RFC7227: Guidelines for Creating New DHCPv6 Options (35 pages) RFC7283: Handling Unknown DHCPv6 Messages (7 pages) * Obsoletes RFC8415 RFC7341: DHCPv4-over-DHCPv6 (DHCP 4o6) Transport (16 pages) RFC7550: Issues and Recommendations with Multiple Stateful DHCPv6 Options (24 pages) * Obsoletes RFC8415 RFC7618: Dynamic Allocation of Shared IPv4 Addresses (15 pages) RFC7653: DHCPv6 Active Leasequery (30 pages) RFC7724: Active DHCPv4 Lease Query (28 pages) RFC7819: Privacy Considerations for DHCP (14 pages) RFC7824: Privacy Considerations for DHCPv6 (18 pages) RFC7839: Access-Network-Identifier Option in DHCP (20 pages) RFC7844: Anonymity Profiles for DHCP Clients (26 pages) RFC7969: Customizing DHCP Configuration on the Basis of Network Topology (20 pages) RFC8156: DHCPv6 Failover Protocol (96 pages) RFC8168: DHCPv6 Prefix-Length Hint Issues (9 pages) RFC8213: Security of Messages Exchanged between Servers and Relay Agents (8 pages) RFC8357: Generalized UDP Source Port for DHCP Relay (10 pages) RFC8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (154 pages) RFC8539: Softwire Provisioning Using DHCPv4 over DHCPv6 (18 pages) RFC8925: IPv6-Only Preferred Option for DHCPv4 (12 pages) RFC8947: Link-Layer Address Assignment Mechanism for DHCPv6 (18 pages) RFC8948: Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6 (16 pages) RFC8987: DHCPv6 Prefix Delegating Relay Requirements (11 pages) RFC9243: A YANG Data Model for DHCPv6 Configuration (92 pages) Distributed Mobility Management (dmm) ------------------------------------- Charter Last Modified: 2023-07-04 Current Status: Active Chairs: Satoru Matsushima Sri Gundavelli Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Erik Kline Mailing Lists: General Discussion: dmm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dmm Archive: https://mailarchive.ietf.org/arch/browse/dmm/ Description of Working Group: Mobility management solutions lie at the center of the wireless Internet and enable mobile devices to partake in IP networks anytime and anywhere. The IETF Distributed Mobility Management (DMM) working group (WG) specifies solutions for IP networks so that traffic between mobile and correspondent nodes can take an optimal route. DMM solutions aim for transparency above the IP layer, including maintenance of active transport level sessions when mobile hosts or mobile networks change their point of attachment to the Internet. Wireless network deployments have traditionally relied on hierarchical schemes that often lead to centralized deployment models, where a small number of mobility anchors manage both mobility and reachability for a mobile node. The DMM WG will consider the latest developments in mobile networking research and operational practice (i.e. flattening network architectures, the impact of virtualization, new deployment needs as wireless access technologies evolve in the coming years) and will describe how distributed mobility management addresses the new needs in this area better than previously standardized solutions. A topic of particular focus will be mobility anchoring in this new context, and the DMM working group is chartered to work on maintenance-oriented extensions of the Mobile IPv6 protocol family (RFC 5213, RFC 5844, RFC 5555, RFC 5568, and RFC 6275) as well as new approaches which capitalize on other protocols specified by the IETF. For example, mobility management in a limited area, such as within an autonomous system, is not strictly limited to mentioned IP mobility protocols but can be any existing or a new protocol solution enabling the movement of a mobile node such as routing protocols. When extending protocols that are not based on Mobile IP, DMM solutions will have to be reviewed by the corresponding WGs. IPv6 is assumed to be present in both the mobile host/router and the access networks. DMM solutions are primarily targeted at IPv6 deployments and are not required to support IPv4, in particular for the case where private IPv4 addresses and/or NATs are used. DMM solutions must maintain backward compatibility: If the network or the mobile host/router does not support the distributed mobility management protocol that should not prevent the mobile host/router gaining basic access (i.e., nomadic) to the network. Contrary to earlier IP mobility protocols, mobility management signaling paths and end-user traffic forwarding paths may differ. Further, mobility-related functions may be located in separate network nodes. DMM solutions should not distinguish between physical or virtualized networking functions. Whenever applicable, clarifications and additional features/capabilities for specific networking function deployment models, e.g. in virtualized environments, are in-scope and encouraged. Solutions may also specify the selection between the care-of addresses and home address(es)/prefix(es) for different application use cases. The working group will produce one or more documents on the following work item topics. o Distributed mobility management deployment models and scenarios: describe the target high-level network architectures and deployment models where distributed mobility management protocol solutions would apply. o Enhanced mobility anchoring: define protocol solutions for a gateway and mobility anchor assignment and mid-session mobility anchor switching that go beyond what has been specified, for example, in RFC 6097, 6463, and 5142. Traffic steering associated with the anchor switch is also in-scope if deemed appropriate. o Forwarding path and signaling management: the function that handles mobility management signaling interacts with the DMM network elements for managing the forwarding state associated with a mobile node's IP traffic. These two functions may or may not be collocated. Furthermore, the forwarding state may also be distributed into multiple network elements instead of a single network element (e.g., anchor). Protocol extensions or new protocols will be specified to allow the above mentioned forwarding path and signalling management. o Exposing mobility state to mobile nodes and network nodes: define solutions that allow, for example, mobile nodes to select either a care-of address or a home address depending on an application' mobility needs. In order to enable this functionality, the network-side control functions and other networking nodes must also be able to exchange appropriate control information, as well as to the mobile nodes and their applications. The working group may decide to extend the current milestones based on the new information and knowledge gained during working on other documents listed in the initial milestones. Possible new documents and milestones must still fit into the overall DMM charter scope as outlined above. Goals and Milestones: Feb 2016 - Submit 'Exposing mobility state to mobile nodes and network nodes' submitted to the IESG. Nov 2016 - RFC5149bis on Service Selection as a working group document Mar 2017 - RFC5149bis submitted to IESG. Done - Submit 'Forwarding path and signaling management' as a working group document. Done - Submit 'Enhanced mobility anchoring' as a working group document. Done - Submit 'RFC4283bis on MN-IDs as a working group document'. Done - Submit 'Exposing mobility state to mobile nodes and network nodes' as a working group document(s). Internet-Drafts: - Distributed Mobility Anchoring [draft-chan-dmm-distributed-mobility-anchoring-08] (27 pages) - LMA Controlled MAG Session Parameters [draft-gundavelli-dmm-lma-controlled-mag-params-00] (12 pages) - Mobile Node Identifier Types for MIPv6 [draft-ietf-dmm-4283mnids-08] (16 pages) - User Plane Protocol and Architectural Analysis on 3GPP 5G System [draft-ietf-dmm-5g-uplane-analysis-04] (42 pages) - Distributed Mobility Management: Current Practices and Gap Analysis [draft-ietf-dmm-best-practices-gap-analysis-09] (34 pages) - DMM Deployment Models and Architectural Considerations [draft-ietf-dmm-deployment-models-04] (15 pages) - Distributed Mobility Anchoring [draft-ietf-dmm-distributed-mobility-anchoring-15] (18 pages) - Protocol for Forwarding Policy Configuration (FPC) in DMM [draft-ietf-dmm-fpc-cpdp-14] (34 pages) - YANG for Protocol for Forwarding Policy Configuration (FPC) [draft-ietf-dmm-fpc-yang-00] (82 pages) - Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6) [draft-ietf-dmm-hnprenum-07] (10 pages) - Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor [draft-ietf-dmm-lma-controlled-mag-params-05] (14 pages) - Mobile Access Gateway (MAG) Multipath Options [draft-ietf-dmm-mag-multihoming-07] (15 pages) - On-Demand Mobility Management [draft-ietf-dmm-ondemand-mobility-18] (12 pages) - Proxy Mobile IPv6 Extensions for Distributed Mobility Management [draft-ietf-dmm-pmipv6-dlif-06] (25 pages) - Requirements for Distributed Mobility Management [draft-ietf-dmm-requirements-17] (24 pages) - Architecture Discussion on SRv6 Mobile User plane [draft-ietf-dmm-srv6mob-arch-00] (8 pages) - Segment Routing over IPv6 for the Mobile User Plane [draft-ietf-dmm-srv6-mobile-uplane-24] (29 pages) - Mobility aware Transport Network Slicing for 5G [draft-ietf-dmm-tn-aware-mobility-10] (20 pages) - Architecture Discussion on SRv6 Mobile User plane [draft-kohno-dmm-srv6mob-arch-07] (8 pages) - MN Identifier Types for RFC 4283 Mobile Node Identifier Option [draft-perkins-dmm-4283mnids-01] (7 pages) - Privacy considerations for DMM [draft-perkins-dmm-privacy-00] (6 pages) - MAG Multipath Binding Option [draft-seite-dmm-rg-multihoming-02] (13 pages) - DMM Deployment Models and Architectural Considerations [draft-wt-dmm-deployment-models-00] (15 pages) - Protocol for Forwarding Policy Configuration (FPC) in DMM [draft-wt-dmm-fpc-cpdp-00] (26 pages) - Home Network Prefix Renumbering in PMIPv6 [draft-yan-dmm-hnprenum-03] (8 pages) - On Demand Mobility Management [draft-yegin-dmm-ondemand-mobility-03] (10 pages) - Mobile User Plane Evolution [draft-zzhang-dmm-mup-evolution-09] (23 pages) Requests for Comments: RFC7333: Requirements for Distributed Mobility Management (24 pages) RFC7429: Distributed Mobility Management: Current Practices and Gap Analysis (34 pages) RFC8127: Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor (14 pages) RFC8191: Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6) (10 pages) RFC8278: Mobile Access Gateway (MAG) Multipath Options (15 pages) RFC8371: Mobile Node Identifier Types for MIPv6 (16 pages) RFC8653: On-Demand Mobility Management (12 pages) RFC8818: Distributed Mobility Anchoring (18 pages) RFC8885: Proxy Mobile IPv6 Extensions for Distributed Mobility Management (25 pages) RFC9433: Segment Routing over IPv6 for the Mobile User Plane (29 pages) Extensions for Scalable DNS Service Discovery (dnssd) ----------------------------------------------------- Charter Last Modified: 2023-09-25 Current Status: Active Chairs: Chris Box David Schinazi Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: dnssd@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dnssd Archive: https://mailarchive.ietf.org/arch/browse/dnssd/ Description of Working Group: Background ---------- Zero configuration networking protocols are currently well suited to discover services within the scope of a single link. In particular, the DNS-SD [RFC 6763] and mDNS [RFC6762] protocol suite (sometimes referred to using Apple Computer Inc.'s trademark, Bonjour) are widely used for DNS-based service discovery and host name resolution on a single link. The DNS-SD/mDNS protocol suite is used in many scenarios including home, campus, and enterprise networks. However, the zero configuration mDNS protocol is constrained to link-local multicast scope by design, and therefore cannot be used to discover services on remote links. In a home network that consists of a single (possibly bridged) link, users experience the expected discovery behavior; available services appear because all devices share a common link. However, in multi-link home networks (as envisaged by the homenet WG) or in routed campus or enterprise networks, devices and users can only discover services on the same link, which is a significant limitation. This has led to calls, such as the Educause petition, to develop an appropriate service discovery solution to span multiple links or to perform discovery across a wide area, not necessarily on directly connected links. In addition, the "Smart Energy Profile 2 Application Protocol Standard", published by ZigBee Alliance and HomePlug Powerline Alliance specifies the DNS-SD/mDNS protocol suite as the basis for its method of zero configuration service discovery. However, its use of wireless mesh multi-link subnets in conjunction with traditional routed networks will require extensions to the DNS-SD/mDNS protocols to allow operation across multiple links. The scenarios in which multi-link service discovery is required may be zero configuration environments, environments where administrative configuration is supported, or a mixture of the two. As demand for service discovery across wider area routed networks grows, some vendors are beginning to ship proprietary solutions. It is thus both timely and important that efforts to develop improved, scalable, autonomous service discovery solutions for routed networks are coordinated towards producing a single, standards-based solution. Working Group Description ------------------------- The focus of the WG is to develop a solution for extended, scalable DNS-SD. This work is likely to highlight problems and challenges with naming protocols, as some level of coexistence will be required between local zero configuration name services and those forming part of the global DNS. It is important that these issues are captured and documented for further analysis; solving those problems is however not within the scope of this WG. The WG will consider the tradeoffs between reusing/extending existing protocols and developing entirely new ones. It is highly desirable that any new solution is backwardly compatible with existing DNS-SD/mDNS deployments. Any solution developed by the dnssd WG must not conflict or interfere with the operation of other zero-configuration service and naming protocols such as uPnP or LLMNR. Integration with such protocols is out of scope for this WG. Current zero configuration discovery protocols are constrained to operate within a single link, which implicitly limits the scope of discovery. In extending service discovery protocols to operate over multiple links, devices will inherently become discoverable over a wider area, which may introduce security or privacy concerns. The WG will consider such concerns when exploring the solution space for multi-link service discovery. To that end, the primary goals of the dnssd WG are as follows: 1. To document a set of requirements for scalable, autonomous DNS-based service discovery in routed, multi-link networks in the following five scenarios: (A) Personal Area networks, e.g., one laptop and one printer. This is the simplest example of a service discovery network, and may or may not have external connectivity. (B) Home networks, as envisaged by the homenet WG, consisting of one or more exit routers, with one or more upstream providers or networks, and an arbitrary internal topology with heterogeneous media where routing is automatically configured. The home network would typically be a single zero configuration administrative domain with a relatively limited number of devices. (C) Wireless 'hotspot' networks, which may include wireless networks made available in public places, or temporary or permanent infrastructures targeted towards meeting or conference style events, e.g., as provided for IETF meetings. In such environments other devices may be more likely to be 'hostile' to the user. (D) Enterprise networks, consisting of larger routed networks, with large numbers of devices, which may be deployments spanning over multiple sites with multiple upstreams, and one more more administrative domains (depending on internal administrative delegation). The large majority of the forwarding and security devices are configured. These may be commercial or academic networks, with differing levels of administrative control over certain devices on the network, and BYOD devices commonplace in the campus scenario. (E) Mesh networks such as RPL/6LoWPAN, with one or more links per routable prefix, which may or may not have external connectivity. The topology may use technologies including 802.11 wireless, HomePlug AV and GP, and ZigBee IP. In the above scenarios, the aim is to facilitate service discovery across the defined site. It is also desirable that a user or device, when away from such a site, is still able to discover services within that site, e.g. a user discovering services in their home network while remote from it. It is also desirable that multiple discovery scopes are supported, from the point of view of either performing discovery within a specified scope or advertisement within a specified scope, and being able to discover (enumerate) the set of scopes such that an application could then choose to do either. It should be noted that scope in this sense might refer to 'building' or 'room' and thus might have no correlation to network topology. 2. To develop an improved, scalable solution for service discovery that can operate in multi-link networks, where devices may be in neighboring or non-neighboring links, applicable to the scenarios above. The solution will consider tradeoffs between reusing/extending existing protocols and developing entirely new protocols. The solution should include documentation or definition of the interfaces that can be implemented, separately to transport of the information. 3. To document challenges and problems encountered in the coexistence of zero configuration and global DNS name services in such multi-link networks, including consideration of both the name resolution mechanism and the namespace. It is important that the dnssd WG takes input from stakeholders in the scenarios it is considering. For example, the homenet WG is currently evaluating its own requirements for naming and service discovery; it is up to the homenet WG as to whether it wishes to recommend adoption of the solution developed in the dnssd WG, but coordination between the WGs is desirable. Goals and Milestones: Dec 2017 - Submit DNS-SD Advertising Proxy draft to the IESG as Standards Track RFC Done - Formation of the WG Done - Adopt requirements draft as WG document Done - Submit requirements draft to the IESG as an Informational RFC Done - Adopt Informational document on the problems and challenges arising for zeroconf and unicast DNS name services Done - Adopt wide-area service discovery solution draft as WG document Done - Confirm long-lived queries draft as WG document Done - Submit the zeroconf and unicast DNS "problems and challenges" draft to the IESG as Informational Done - Adopt privacy extensions for DNS-SD draft as a WG document Done - Adopt device pairing mechanism draft as a WG document Done - Submit DNS Push draft to the IESG as Standards Track RFC Done - Submit wide-area service discovery solution draft to the IESG as Standards Track RFC Done - Adopt hybrid-proxy implementation draft as WG document Done - Adopt DNS-SD Advertising Proxy draft as a WG document Internet-Drafts: - DNS Multiple QTYPEs [draft-bellis-dnsext-multi-qtypes-08] (7 pages) - Service Discovery Road Map [draft-cheshire-dnssd-roadmap-03] (20 pages) - DNS-SD Privacy and Security Requirements [draft-huitema-dnssd-prireq-00] (15 pages) - Privacy Extensions for DNS-SD [draft-huitema-dnssd-privacy-02] (20 pages) - DNS-SD Privacy Scaling Tradeoffs [draft-huitema-dnssd-privacyscaling-01] (13 pages) - Advertising Proxy for DNS-SD Service Registration Protocol [draft-ietf-dnssd-advertising-proxy-04] (13 pages) - Discovery Proxy for Multicast DNS-Based Service Discovery [draft-ietf-dnssd-hybrid-10] (33 pages) - Selecting Labels for Use with Conventional DNS and Other Resolution Systems in DNS-Based Service Discovery [draft-ietf-dnssd-mdns-dns-interop-04] (11 pages) - Multicast DNS Discovery Relay [draft-ietf-dnssd-mdns-relay-04] (30 pages) - DNS Multiple QTYPEs [draft-ietf-dnssd-multi-qtypes-04] (8 pages) - Device Pairing Using Short Authentication Strings [draft-ietf-dnssd-pairing-05] (11 pages) - Device Pairing Design Issues [draft-ietf-dnssd-pairing-info-02] (17 pages) - DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements [draft-ietf-dnssd-prireq-08] (17 pages) - Privacy Extensions for DNS-SD [draft-ietf-dnssd-privacy-05] (21 pages) - DNS-SD Privacy Scaling Tradeoffs [draft-ietf-dnssd-privacyscaling-00] (13 pages) - DNS Push Notifications [draft-ietf-dnssd-push-25] (32 pages) - Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions [draft-ietf-dnssd-requirements-06] (14 pages) - Service Registration Protocol for DNS-Based Service Discovery [draft-ietf-dnssd-srp-25] (41 pages) - Automatic Replication of DNS-SD Service Registration Protocol Zones [draft-ietf-dnssd-srp-replication-02] (26 pages) - An EDNS(0) option to negotiate Leases on DNS Updates [draft-ietf-dnssd-update-lease-08] (12 pages) - Device Pairing Using Short Authentication Strings [draft-kaiser-dnssd-pairing-00] (20 pages) - Automatic Replication of DNS-SD Service Registration Protocol Zones [draft-lemon-srp-replication-03] (24 pages) - Advertising Proxy for DNS-SD Service Registration Protocol [draft-sctl-advertising-proxy-02] (10 pages) - Multicast DNS Discovery Relay [draft-sctl-dnssd-mdns-relay-04] (20 pages) - An EDNS0 option to negotiate Leases on DNS Updates [draft-sekar-dns-ul-03] (7 pages) Requests for Comments: RFC7558: Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions (14 pages) RFC8222: Selecting Labels for Use with Conventional DNS and Other Resolution Systems in DNS-Based Service Discovery (11 pages) RFC8765: DNS Push Notifications (32 pages) RFC8766: Discovery Proxy for Multicast DNS-Based Service Discovery (33 pages) RFC8882: DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements (17 pages) DNS PRIVate Exchange (dprive) ----------------------------- Charter Last Modified: 2023-10-24 Current Status: Active Chairs: Brian Haberman Tim Wicinski Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: dns-privacy@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dns-privacy Archive: https://mailarchive.ietf.org/arch/browse/dns-privacy/ Description of Working Group: The DNS PRIVate Exchange (DPRIVE) Working Group develops mechanisms to provide confidentiality to DNS transactions in order to address concerns surrounding pervasive monitoring (RFC 7258). The set of DNS requests that an individual makes can provide an attacker with a large amount of information about that individual. DPRIVE aims to deprive the attacker of this information (The IETF defines pervasive monitoring as an attack [RFC7258]). The initial focus of this Working Group was the development of mechanisms that provide confidentiality and authentication between DNS Clients and Iterative Resolvers (published as RFCs 7858 and 8094). With proposed standard solutions for the client-to-iterative resolvers published, the working group turns its attention to the development of documents focused on: 1) providing confidentiality to DNS transactions between Iterative Resolvers and Authoritative Servers, 2) measuring the efficacy in preserving privacy in the face pervasive monitoring attacks, and 3) defining operational, policy, and security considerations for DNS operators offering DNS privacy services. Some of the results of this working group may be experimental.There are numerous aspects that differ between DNS exchanges with an iterative resolver and exchanges involving DNS root/authoritative servers. The working group will work with DNS operators and developers (via the DNSOP WG) to ensure that proposed solutions address key requirements. DPRIVE is chartered to work on mechanisms that add confidentiality to the DNS. While it may be tempting to solve other DNS issues while adding confidentiality, DPRIVE is not the working group to do this. DPRIVE will not work on any integrity-only mechanisms. Examples of the sorts of risks that DPRIVE will address can be found in [RFC 7626], and include both passive wiretapping and more active attacks, such as MITM attacks. DPRIVE will address risks to end-users' privacy (for example, which websites an end user is accessing). DPRIVE Work Items: - Develop requirements for adding confidentiality to DNS exchanges between recursive resolvers and authoritative servers (unpublished document). - Investigate potential solutions for adding confidentiality to DNS exchanges involving authoritative servers (Experimental). - Define, collect and publish performance data measuring effectiveness of DPRIVE-published technologies against pervasive monitoring attacks. - Document Best Current Practices for operating DNS Privacy services. Goals and Milestones: Aug 2020 - Submit draft on DNS privacy exchanges involving authoritative servers (Exp) Done - Unpublished document on requirements for DNS privacy services between recursive and authoritative servers (Wiki) Internet-Drafts: - DNS privacy considerations [draft-bortzmeyer-dnsop-dns-privacy-02] (12 pages) - DNS Privacy Considerations [draft-bortzmeyer-dprive-rfc7626-bis-02] (23 pages) - Authentication and (D)TLS Profile for DNS-over-TLS and DNS-over-DTLS [draft-dgr-dprive-dtls-and-tls-profiles-00] (17 pages) - Recommendations for DNS Privacy Service Operators [draft-dickinson-dprive-bcp-op-01] (32 pages) - Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS [draft-dkgjsal-dprive-unilateral-probing-02] (24 pages) - Using Early Data in DNS over TLS [draft-ghedini-dprive-early-data-02] (6 pages) - Authoritative DNS-over-TLS Operational Considerations [draft-hal-adot-operational-considerations-02] (14 pages) - Specification of DNS over Dedicated QUIC Connections [draft-huitema-dprive-dnsoquic-00] (19 pages) - TLS for DNS: Initiation and Performance Considerations [draft-hzhwm-dprive-start-tls-for-dns-02] (15 pages) - DNS Zone Transfer-over-TLS [draft-hzpa-dprive-xfr-over-tls-02] (18 pages) - Recommendations for DNS Privacy Service Operators [draft-ietf-dprive-bcp-op-14] (34 pages) - DNS over Datagram Transport Layer Security (DTLS) [draft-ietf-dprive-dnsodtls-15] (13 pages) - DNS over Dedicated QUIC Connections [draft-ietf-dprive-dnsoquic-12] (27 pages) - Specification for DNS over Transport Layer Security (TLS) [draft-ietf-dprive-dns-over-tls-09] (19 pages) - Usage Profiles for DNS over TLS and DNS over DTLS [draft-ietf-dprive-dtls-and-tls-profiles-11] (27 pages) - Using Early Data in DNS over TLS [draft-ietf-dprive-early-data-00] (6 pages) - The EDNS(0) Padding Option [draft-ietf-dprive-edns0-padding-03] (5 pages) - Evaluation of Privacy for DNS Private Exchange [draft-ietf-dprive-eval-00] (22 pages) - Recursive to Authoritative DNS with Unauthenticated Encryption [draft-ietf-dprive-opportunistic-adotq-02] (10 pages) - Padding Policies for Extension Mechanisms for DNS (EDNS(0)) [draft-ietf-dprive-padding-policy-06] (9 pages) - DNS Privacy Requirements for Exchanges between Recursive Resolvers and Authoritative Servers [draft-ietf-dprive-phase2-requirements-02] (10 pages) - DNS Privacy Considerations [draft-ietf-dprive-problem-statement-06] (17 pages) - DNS Privacy Considerations [draft-ietf-dprive-rfc7626-bis-09] (22 pages) - TLS for DNS: Initiation and Performance Considerations [draft-ietf-dprive-start-tls-for-dns-01] (18 pages) - Recursive to Authoritative DNS with Unauthenticated Encryption [draft-ietf-dprive-unauth-to-authoritative-04] (11 pages) - Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS [draft-ietf-dprive-unilateral-probing-13] (34 pages) - DNS Zone Transfer over TLS [draft-ietf-dprive-xfr-over-tls-12] (32 pages) - Padding Profiles for EDNS(0) [draft-mayrhofer-dprive-padding-profile-00] (6 pages) - Recursive to Authoritative DNS with Opportunistic Encryption [draft-pp-recursive-authoritative-opportunistic-04] (9 pages) - DNS over DTLS (DNSoD) [draft-wing-dprive-dnsodtls-01] (13 pages) Requests for Comments: RFC7626: DNS Privacy Considerations (17 pages) * Obsoletes RFC9076 RFC7830: The EDNS(0) Padding Option (5 pages) RFC7858: Specification for DNS over Transport Layer Security (TLS) (19 pages) * Updates RFC8310 RFC8094: DNS over Datagram Transport Layer Security (DTLS) (13 pages) RFC8310: Usage Profiles for DNS over TLS and DNS over DTLS (27 pages) RFC8467: Padding Policies for Extension Mechanisms for DNS (EDNS(0)) (9 pages) RFC8932: Recommendations for DNS Privacy Service Operators (34 pages) RFC9076: DNS Privacy Considerations (22 pages) RFC9103: DNS Zone Transfer over TLS (32 pages) RFC9250: DNS over Dedicated QUIC Connections (27 pages) RFC9539: Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS (24 pages) Drone Remote ID Protocol (drip) ------------------------------- Charter Last Modified: 2023-11-09 Current Status: Active Chairs: Daniel Migault Mohamed Boucadair Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: tm-rid@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tm-rid Archive: https://mailarchive.ietf.org/arch/browse/tm-rid/ Description of Working Group: Civil Aviation Authorities (CAAs) worldwide have initiated rule making for Unmanned Aircraft Systems (UAS) Remote Identification (RID). CAAs currently promulgate performance-based regulations that do not mandate specific techniques, but rather cite industry-consensus technical standards as acceptable means of compliance. One key standard is ASTM International (formerly the American Society for Testing and Materials) WK65041 [1]. This technical specification defines UAS RID message formats, and transmission methods. Network RID defines a set of information for UAS to be made available globally via the Internet. Broadcast RID defines a set of messages for UAS to send locally one-way over Bluetooth or Wi-Fi. WK65041 does not address how to populate/query registries, how to ensure trustworthiness of information, nor how to make the information useful. DRIP’s goal is to specify how RID can be made trustworthy and available in both Internet and local-only connected scenarios, especially in emergency situations. Some UAS operate in environments where the network or the devices or both are severely constrained [2] in terms of processing, bandwidth (e.g., Bluetooth 4 beacon payload is 25 bytes long), or battery life, and DRIP aims to function in these environments. The specifications produced by the WG will need to balance public safety authorities’ need to know trustworthy information with UAS operators’ and other involved parties’ privacy. The working group will primarily leverage Internet standards (including HIP, EPP, RDAP, and DNS) and infrastructure as well as domain name registration business models. The WG will track and align with the requirements being developed by regulatory authorities, e.g., the International Civil Aviation Organization the European Union Aviation Safety Agency (EASA) delegated [3] and implementing [4] regulations, and the US Federal Aviation Administration (US FAA) [5]. The working group will work on the following items: * Requirements: the WG is expected to provide an informational document that lists the technical requirements for applying IETF protocols to the UAS Remote Identification (UAS RID) - that is the system for identifying Unmanned Aircraft (UA) during flight by other parties. These requirements also include showing that new or adapted identifiers from existing protocols conform and meet the specifications to be certified as a UAS RID. * Architecture: the WG will propose a standard document that describes the architecture that address the technical requirements and that will attempt to re-use protocols or architectures already standardized at the IETF. * Protocol design: while the primary purpose of DRIP WG is to leverage existing protocols, the specificities of the UAS environment are likely to require existing protocols to be extended or new protocols to be designed. The WG will focus on getting these protocols or extensions standardized, coordinating with other WGs relevant for the protocol(s) in question on the most appropriate home for any given piece of work. References: [1] ASTM International F38 Committee Work Item WK65041 “Standard Specification for UAS Remote ID and Tracking” https://www.astm.org/DATABASE.CART/WORKITEMS/WK65041.htm [2] UAS Identification and Tracking Aviation Rulemaking Committee Recommendations Final Report 2017 SEP 30 https://www.faa.gov/regulations_policies/rulemaking/committees/documents/media/UAS%20ID%20ARC%20Final%20Report%20with%20Appendices.pdf [3] https://eur-lex.europa.eu/eli/reg_del/2019/945/oj [4] https://eur-lex.europa.eu/eli/reg_impl/2019/947/ojeg_impl/2019/947/oj [5] Notice of Proposed Rule Making (NPRM) https://www.federalregister.gov/documents/2019/12/31/2019-28100/remote-identification-of-unmanned-aircraft-systems Goals and Milestones: Mar 2024 - Submit DRIP Registries to the IESG Done - Requirements and architecture drafts adopted by the WG Done - Solution space documents adopted by the WG Done - Requirements and architecture drafts in the WGLC Done - Submit Requirements Document to the IESG Done - Submit DRIP Architecture Document to the IESG Done - Submit DRIP UAS Remote ID to the IESG Done - Submit DRIP Authentication Formats to the IESG Done - Adopt a support document for operationalizing DRIP (Informational; not necessarily for publication as RFC) Internet-Drafts: - Drone Remote Identification Protocol (DRIP) Architecture [draft-card-drip-arch-02] (16 pages) - Drone Remote Identification Protocol (DRIP) Requirements [draft-card-drip-reqs-02] (18 pages) - Drone Remote Identification Protocol (DRIP) Architecture [draft-ietf-drip-arch-31] (28 pages) - DRIP Entity Tag Authentication Formats & Protocols for Broadcast Remote ID [draft-ietf-drip-auth-49] (48 pages) - The DRIP DET public Key Infrastructure [draft-ietf-drip-dki-01] (44 pages) - DRIP Entity Tag (DET) Identity Management Architecture [draft-ietf-drip-registries-17] (46 pages) - Drone Remote Identification Protocol (DRIP) Requirements and Terminology [draft-ietf-drip-reqs-18] (41 pages) - DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID) [draft-ietf-drip-rid-37] (34 pages) - UAS Remote ID [draft-ietf-drip-uas-rid-01] (19 pages) - The DRIP DET public Key Infrastructure [draft-moskowitz-drip-dki-09] (44 pages) - DRIP Authentication Formats [draft-wiethuechter-drip-auth-06] (22 pages) - DRIP Registries [draft-wiethuechter-drip-registries-01] (36 pages) Requests for Comments: RFC9153: Drone Remote Identification Protocol (DRIP) Requirements and Terminology (41 pages) RFC9374: DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID) (34 pages) RFC9434: Drone Remote Identification Protocol (DRIP) Architecture (28 pages) RFC9575: DRIP Entity Tag (DET) Authentication Formats and Protocols for Broadcast Remote Identification (RID) (43 pages) Delay/Disruption Tolerant Networking (dtn) ------------------------------------------ Charter Last Modified: 2024-03-19 Current Status: Active Chairs: Edward J. Birrane Rick Taylor Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Erik Kline Secretary: Adam Wiethuechter Mailing Lists: General Discussion: dtn@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dtn Archive: https://mailarchive.ietf.org/arch/browse/dtn/ Description of Working Group: The Delay/Disruption Tolerant Networking (DTN) Working Group specifies mechanisms for data communications in the presence of long delays and/or intermittent connectivity. The Working Group has published the Bundle Protocol v7 (BPv7), corresponding Bundle Protocol Security protocol (BPSec) and an interoperable Security Context, and the TCP Convergence Layer specifications as standards track RFCs. Multiple independent implementations exist for these technologies in both space and terrestrial environments, and the technology is now used in production by governments and commercial organizations world-wide. This Working Group now focuses on the further work relevant to the area of Delay/Disruption Tolerant Networking, dividing work items into 3 broad categories: * An architecture for Naming, Addressing and Forwarding The Bundle Protocol v7 defines an encoding of Names for use in DTN, but the detailed semantics have not been specified. The Working Group will define a common architecture for the delay/disruption tolerant assignment of names, and the late-binding of such names during bundle forwarding to end-points within a DTN. This architecture will define a model for the forwarding process of a Bundle Process Agent, providing an informational reference point for further specifications. The Working Group charter intentionally excludes topics related to Routing in DTNs. This does not preclude discussion of the subject, in coordination with the Routing Area, but no Working Group documents will be adopted under this charter. * The definition of an architecture and protocols in the areas of Operations, Administration, and Management (OAM), and Key Management Current DTN deployments rely on the use of pre-placed keys and configuration or bespoke tooling, and there is a growing demand for standards to improve the automation and reliability of DTN management. Existing IETF protocols for OAM and Key Management generally rely on a bi-directional end-to-end path between devices, and in Delay/Disruption Tolerant Networks (DTNs) such paths rarely exist. To enable OAM and Key Management in such cases, there may be a need to standardize an architecture supporting alternative methods and their supporting protocols and data models. The Working Group will liaise with relevant experts in the OPS Area to discover if there are existing standards that meet, or may be extended to meet, the DTN use-cases before standardizing new protocols. There is also believed to be cross-over between the use-cases for OAM and Key Management in DTNs and the use-cases in Mobile Ad-hoc Networks (MANETs); to this end the Working Group will coordinate with the MANET Working Group to explore potential synergies and avoid duplication of effort. * Extensions to and best practices for existing protocols Extensions to the Bundle Protocol to enable reliability signalling, tunnelling and Quality of Service indication are needed for the operational deployment of Delay/Disruption Tolerant Networks, and these capabilities will be standardized by the Working Group. Additional extensions to the Bundle Protocol, additional Security Context definitions for BPSec, and new Convergence Layer adapters will be considered on a case-by-case basis by the working group. The Working Group will also document best practices learned from existing deployments. The Working Group will coordinate with other IETF Working Groups, especially in the Security, Routing, Operation and Management Areas, to ensure the quality of peer review, the avoidance of duplication of effort, and alignment with specifications produced in other Working Groups. Goals and Milestones: Jul 2022 - Delay-Tolerant Management Architecture Mar 2023 - Naming and Addressing Architecture Document Mar 2023 - Bundle Progress Signalling Jul 2023 - Bundle-in-Bundle Encapsulation Jul 2023 - QoS/Flow Extension Block Nov 2023 - Neighbor/Peer Discovery Protocol Specification Mar 2024 - Delay-Tolerant Management Protocols Jul 2024 - Key Management Protocol Internet-Drafts: - DTNMA Application Management Model (AMM) and Data Models [draft-ietf-dtn-adm-00] (121 pages) - DTNMA Application Data Model (ADM) YANG Syntax [draft-ietf-dtn-adm-yang-01] (80 pages) - Asynchronous Management Architecture [draft-ietf-dtn-ama-03] (33 pages) - DTNMA Application Management Model (AMM) and Data Models [draft-ietf-dtn-amm-01] (71 pages) - DTNMA Application Resource Identifier (ARI) [draft-ietf-dtn-ari-02] (49 pages) - Bundle-in-Bundle Encapsulation [draft-ietf-dtn-bibect-04] (16 pages) - Bundle Protocol Version 7 [draft-ietf-dtn-bpbis-31] (53 pages) - Bundle Protocol Security (BPSec) [draft-ietf-dtn-bpsec-27] (35 pages) - DTN Bundle Protocol Security (BPSec) COSE Context [draft-ietf-dtn-bpsec-cose-04] (46 pages) - Default Security Contexts for Bundle Protocol Security (BPSec) [draft-ietf-dtn-bpsec-default-sc-11] (51 pages) - BPSec Default Security Contexts [draft-ietf-dtn-bpsec-interop-sc-02] (22 pages) - Bundle Protocol Version 7 Administrative Record Types Registry [draft-ietf-dtn-bpv7-admin-iana-03] (5 pages) - DTN Management Architecture [draft-ietf-dtn-dtnma-14] (59 pages) - Update to the ipn URI scheme [draft-ietf-dtn-ipn-update-13] (31 pages) - Minimal TCP Convergence-Layer Protocol [draft-ietf-dtn-mtcpcl-01] (8 pages) - Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4 [draft-ietf-dtn-tcpclv4-28] (62 pages) Requests for Comments: RFC9171: Bundle Protocol Version 7 (53 pages) RFC9172: Bundle Protocol Security (BPSec) (35 pages) RFC9173: Default Security Contexts for Bundle Protocol Security (BPSec) (51 pages) RFC9174: Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4 (62 pages) Internet Area Working Group (intarea) ------------------------------------- Charter Last Modified: 2024-07-24 Current Status: Active Chairs: Juan-Carlos Zúñiga Wassim Haddad Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: int-area@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/int-area Archive: https://mailarchive.ietf.org/arch/browse/int-area/ Description of Working Group: The Internet Area Working Group (INTAREA WG) acts primarily as a forum for discussing far-ranging topics that affect the entire area. Such topics include, for instance, address space issues, basic IP layer functionality, and architectural questions. The group also serves as a forum to distribute information about ongoing activities in the area, create a shared understanding of the challenges and goals for the area, and to enable coordination. The Internet Area receives occasional proposals for the development and publication of RFCs that are not in scope of an existing working group and do not justify the formation of a new working group. The INTAREA WG has a secondary role to serve as the forum for developing such work items in the IETF. The working group milestones are updated as needed to reflect the current work items and their associated milestones. New work must satisfy the following conditions: (1) WG consensus on the relevance for the Internet at large. (2) WG consensus on the suitability and projected quality of the proposed work item. (3) A core group of WG participants with sufficient energy and expertise to advance the work item according to the proposed schedule. (4) Commitment from the WG as a whole to provide sufficient and timely review of the proposed work item. (5) Agreement by the ADs, who, depending on the scope of the proposed work item, may decide that an IESG review is needed first. Goals and Milestones: May 2010 - Submission of IPID document to the IESG as PS Aug 2010 - Submission of tunneling issues document to the IESG as Info Aug 2010 - Submission of tunneling security issues document to the IESG as Info Internet-Drafts: - Multi-hop Ad Hoc Wireless Communication [draft-baccelli-intarea-adhoc-wireless-com-01] (11 pages) - Extended Ping (Xping) [draft-bonica-intarea-eping-04] (17 pages) - Discovering Provisioning Domain Names and Data [draft-bruneau-intarea-provisioning-domains-02] (20 pages) - Current Hostname Practice Considered Harmful [draft-huitema-privsec-harmfulname-01] (9 pages) - Multi-hop Ad Hoc Wireless Communication [draft-ietf-intarea-adhoc-wireless-com-02] (12 pages) - Privacy Considerations for Protocols Relying on IP Broadcast or Multicast [draft-ietf-intarea-broadcast-consider-09] (13 pages) - Using the IPv6 Flow Label for Load Balancing in Server Farms [draft-ietf-intarea-flow-label-balancing-03] (13 pages) - IP Fragmentation Considered Fragile [draft-ietf-intarea-frag-fragile-17] (23 pages) - IPv6 Support for Generic Routing Encapsulation (GRE) [draft-ietf-intarea-gre-ipv6-14] (11 pages) - A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem [draft-ietf-intarea-gre-mtu-05] (12 pages) - Generic UDP Encapsulation [draft-ietf-intarea-gue-09] (43 pages) - Extensions for Generic UDP Encapsulation [draft-ietf-intarea-gue-extensions-06] (39 pages) - Current Hostname Practice Considered Harmful [draft-ietf-intarea-hostname-practice-05] (12 pages) - IP over Intentionally Partially Partitioned Links [draft-ietf-intarea-ippl-00] (16 pages) - Updated Specification of the IPv4 ID Field [draft-ietf-intarea-ipv4-id-update-07] (19 pages) - IPv6 Support Required for All IP-Capable Nodes [draft-ietf-intarea-ipv6-required-02] (6 pages) - Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments [draft-ietf-intarea-nat-reveal-analysis-10] (24 pages) - PROBE: A Utility for Probing Interfaces [draft-ietf-intarea-probe-10] (19 pages) - Discovering Provisioning Domain Names and Data [draft-ietf-intarea-provisioning-domains-11] (27 pages) - Communicating Proxy Configurations in Provisioning Domains [draft-ietf-intarea-proxy-config-01] (14 pages) - IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters [draft-ietf-intarea-rfc7042bis-11] (37 pages) - IP Router Alert Considerations and Usage [draft-ietf-intarea-router-alert-considerations-10] (19 pages) - Internet Protocol Number for SCHC [draft-ietf-intarea-schc-ip-protocol-number-00] (7 pages) - Protocol Numbers for SCHC [draft-ietf-intarea-schc-protocol-numbers-02] (9 pages) - Logging Recommendations for Internet-Facing Servers [draft-ietf-intarea-server-logging-recommendations-04] (5 pages) - Issues with IP Address Sharing [draft-ietf-intarea-shared-addressing-issues-05] (29 pages) - IP Tunnels in the Internet Architecture [draft-ietf-intarea-tunnels-13] (52 pages) - IP over Intentionally Partially Partitioned Links [draft-nordmark-intarea-ippl-05] (12 pages) Requests for Comments: RFC6269: Issues with IP Address Sharing (29 pages) RFC6302: Logging Recommendations for Internet-Facing Servers (5 pages) RFC6398: IP Router Alert Considerations and Usage (19 pages) RFC6540: IPv6 Support Required for All IP-Capable Nodes (6 pages) RFC6864: Updated Specification of the IPv4 ID Field (19 pages) RFC6967: Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments (24 pages) RFC7098: Using the IPv6 Flow Label for Load Balancing in Server Farms (13 pages) RFC7588: A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem (12 pages) RFC7676: IPv6 Support for Generic Routing Encapsulation (GRE) (11 pages) RFC8117: Current Hostname Practice Considered Harmful (12 pages) RFC8335: PROBE: A Utility for Probing Interfaces (19 pages) RFC8386: Privacy Considerations for Protocols Relying on IP Broadcast or Multicast (13 pages) RFC8801: Discovering Provisioning Domain Names and Data (27 pages) RFC8900: IP Fragmentation Considered Fragile (23 pages) RFC9542: IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters (32 pages) MAC Address Device Identification for Network and Application Services (madinas) -------------------------------------------------------------------------------- Charter Last Modified: 2023-05-25 Current Status: Active Chairs: Carlos J. Bernardos Juan-Carlos Zúñiga Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: madinas@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/madinas Archive: https://mailarchive.ietf.org/arch/browse/madinas/ Description of Working Group: The Medium Access Control (MAC) address is the Link Layer address used in IEEE 802 technologies. It was originally assigned statically for each physical network card by the Network Interface Card manufacturer, out of the space reserved by the IEEE Registration Authority Committee (RAC) for globally unique MAC addresses. The MAC address is used as source or destination target when sending and receiving frames. The default static assignment of the MAC address raises privacy concerns for personal devices. These concerns have recently started to be mitigated by SDOs specifying the use of Randomized and Changing MAC addresses (RCM) and end-device vendors implementing RCM. Device identity is important in scenarios where the network needs to know the device or user identity in order to offer, operate and maintain certain services. Currently, many use cases and applications make an implicit assumption that a device is represented by an IEEE 802 Layer 2 permanent and unique MAC address. This assumption is being used in both control plane and data plane functions and protocols. RCM breaks this assumption. This requires updating applications to function across MAC address changes. The MADINAS Working Group will document the current RCM state of affairs by : (i) identifying relevant network and application services scenarios and examining the effect of RCM schemes on them; (ii) analyzing various existing identifiers (i.e., beyond the MAC address) that can be used by the network to provide seamless services, and (iii) identifying scenarios where device identity is not required. The group will generate a Best Current Practices (BCP) document recommending means to reduce the impact of RCM on the documented use cases while ensuring that the privacy achieved with RCM is not compromised. For scenarios where device identity stability is desirable, the BCP document will recommend existing protocols that can be used to protect the request and exchange of identifiers between the client and the service provider. The Working Group will work together with other IETF WGs (e.g., DHC, IntArea), and will liaise with other relevant organizations, such as IEEE 802 and the Wireless Broadband Alliance (WBA), by coordinating on the different recommendations, as well as potential follow-up activities within or outside the IETF. MADINAS is expected to be a short timeframe (12-18 months) Working Group to quickly assess these needs. Additional solution space documents would only be published if identified as necessary, requiring a rechartering process in coordination with other relevant SDOs. The group will produce the following deliverables: 1. Document Current State of Affairs: An Informational use cases and identity requirements document An Informational MAC Address Randomization current state-of-affairs document 2. Document Best Practices handling RCM A Best Current Practices document Goals and Milestones: Jun 2022 - MAC Address Randomization current state-of-affairs (informational) document submitted to the IESG for publication Sep 2022 - Use Cases and Identity Requirements (informational) document submitted to the IESG for publication Mar 2023 - Best Current Practices handling RCM document submitted to the IESG for publication Internet-Drafts: - Randomized and Changing MAC Address Use Cases [draft-henry-madinas-framework-03] (15 pages) - Randomized and Changing MAC Address State of Affairs [draft-ietf-madinas-mac-address-randomization-15] (19 pages) - Randomized and Changing MAC Address Use Cases [draft-ietf-madinas-use-cases-10] (19 pages) - MAC address randomization [draft-zuniga-madinas-mac-address-randomization-01] (15 pages) No Requests for Comments Network Time Protocols (ntp) ---------------------------- Charter Last Modified: 2024-07-25 Current Status: Active Chairs: Dieter Sibold Karen O'Donoghue Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Erik Kline Mailing Lists: General Discussion: ntp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ntp Archive: https://mailarchive.ietf.org/arch/browse/ntp/ Description of Working Group: Network Time Protocols working group Accurate, precise, and reliable time is an important function relied upon by modern systems, devices, and applications. This requires reliable and accurate network time synchronization over modern IP-based networks. Additionally, accurate time is fundamental to implementing many important security properties, and therefore often must be (cryptographically, or otherwise) secured. The Network Time Protocols working group is focused on enhancing existing network time synchronization protocols, such as the Network Time Protocol (NTP), and specifying new network-time-related protocols or extensions for purposes that the existing protocols are not well suited to address. NTP was first defined in the IETF in RFC 958 in 1985. It has been through several iterations in the IETF. The latest, NTPv4 (RFC 5905) was published in 2010. Today, it is a widely used time synchronization protocol for the synchronization of clocks of various digital systems including computers, networks, and a myriad of devices. Despite NTP's wide-spread success, it has become apparent that it needs further development in order to adequately meet the modern requirements of time synchronization protocols and to meet the increasing security threats on the Internet. The working group will continue to address the maintenance of NTPv4, including extensions and corrections. This includes the introduction of an interleave mode in order to enhance the accuracy of the network time synchronization and the introduction of alternative clock selection algorithms in order to enhance robustness against delay attacks. NTP remains vulnerable to many types of attacks. Therefore, in 2020, the working group published Network Time Security (NTS) as RFC 8915. NTS extends NTP with an authentication approach to ensure authenticity of NTP time servers and protects the integrity of exchanged NTP packets. The working group will work on extending NTS to cover the remaining modes of service for NTP not covered by the initial specification. The working group will also work on extending NTS for PTP [1] in collaboration with the IEEE 1588 working group. The working group will also develop an updated version of NTP (preliminarily known as NTPv5), addressing a number of identified weaknesses. The new specification will consist of a set of documents, separating the on-wire protocol engine and the timing engine of NTP clients and servers. The updated version of NTP will address the security requirements specified in RFC 7384 and leverage the work completed in RFC 8915. Finally, the working group will address other network-time-related protocols in the IETF (e.g., roughtime) as well as work on items brought to the group from other standards bodies (e.g. IEEE 1588), with the acknowledged request to do so from that body. Working group items: * YANG model for NTPv4 * interleaved mode for NTPv4 * alternative clock selection algorithms * NTS for PTP * NTPv5 requirements * NTPv5 specification(s) * roughtime specification [1] "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems," in IEEE Std 1588-2019 (Revision of IEEE Std 1588-2008) , pp.1-499, 16 June 2020, doi: 10.1109/IEEESTD.2020.9120376. Goals and Milestones: May 2022 - NTPv4 YANG data model Jun 2022 - roughtime core specification Dec 2022 - NTS for PTP Dec 2022 - NTPv5 requirements Internet-Drafts: - Message Authentication Codes for the Network Time Protocol [draft-aanchal4-ntp-mac-03] (12 pages) - On Implementing Time [draft-aanchal-time-implementation-guidance-02] (9 pages) - Network Time Security for the Network Time Protocol [draft-dansarie-nts-00] (36 pages) - NTP Client Data Minimization [draft-dfranke-ntp-data-minimization-02] (5 pages) - Network Time Security for the Unicast Mode of the Precision Time Protocol [draft-gerstung-nts4uptp-03] (21 pages) - Port Randomization in the Network Time Protocol Version 4 [draft-gont-ntp-port-randomization-04] (10 pages) - NTPv5 use cases and requirements [draft-gruessing-ntp-ntpv5-requirements-05] (9 pages) - Control Messages Protocol for Use with Network Time Protocol Version 4 [draft-haberman-ntpwg-mode-6-cmds-02] (15 pages) - Alternative NTP port [draft-ietf-ntp-alternative-port-02] (7 pages) - Network Time Protocol Version 4: Autokey Specification [draft-ietf-ntp-autokey-08] (58 pages) - Network Time Protocol Best Current Practices [draft-ietf-ntp-bcp-13] (26 pages) - UDP Checksum Complement in the Network Time Protocol (NTP) [draft-ietf-ntp-checksum-trailer-07] (14 pages) - A Secure Selection and Filtering Mechanism for the Network Time Protocol with Khronos [draft-ietf-ntp-chronos-25] (17 pages) - Protecting Network Time Security Messages with the Cryptographic Message Syntax (CMS) [draft-ietf-ntp-cms-for-nts-message-06] (19 pages) - NTP Client Data Minimization [draft-ietf-ntp-data-minimization-04] (6 pages) - Network Time Protocol (NTP) Server Option for DHCPv6 [draft-ietf-ntp-dhcpv6-ntp-opt-06] (9 pages) - Network Time Protocol Version 4 (NTPv4) Extension Fields [draft-ietf-ntp-extension-field-07] (8 pages) - On Implementing Time [draft-ietf-ntp-implementation-guidance-00] (9 pages) - NTP Interleaved Modes [draft-ietf-ntp-interleaved-modes-07] (15 pages) - Message Authentication Code for the Network Time Protocol [draft-ietf-ntp-mac-06] (5 pages) - Control Messages Protocol for Use with Network Time Protocol Version 4 [draft-ietf-ntp-mode-6-cmds-11] (21 pages) - Network Time Security [draft-ietf-ntp-network-time-security-15] (39 pages) - The Network Time Protocol Version 4 Algorithm Specification [draft-ietf-ntp-ntpv4-algorithms-01] (25 pages) - Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4) [draft-ietf-ntp-ntpv4-mib-07] (26 pages) - Network Time Protocol Version 4: Protocol and Algorithms Specification [draft-ietf-ntp-ntpv4-proto-13] (110 pages) - Network Time Protocol Version 5 [draft-ietf-ntp-ntpv5-02] (31 pages) - NTPv5 Use Cases and Requirements [draft-ietf-ntp-ntpv5-requirements-04] (11 pages) - NTS4PTP - Network Time Security for the Precision Time Protocol [draft-ietf-ntp-nts-for-ptp-00] (78 pages) - NTP Over PTP [draft-ietf-ntp-over-ptp-03] (12 pages) - Guidelines for Defining Packet Timestamps [draft-ietf-ntp-packet-timestamps-09] (17 pages) - Network Time Protocol Version 4: Port Randomization [draft-ietf-ntp-port-randomization-08] (9 pages) - Network Time Protocol REFID Updates [draft-ietf-ntp-refid-updates-05] (8 pages) - Requirements for Network Time Protocol Version 4 [draft-ietf-ntp-reqs-01] (16 pages) - Roughtime [draft-ietf-ntp-roughtime-11] (19 pages) - Roughtime Ecosystem [draft-ietf-ntp-roughtime-ecosystem-01] (4 pages) - Updating the NTP Registries [draft-ietf-ntp-update-registries-16] (11 pages) - Network Time Security for the Network Time Protocol [draft-ietf-ntp-using-nts-for-ntp-28] (33 pages) - A YANG Data Model for NTP [draft-ietf-ntp-yang-data-model-17] (56 pages) - NTS4PTP - Key Management System for the Precision Time Protocol Based on the Network Time Security Protocol [draft-langer-ntp-nts-for-ptp-07] (76 pages) - The Network Time Protocol Version 4 (NTPv4) MAC Extension Field [draft-mayer-ntp-mac-extension-field-00] (6 pages) - Guidelines for Defining Packet Timestamps [draft-mizrahi-intarea-packet-timestamps-01] (14 pages) - Using UDP Checksum Trailers in the Network Time Protocol (NTP) [draft-mizrahi-ntp-checksum-trailer-02] (10 pages) - Using NTP Extension Fields without Authentication [draft-mizrahi-ntp-extension-field-03] (9 pages) - Alternative NTP port [draft-mlichvar-ntp-alternative-port-02] (6 pages) - NTP Correction Field [draft-mlichvar-ntp-correction-field-04] (7 pages) - NTP Interleaved Modes [draft-mlichvar-ntp-interleaved-modes-01] (9 pages) - Network Time Protocol Version 5 [draft-mlichvar-ntp-ntpv5-07] (28 pages) - NTP Over PTP [draft-mlichvar-ntp-over-ptp-03] (6 pages) - Network Time Protocol Best Current Practices [draft-reilly-ntp-bcp-02] (18 pages) - Roughtime [draft-roughtime-aanchal-04] (17 pages) - The update registries draft [draft-rsalz-update-registries-02] (11 pages) - A Secure Selection and Filtering Mechanism for the Network Time Protocol Version 4 [draft-schiff-ntp-chronos-03] (8 pages) - Network Time Protocol Extended Information Extension Field [draft-stenn-ntp-extended-information-04] (5 pages) - Network Time Protocol Version 4 (NTPv4) Extension Fields [draft-stenn-ntp-extension-fields-09] (13 pages) - Network Time Protocol I-Do Extension Field [draft-stenn-ntp-i-do-06] (7 pages) - Network Time Protocol IPv6 REFID Hash [draft-stenn-ntp-ipv6-refid-hash-00] (4 pages) - Network Time Protocol Last Extension Field [draft-stenn-ntp-last-extension-00] (4 pages) - Network Time Protocol Leap Smear REFID [draft-stenn-ntp-leap-smear-refid-02] (5 pages) - Network Time Protocol MAC/Last Extension Fields [draft-stenn-ntp-mac-last-ef-04] (8 pages) - Network Time Protocol Suggested REFID Extension Field [draft-stenn-ntp-suggest-refid-05] (7 pages) Requests for Comments: RFC5905: Network Time Protocol Version 4: Protocol and Algorithms Specification (110 pages) * Updates RFC7822 * Updates RFC8573 * Updates RFC9109 RFC5906: Network Time Protocol Version 4: Autokey Specification (58 pages) RFC5907: Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4) (26 pages) RFC5908: Network Time Protocol (NTP) Server Option for DHCPv6 (9 pages) RFC7821: UDP Checksum Complement in the Network Time Protocol (NTP) (14 pages) RFC7822: Network Time Protocol Version 4 (NTPv4) Extension Fields (8 pages) RFC8573: Message Authentication Code for the Network Time Protocol (5 pages) RFC8633: Network Time Protocol Best Current Practices (26 pages) RFC8877: Guidelines for Defining Packet Timestamps (17 pages) RFC8915: Network Time Security for the Network Time Protocol (33 pages) RFC9109: Network Time Protocol Version 4: Port Randomization (9 pages) RFC9249: A YANG Data Model for NTP (56 pages) RFC9327: Control Messages Protocol for Use with Network Time Protocol Version 4 (21 pages) RFC9523: A Secure Selection and Filtering Mechanism for the Network Time Protocol with Khronos (13 pages) Static Context Header Compression (schc) ---------------------------------------- Charter Last Modified: 2024-07-16 Current Status: Active Chairs: Alexander Pelov Pascal Thubert Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: schc@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/schc Archive: https://mailarchive.ietf.org/arch/browse/schc/ Description of Working Group: The scope of the Static Context Header Compression (SCHC) Working Group (to be pronounced as "chic" in French) is to extend the benefits of the RFC 8724 SCHC technology in Low-Power Wide-Area (LPWA) and non-LPWA networks, including Low Power devices such as zero-energy / scavenging devices that may operate in Delay Tolerant mode. To that effect, the group will provide specifications for the application of SCHC over underlying layers, where underlying layers include but are not limited to UDP tunnels, IP, PPP, and Ethernet, as well as the use of SCHC by upper-layer protocols. To extend SCHC over multi-hop networks with remote endpoints, there is a need in the data plane to signal the SCHC session and some operational values in the packets. For instance, the INT-AREA WG is working on a SCHC protocol type for IP and a SCHC Ethertype (in coordination with IEEE) for Ethernet. The WG will provide standards track specifications for a SCHC Header that conveys the SCHC Session Info over IP. A complete SCHC solution also requires control plane technologies to secure the operations and manage the SCHC sessions, devices, and gateways. The group will provide specifications to securely identify the rule sets and negotiate the associated parameters between the pair of endpoints. The group will also work on the rules provisioning to the nodes, including the instantiation of generic rules to the nodes and networks in which they are applied. The WG will work on: 1) Perform SCHC Maintenance, including enabling SCHC mechanisms for Upper layer Protocols, and providing additional reliability mechanisms such as FEC for fragments. 2) Produce a Standards Track document to enable Operations, Administration, and Maintenance (OAM), including support for delayed (as some devices can be asleep) or proxied (via the gateway) reachability verification. 3) Produce Standard Track documents for SCHC over underlying layers and carried protocols over SCHC where underlying layers includes but is not limited to IP, UDP tunnels, PPP, and Ethernet and carried protocols may include IPv4, ICMPv6-based protocols, TCP, IP tunnels, DLMS, and other protocols over CoAP such as LwM2M; define and maintain data models for the protocols supported by SCHC. 4) Produce an informational document describing how a carried protocol can use SCHC. 5) Define in a Standard Track document the SCHC Protocol Header to convey SCHC Session Info over IP 6) Produce Standard Track documents for SCHC Rule Discovery and Parameter Negotiation, including the specification of how work from the IETF security area is leveraged to secure these operations 7) Produce Standard Track documents for SCHC Rule Provisioning, including the specification of generic SCHC rules that can be instantiated, e.g., to apply to a certain node or within a certain network. The SCHC WG will coordinate with INTAREA WG for the IP protocol type definition, 6MAN WG for possible ICMPv6 code(s), and with other WGs for possible Protocols-over-SCHC or SCHC-over-protocol activities (e.g., in TSV area). It will work with the relevant security area WGs to appropriately secure the SCHC session. If required, the SCHC WG will liaise and coordinate with other Standard Development Organisations when SCHC will be used over or under protocols not defined with IETF. Goals and Milestones: Jul 2023 - WG adoption of a standard track specification of Operations, Administration, and Maintenance (OAM) Nov 2023 - WG adoption of a standard track specification SCHC over IP Nov 2023 - WG adoption of a standard track specification for generic SCHC header Dec 2023 - WG adoption of a standard track specification for rules provisioning Dec 2023 - WG adoption of a standard track specification for rules discovery and parameters negotiation Dec 2023 - WG adoption of a standard track specification of FEC for fragments Mar 2024 - Request for publication of a standard track specification for SCHC over PPP Mar 2024 - Request for publication of an information document about SCHC architecture Dec 2024 - Request for publication of a standard track specification of Operations, Administration, and Maintenance (OAM) Dec 2024 - Request for publication of a standard track specification of FEC for fragments Feb 2025 - Request for publication of a standard track specification for generic SCHC header Mar 2025 - Request for publication of a standard track specification for rules discovery and parameters negotiation Mar 2025 - Request for publication of a standard track specification for rules provisioning Mar 2025 - Request for publication of a standard track specification of a standard track specification SCHC over IP Done - WG adoption of a standard track specification for SCHC over PPP Done - WG adoption of an information document about SCHC architecture Internet-Drafts: - Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) [draft-ietf-schc-8824-update-02] (86 pages) - SCHC Access Control [draft-ietf-schc-access-control-00] (13 pages) - Static Context Header Compression (SCHC) Architecture [draft-ietf-schc-architecture-02] (25 pages) - Static Context Header Compression and Fragmentation over networks prone to disruptions [draft-ietf-schc-over-networks-prone-to-disruptions-00] (19 pages) - SCHC over PPP [draft-ietf-schc-over-ppp-00] (10 pages) - Protocol Numbers for SCHC [draft-ietf-schc-protocol-numbers-00] (9 pages) No Requests for Comments Stub Network Auto Configuration for IPv6 (snac) ----------------------------------------------- Charter Last Modified: 2024-03-27 Current Status: Active Chairs: Darren Dukes Kiran Makhijani Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: snac@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/snac Archive: https://mailarchive.ietf.org/arch/browse/snac/ Description of Working Group: Stub Network AutoConfiguration proposed charter A stub network is a network that can be connected to an existing infrastructure network and, to the extent possible, participate as part of that infrastructure. A stub network must be able to connect to an infrastructure network without modifications to that infrastructure network, even if MAC address lengths differ (e.g., IEEE 802.15.4). Hosts connected to the stub network should be able to do anything that hosts directly connected to the infrastructure network can do. Stub networks are leaf networks: they do not support the attachment of additional stub networks. The simplest use case for a stub network (e.g., a IEEE 802.15.4-based entertainment or lighting system) is to connect to an infrastructure network (e.g., a home network) that is a single layer-2 link (hence not running any routing protocol), without requiring any new behaviour from this infrastructure network. Hence, a solution that only provides transparent connectivity between the stub network and the infrastructure link to which it is directly connected is an important first step. Multiple distinct stub networks should be able to connect to the same infrastructure network. A more involved use case is to connect to an infrastructure network that can delegate an IPv6 prefix to the stub network and support unicast service discovery. The infrastructure network may be a single-link unmanaged network (e.g., a home network) or a managed multi-link network infrastructure. The multi-link use case may require the stub network prefix to be included in the routing plane of the infrastructure network. Both use cases are in scope for the working group. For all types of stub networks, the working group documents will allow IPv6-only stub networks to connect automatically to an infrastructure network, without any address translation (e.g., NPTv6 RFC 6296), so that hosts and services on the stub network can communicate as if they were connected directly to the infrastructure network. Hosts on the stub network(s) and the infrastructure network must be mutually discoverable, and mutually reachable. Discoverability refers to service discovery, e.g., DNSSD (RFC6763). In addition, hosts on the stub network should be able to connect to the Internet (via the infrastructure network), if desired, just as well as hosts on the infrastructure network are able to. The working group will coordinate with other relevant working groups, such as DNSSD or 6MAN or DHC, for any changes required in protocols and will make sure that those groups are included in major document reviews at appropriate times. Deliverables: * A framework document that explains how one or more stub routers connect one or more stub networks to a single unmanaged infrastructure link. This includes providing IP addresses required for communication, routes and routing required for communication, and providing service discovery for the stub network and the adjacent infrastructure link. * A document describing the set of services that must be provided by a multi-link infrastructure network in order for stub networks to be added to the infrastructure providing full mutual reachability, addressability, and discoverability between stub network hosts and hosts on adjacent and non-adjacent infrastructure links. This would address, for example, a building management network or an enterprise network. Goals and Milestones: Jan 2023 - Framework I-D adopted by the WG Jun 2023 - Services for multi-link adopted by the WG Nov 2023 - Framework I-D publication requested to the IESG Nov 2024 - Services for multi-link publication requested to the IESG Internet-Drafts: - Automatically Connecting Stub Networks to Unmanaged Infrastructure [draft-ietf-snac-simple-05] (37 pages) - Automatically Connecting Stub Networks to Unmanaged Infrastructure [draft-lemon-stub-networks-07] (21 pages) No Requests for Comments Timing over IP Connection and Transfer of Clock (tictoc) -------------------------------------------------------- Charter Last Modified: 2023-04-21 Current Status: Active Chairs: Karen O'Donoghue Yaakov (J) Stein Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Erik Kline Mailing Lists: General Discussion: tictoc@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tictoc Archive: https://mailarchive.ietf.org/arch/browse/tictoc/ Description of Working Group: The Timing over IP Connections and Transfer Of Clock (TICTOC) WG is concerned with highly accurate time and frequency distribution over native IP and MPLS-enabled IP Packet Switched Networks (PSNs). While this need arises from a variety of sources (see draft-bryant-tictoc-probstat-01.txt), the application areas of focus for this WG are: (1) Network infrastructures with the need for highly accurate time and frequency distribution within well-engineered service provider or enterprise campus networks. On-path support with specialized hardware may be expected to be available at one or more hops on a given path. (2) Individual hosts and devices on the public Internet requiring functionality or performance not currently available in NTP. On-path support may be utilized if available, but is not expected. This application brings additional requirements beyond improved accuracy, for example, the traceable and authenticated distribution of UTC time, including correct handling of leap seconds. The NTP Working Group is currently standardizing the fourth version of NTP for time distribution over IP networks. The NTP WG has focused its deliverables largely on standardizing the currently deployed NTPv4, while collecting requirements for future extensions. These requirements will transition to the tictoc WG for further development. Meeting those requirements may include revision of the protocol to a new version level. However, in all cases backwards compatibility and coexistence with currently deployed NTPv4 is a paramount concern. An applicability statement will describe the use cases for which any extension of NTP is targeted. The IEEE Test and Measurement Society is in the closing stages of standardizing a second version of IEEE1588. This is unofficially known as IEEE1588v2 and is expected to be published as IEEE1588-2008. IEEE1588v2 is emerging as a viable solution for time transfer over service provider and campus Ethernet networks, and for which on-path hardware support is becoming available. IEEE1588v2 specifically encourages other standards organizations to adapt it to their requirements, and provides guidelines for doing so. TICTOC will determine whether a profile for IEEE1588v2 over IP or MPLS-enabled IP networks would be suitable for (1), and if so will produce a profile within the guidelines provided in the IEEE1588v2 specification. An applicability statement will describe the use cases for which any profile of IEEE1588v2 is targeted. Time and Frequency distribution is considered by many to be a complex and often esoteric subject area. The WG will develop a modular framework in order to map out components within the solution space, define terminology, and identify common areas of protocol work that can be capitalized upon. TICTOC will also consider the co-existence of IEEE1588v2 and NTP in the same network. In doing so, TICTOC will first verify that the data model of NTP can be accommodated by IEEE1588v2 protocol operation and document any deficiencies compared to NTP. If there is a need to map the data models, it will produce a specification for how to utilize IEEE 1588 in a localized region as one portion of an NTP-based system. TICTOC protocols will be applicable to a variety of link layer technologies. To get the highest quality time and frequency transfer the user should take advantage of two types of on-path service where they are available: Link based frequency transfer, and hop-by-hop delay correction (for time). Examples of link based frequency support are SONET/SDH, TDM, Synchronous Ethernet and DSL with timing reference support. The main types of support that can be provided by a network element are boundary clock (where the clock is regenerated at the node in a multistage master slave relationship) and transparent clock where corrections are applied to time transfer packets as they pass through to compensate for the queuing delay, and where known for asymmetry in the link delay. Transparent clock (queue delay correction) requires routers to identify a time transfer packet, record the queuing delay, and either apply an on the fly correction to the packet, or to generate a follow-up packet with the necessary time correction information. TICTOC will ensure that any transparent clock design is acceptable in an Internet environment. On-path support is not a given, and TICTOC will investigate methods for automatically discovering when this support is available and when it is not. TICTOC will transfer time and frequency over both IP and IP enabled MPLS PSNs. One of the major users of TICTOC technology is the service provider community, where MPLS enabled IP networks are common. If necessary, TICTOC may take advantage of the path control properties of MPLS and the ability to signal modifications to per packet forwarding behavior. The security of time transfer, including the authentication of the time reference is an important consideration and must be designed in from the beginning. The ultimate system-level accuracy of time and frequency transfer depends on a number of factors outside the scope of the protocols themselves. Thus, even if it is possible for TICTOC to make a number of improvements at the protocol level to facilitate more accurate time and frequency transfer, it is impossible for the WG to provide system-level accuracy guarantees on its own. The TICTOC WG will co-ordinate with the PWE3 and NTP WGs in the IETF, as well as IEEE1588, IEEE 802.1AS and ITU-T SG15 Q13. It is also expected that active individuals in the TICTOC WG will propose the formation of an IRTF RG to study more advanced aspects of time and frequency distribution. First phase Objectives: - To develop a time and frequency distribution requirements document for the two cases listed above, including coexistence of the two as appropriate. - To develop a document defining the modular breakdown of functionality within the solution space. - To determine the extent to which these requirements can be satisfied using IEEE1588v2 and NTPv4 within each use case, along with an associated gap analysis for what requirements are not met without adaptation or extension of these protocols. - To develop an IEEE1588v2 profile as necessary for time and frequency distribution, with primary focus on (1). This profile will include a MIB module for IEEE1588v2. - To develop extensions to NTPv4 as necessary for time and frequency distribution, with primary focus on (2). - If required, to develop mechanisms for coexistence of IEEE1588v2 and NTP. - To document threat analyses and security mechanisms for all protocols developed by the WG. - To document media mappings for link layer technologies of interest. Second phase Objectives (requiring re-charter of the WG): To propose and document algorithms, protocols and mechanisms for transport, frequency acquisition, ranging, and packet selection/discard, master clock selection, path selection, OAM, synchronization status messaging, performance monitoring, security, and network management. Goals and Milestones: Mar 2016 - 1588v2 profile, if needed, document exits WGLC Apr 2016 - MIB for IEEE 1588v2 profile and NTPv4 extensions (TICTOC MIB) document exits WGLC May 2016 - Prioritize second phase deliverables and add milestones or re-charter document exits WGLC Jun 2016 - IEEE 1588v2 YANG Model exits WGLC Jun 2016 - Publish Experimental RFC on multi-path time synchronization Jul 2016 - Publish Experimental RFC on transporting time over MPLS Done - Security document(s) document exits WGLC Internet-Drafts: - TICTOC Problem Statement [draft-bryant-tictoc-probstat-02] (16 pages) - Problem Statements of Scalable Synchronization Networks [draft-hjxl-ssn-ps-00] (9 pages) - Transporting Timing messages over MPLS Networks [draft-ietf-tictoc-1588overmpls-07] (19 pages) - YANG Data Model for the Precision Time Protocol (PTP) [draft-ietf-tictoc-1588v2-yang-11] (30 pages) - Multipath Time Synchronization [draft-ietf-tictoc-multi-path-synchronization-07] (17 pages) - Enterprise Profile for the Precision Time Protocol With Mixed Multicast and Unicast messages [draft-ietf-tictoc-ptp-enterprise-profile-28] (15 pages) - Precision Time Protocol Version 2 (PTPv2) Management Information Base [draft-ietf-tictoc-ptp-mib-12] (64 pages) - TICTOC Requirement [draft-ietf-tictoc-requirements-01] (32 pages) - Security Requirements of Time Protocols in Packet Switched Networks [draft-ietf-tictoc-security-requirements-12] (36 pages) - YANG Data Model for IEEE 1588v2 [draft-jlx-tictoc-1588v2-yang-04] (22 pages) - Multi-Path Time Synchronization [draft-shpiner-multi-path-synchronization-03] (16 pages) - Architecture for the Transmission of Timing over Packet Networks [draft-stein-tictoc-modules-03] (22 pages) Requests for Comments: RFC7384: Security Requirements of Time Protocols in Packet Switched Networks (36 pages) RFC8039: Multipath Time Synchronization (17 pages) RFC8173: Precision Time Protocol Version 2 (PTPv2) Management Information Base (64 pages) RFC8575: YANG Data Model for the Precision Time Protocol (PTP) (30 pages) Autonomic Networking Integrated Model and Approach (anima) ---------------------------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Sheng Jiang Toerless Eckert Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari Operations and Management Area Advisor: Mahesh Jethanandani Tech Advisor: Nancy Cam-Winget Secretary: Michael Richardson Mailing Lists: General Discussion: anima@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/anima Archive: https://mailarchive.ietf.org/arch/browse/anima/ Description of Working Group: The Autonomic Networking Integrated Model and Approach (ANIMA) working group develops and maintains specifications and documentation for interoperable protocols and procedures for automated network management and control of professionally-managed networks. The vision is a network that configures, heals, optimizes and protects itself. The strategy is the incremental introduction of components to smoothly evolve existing and new networks accordingly. ANIMA work will rely on the framework described in draft-ietf-anima-reference-model already approved for publication. Work not related to this framework is welcome for review, but WG adoption of such work requires explicit rechartering. The two concrete areas of the reference model are (1) the Autonomic Networking Infrastructure (ANI), and (2) Autonomic Functions (AF) built from software modules called Autonomic Service Agents (ASA). The ANI is specified through prior ANIMA work. It is composed of the Autonomic Control Plane (ACP; RFC 8368), Bootstrap over Secure Key Infrastructures (BRSKI) including Vouchers (RFC8366), and the Generic Autonomic Signaling Protocol (GRASP). ANIMA will work on closing gaps and extending the ANI and its components. ANIMA will start to define Autonomic Functions (AF) to enable service automation in networks; it will also work on generic aspects of ASA including design guidelines and lifecycle management, coordination and dependency management. The reference model also discusses Intent, but ANIMA will not work on this without explicit rechartering. It will rely on the Network Management Research Group (NMRG) to define the next steps for this topic. ANIMA will coordinate with other IETF and IRTF groups as needed. The scope of possible work items are (additional works are subject to extra approval from the responsible AD): - Extensions to the ANI, including variations of ANI deployment (e.g. in virtualised environments), information distribution within an AN, ANI OAMP interfaces (Operations, Administration, Management, Provisioning), interaction with YANG-based mechanisms, defining the domain boundary and membership management of the domain. - Support for Autonomic Service Agents, including design and implementation guidelines for ASAs, life cycle management, authorization and coordination of ASA. - BRSKI features, including proxies, enrollment, adaptions over various network protocols, variations of voucher formats. - Generic use cases of Autonomic Network and new GRASP extensions/options for them, including bulk transfer, DNS-SD interworking, autonomic resource management, autonomic SLA assurance, autonomic multi-tenant management, autonomic network measurement. - Integration with Network Operations Centers (NOCs), including autonomic discovery/connectivity to NOC, YANG-based ANI/ASA management by the NOC and reporting AF from node to NOC. Goals and Milestones: Nov 2019 - Submit Information distribution over GRASP to the IESG Dec 2019 - Submit Constrained Voucher Artifacts for Bootstrapping Protocols to the IESG Dec 2019 - Submit Constrained Join Proxy for Bootstrapping Protocols to the IESG Mar 2020 - Submit Lifecycle and Management of Autonomic Service Agents to the IESG Mar 2020 - Submit Guidelines for Developing Autonomic Service Agents to the IESG Jul 2020 - Recharter or close the WG Internet-Drafts: - Guidelines for Autonomic Service Agents [draft-ietf-anima-asa-guidelines-07] (23 pages) - An Autonomic Control Plane (ACP) [draft-ietf-anima-autonomic-control-plane-30] (128 pages) - Bootstrapping Remote Secure Key Infrastructure (BRSKI) [draft-ietf-anima-bootstrapping-keyinfra-45] (116 pages) - BRSKI-AE: Alternative Enrollment Protocols in BRSKI [draft-ietf-anima-brski-ae-12] (41 pages) - BRSKI-AE: Alternative Enrollment Protocols in BRSKI [draft-ietf-anima-brski-async-enroll-05] (30 pages) - BRSKI Cloud Registrar [draft-ietf-anima-brski-cloud-10] (27 pages) - Discovery for BRSKI variations [draft-ietf-anima-brski-discovery-04] (44 pages) - BRSKI with Pledge in Responder Mode (BRSKI-PRM) [draft-ietf-anima-brski-prm-15] (113 pages) - Join Proxy for Bootstrapping of Constrained Network Elements [draft-ietf-anima-constrained-join-proxy-15] (26 pages) - Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) [draft-ietf-anima-constrained-voucher-25] (88 pages) - GeneRic Autonomic Signaling Protocol (GRASP) [draft-ietf-anima-grasp-15] (55 pages) - GeneRic Autonomic Signaling Protocol Application Program Interface (GRASP API) [draft-ietf-anima-grasp-api-10] (29 pages) - Information Distribution over GRASP [draft-ietf-anima-grasp-distribution-11] (23 pages) - JWS signed Voucher Artifacts for Bootstrapping Protocols [draft-ietf-anima-jws-voucher-12] (16 pages) - A Generic Autonomic Deployment and Management Mechanism for Resource-based Network Services [draft-ietf-anima-network-service-auto-deployment-06] (15 pages) - Autonomic IPv6 Edge Prefix Management in Large-Scale Networks [draft-ietf-anima-prefix-management-07] (19 pages) - A Reference Model for Autonomic Networking [draft-ietf-anima-reference-model-10] (26 pages) - A Voucher Artifact for Bootstrapping Protocols [draft-ietf-anima-rfc8366bis-12] (43 pages) - Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM) [draft-ietf-anima-stable-connectivity-10] (24 pages) - A Voucher Artifact for Bootstrapping Protocols [draft-ietf-anima-voucher-07] (23 pages) - Delegated Authority for Bootstrap Voucher Artifacts [draft-ietf-anima-voucher-delegation-02] (16 pages) - Generic Autonomic Signaling Protocol Application Program Interface (GRASP API) [draft-liu-anima-grasp-api-06] (25 pages) - Constrained Voucher Profile for Bootstrapping Protocols [draft-richardson-anima-ace-constrained-voucher-03] (20 pages) Requests for Comments: RFC8366: A Voucher Artifact for Bootstrapping Protocols (23 pages) RFC8368: Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM) (24 pages) RFC8990: GeneRic Autonomic Signaling Protocol (GRASP) (55 pages) RFC8991: GeneRic Autonomic Signaling Protocol Application Program Interface (GRASP API) (29 pages) RFC8992: Autonomic IPv6 Edge Prefix Management in Large-Scale Networks (19 pages) RFC8993: A Reference Model for Autonomic Networking (26 pages) RFC8994: An Autonomic Control Plane (ACP) (128 pages) RFC8995: Bootstrapping Remote Secure Key Infrastructure (BRSKI) (116 pages) RFC9222: Guidelines for Autonomic Service Agents (23 pages) Benchmarking Methodology (bmwg) ------------------------------- Charter Last Modified: 2023-07-26 Current Status: Active Chairs: Giuseppe Fioccola Sarah Banks Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari Operations and Management Area Advisor: Warren Kumari Mailing Lists: General Discussion: bmwg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/bmwg Archive: https://mailarchive.ietf.org/arch/browse/bmwg/ Description of Working Group: The Benchmarking Methodology Working Group (BMWG) will continue to produce a series of recommendations concerning the key performance characteristics of internetworking technologies, or benchmarks for network devices, systems, and services. Taking a view of networking divided into planes, the scope of work includes benchmarks for the management, control, and forwarding planes. The scope of BMWG has been extended to develop methods for virtual network functions (VNF) and their unique supporting infrastructure (such as SDN Controllers and vSwitches). Benchmarks for platform capacity and performance characteristics of virtual routers, firewalls (and other security functions), signaling control gateways, and other forms of gateways are included. The benchmarks will foster comparisons between physical and virtual network functions, and also cover unique features of Network Function Virtualization systems. Also, with the emergence of virtualized test systems, specifications for test system calibration are also in-scope. Each recommendation will describe the class of network function, system, or service being addressed; discuss the performance characteristics that are pertinent to that class; clearly identify a set of metrics that aid in the description of those characteristics; specify the methodologies required to collect said metrics; and lastly, present the requirements for the common, unambiguous reporting of benchmarking results. The set of relevant benchmarks will be developed with input from the community of users (e.g., network operators and testing organizations) and from those affected by the benchmarks when they are published (networking and test equipment manufacturers). When possible, the benchmarks and other terminologies will be developed jointly with organizations that are willing to share their expertise. Joint review requirements for a specific work area will be included in the description of the task. To better distinguish the BMWG from other measurement initiatives in the IETF, the scope of the BMWG is limited to the characterization of implementations of various internetworking technologies using controlled stimuli in a laboratory environment. Said differently, the BMWG does not attempt to produce benchmarks for live, operational networks. Moreover, the benchmarks produced by this WG shall strive to be vendor independent or otherwise have universal applicability to a given technology class. Because the demands of a particular technology may vary from deployment to deployment, a specific non-goal of the Working Group is to define acceptance criteria or performance requirements. An ongoing task is to provide a forum for development and advancement of measurements which provide insight on the capabilities and operation of implementations of inter-networking technology. Ideally, BMWG should communicate with the operations community through organizations such as NANOG, RIPE, and APRICOT, and consult with/inform other IETF WGs (as is the current practice). Goals and Milestones: Dec 2023 - Draft on General VNF Benchmarking Automation to IESG Review Dec 2023 - Considerations for Benchmarking Network Virtualization Platforms to IESG Review Jan 2024 - Draft on Selecting and Applying Model(s) for Benchmarking to IESG Review Sep 2024 - Benchmarking for Stateful NATxy Gateways using RFC4814 Pseudorandom port numbers to IESG review Jan 2025 - Draft on Multiple Loss Ratio Search to IESG Review Done - Update to RFC2544 Back-to-back Frame Benchmarking to IESG Review Done, But did not progress at IESG - Methodology for EVPN Benchmarking to IESG Review Internet-Drafts: - Considerations for Benchmarking Network Performance in Containerized Infrastructures [draft-dcn-bmwg-containerized-infra-13] (25 pages) - Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful [draft-ietf-bmwg-2544-as-08] (11 pages) - Framework for Accelerated Stress Benchmarking [draft-ietf-bmwg-acc-bench-framework-00] (7 pages) - Methodology Guidelines for Accelerated Stress Benchmarking [draft-ietf-bmwg-acc-bench-meth-09] (13 pages) - Methodology for Benchmarking Accelerated Stress with Operational EBGP Instabilities [draft-ietf-bmwg-acc-bench-meth-ebgp-00] (9 pages) - Methodology for Benchmarking Accelerated Stress with Operational Security [draft-ietf-bmwg-acc-bench-meth-opsec-00] (7 pages) - Terminology for Accelerated Stress Benchmarking [draft-ietf-bmwg-acc-bench-term-13] (27 pages) - Methodology for ATM Benchmarking [draft-ietf-bmwg-atm-method-03] (127 pages) - Terminology for ATM Benchmarking [draft-ietf-bmwg-atm-term-00] (32 pages) - Terminology for ATM ABR Benchmarking [draft-ietf-bmwg-atm-term-abr-03] (16 pages) - Updates for the Back-to-Back Frame Benchmark in RFC 2544 [draft-ietf-bmwg-b2b-frame-04] (13 pages) - Benchmarking Methodology for Stateful NATxy Gateways using RFC 4814 Pseudorandom Port Numbers [draft-ietf-bmwg-benchmarking-stateful-09] (31 pages) - Benchmarking Methodology for Routers Supporting Resource Reservation [draft-ietf-bmwg-benchres-method-00] (15 pages) - Benchmarking Terminology for Resource Reservation Capable Routers [draft-ietf-bmwg-benchres-term-08] (24 pages) - Benchmarking Methodology for Basic BGP Convergence [draft-ietf-bmwg-bgpbas-01] (16 pages) - Basic BGP Convergence Benchmarking Methodology for Data-Plane Convergence [draft-ietf-bmwg-bgp-basic-convergence-05] (35 pages) - Benchmarking Methodology for Content-Aware Network Devices [draft-ietf-bmwg-ca-bench-meth-04] (19 pages) - Terminology for Cell/Call Benchmarking [draft-ietf-bmwg-call-04] (29 pages) - Considerations for Benchmarking Network Performance in Containerized Infrastructures [draft-ietf-bmwg-containerized-infra-01] (27 pages) - Terminology for Benchmarking BGP Device Convergence in the Control Plane [draft-ietf-bmwg-conterm-06] (36 pages) - Data Center Benchmarking Methodology [draft-ietf-bmwg-dcbench-methodology-18] (19 pages) - Data Center Benchmarking Terminology [draft-ietf-bmwg-dcbench-terminology-19] (20 pages) - Methodology for Benchmarking Network-layer Traffic Control Mechanisms [draft-ietf-bmwg-dsmmeth-02] (13 pages) - Terminology for Benchmarking Network-layer Traffic Control Mechanisms [draft-ietf-bmwg-dsmterm-13] (34 pages) - Benchmarking Methodology for Ethernet Switches [draft-ietf-bmwg-ethernet-switches-01] (13 pages) - Benchmarking Methodology for EVPN and PBB-EVPN [draft-ietf-bmwg-evpntest-11] (27 pages) - Methodology for Forwarding Information Base (FIB) based Router Performance [draft-ietf-bmwg-fib-meth-03] (13 pages) - Terminology for Forwarding Information Base (FIB) based Router Performance [draft-ietf-bmwg-fib-term-04] (15 pages) - Benchmarking Methodology for Firewall Performance [draft-ietf-bmwg-firewall-08] (34 pages) - Terminology for Frame Relay Benchmarking [draft-ietf-bmwg-fr-term-06] (24 pages) - Hash and Stuffing: Overlooked Factors in Network Device Benchmarking [draft-ietf-bmwg-hash-stuffing-08] (26 pages) - Considerations for Benchmarking Link-State IGP Data Plane Route Convergence [draft-ietf-bmwg-igp-dataplane-conv-app-17] (6 pages) - Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence [draft-ietf-bmwg-igp-dataplane-conv-meth-23] (42 pages) - Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence [draft-ietf-bmwg-igp-dataplane-conv-term-23] (29 pages) - IMIX Genome: Specification of Variable Packet Sizes for Additional Testing [draft-ietf-bmwg-imix-genome-05] (10 pages) - IP Flow Information Accounting and Export Benchmarking Methodology [draft-ietf-bmwg-ipflow-meth-10] (39 pages) - Connectivity [draft-ietf-bmwg-ippm-connect-00] (9 pages) - Methodology for Benchmarking IPsec Devices [draft-ietf-bmwg-ipsec-meth-05] (41 pages) - Terminology for Benchmarking IPsec Devices [draft-ietf-bmwg-ipsec-term-12] (46 pages) - IPv6 Benchmarking Methodology for Network Interconnect Devices [draft-ietf-bmwg-ipv6-meth-05] (20 pages) - Benchmarking the Neighbor Discovery Protocol [draft-ietf-bmwg-ipv6-nd-06] (17 pages) - Benchmarking Methodology for IPv6 Transition Technologies [draft-ietf-bmwg-ipv6-tran-tech-benchmarking-08] (30 pages) - Benchmarking Methodology for In-Service Software Upgrade (ISSU) [draft-ietf-bmwg-issu-meth-02] (16 pages) - Benchmarking Terminology for LAN Switching Devices [draft-ietf-bmwg-lanswitch-06] (25 pages) - Terminology for IP Multicast Benchmarking [draft-ietf-bmwg-mcast-08] (16 pages) - Methodology for IP Multicast Benchmarking [draft-ietf-bmwg-mcastm-14] (31 pages) - Benchmarking Methodology for Network Interconnect Devices [draft-ietf-bmwg-methodology-02] (30 pages) - Multiple Loss Ratio Search [draft-ietf-bmwg-mlrsearch-07] (50 pages) - MPLS Forwarding Benchmarking Methodology for IP Flows [draft-ietf-bmwg-mpls-forwarding-meth-06] (27 pages) - Benchmarking Methodology for LAN Switching Devices [draft-ietf-bmwg-mswitch-04] (35 pages) - A YANG Data Model for Network Tester Management [draft-ietf-bmwg-network-tester-cfg-04] (26 pages) - Benchmarking Methodology for Network Security Device Performance [draft-ietf-bmwg-ngfw-performance-15] (51 pages) - Considerations When Using Basic OSPF Convergence Benchmarks [draft-ietf-bmwg-ospfconv-applicability-07] (11 pages) - Benchmarking Basic OSPF Single Router Control Plane Convergence [draft-ietf-bmwg-ospfconv-intraarea-10] (16 pages) - OSPF Benchmarking Terminology and Concepts [draft-ietf-bmwg-ospfconv-term-10] (9 pages) - Benchmarking Methodologies for Overall Network Performance [draft-ietf-bmwg-overallperf-00] (6 pages) - Methodology for Benchmarking MPLS Traffic Engineered (MPLS-TE) Fast Reroute Protection [draft-ietf-bmwg-protection-meth-14] (35 pages) - Benchmarking Terminology for Protection Performance [draft-ietf-bmwg-protection-term-09] (33 pages) - Device Reset Characterization [draft-ietf-bmwg-reset-06] (17 pages) - Framework for Router Benchmarking [draft-ietf-bmwg-rtr-framework-00] (8 pages) - Benchmarking Methodology for Software-Defined Networking (SDN) Controller Performance [draft-ietf-bmwg-sdn-controller-benchmark-meth-09] (64 pages) - Terminology for Benchmarking Software-Defined Networking (SDN) Controller Performance [draft-ietf-bmwg-sdn-controller-benchmark-term-10] (23 pages) - Benchmarking Terminology for Firewall Performance [draft-ietf-bmwg-secperf-08] (26 pages) - Methodology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration [draft-ietf-bmwg-sip-bench-meth-12] (21 pages) - Terminology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration [draft-ietf-bmwg-sip-bench-term-12] (20 pages) - Benchmarking Methodology for Segment Routing [draft-ietf-bmwg-sr-bench-meth-01] (27 pages) - Benchmarking Terminology for Network Interconnection Devices [draft-ietf-bmwg-terms-01] (12 pages) - Traffic Management Benchmarking [draft-ietf-bmwg-traffic-management-06] (51 pages) - Considerations for Benchmarking Virtual Network Functions and Their Infrastructure [draft-ietf-bmwg-virtual-net-05] (15 pages) - Benchmarking Virtual Switches in the Open Platform for NFV (OPNFV) [draft-ietf-bmwg-vswitch-opnfv-04] (24 pages) - Benchmarking Methodology for EVPN and PBB-EVPN [draft-kishjac-bmwg-evpntest-10] (22 pages) - Benchmarking Methodology for Stateful NATxy Gateways using RFC 4814 Pseudorandom Port Numbers [draft-lencse-bmwg-benchmarking-stateful-04] (22 pages) Requests for Comments: RFC1242: Benchmarking Terminology for Network Interconnection Devices (12 pages) * Updates RFC6201 RFC1944: Benchmarking Methodology for Network Interconnect Devices (30 pages) * Obsoletes RFC2544 RFC2285: Benchmarking Terminology for LAN Switching Devices (25 pages) RFC2432: Terminology for IP Multicast Benchmarking (16 pages) RFC2647: Benchmarking Terminology for Firewall Performance (26 pages) RFC2761: Terminology for ATM Benchmarking (32 pages) RFC2889: Benchmarking Methodology for LAN Switching Devices (35 pages) RFC3116: Methodology for ATM Benchmarking (127 pages) RFC3133: Terminology for Frame Relay Benchmarking (24 pages) RFC3134: Terminology for ATM ABR Benchmarking (16 pages) RFC3222: Terminology for Forwarding Information Base (FIB) based Router Performance (15 pages) RFC3511: Benchmarking Methodology for Firewall Performance (34 pages) * Obsoletes RFC9411 RFC3918: Methodology for IP Multicast Benchmarking (31 pages) RFC4061: Benchmarking Basic OSPF Single Router Control Plane Convergence (16 pages) RFC4062: OSPF Benchmarking Terminology and Concepts (9 pages) RFC4063: Considerations When Using Basic OSPF Convergence Benchmarks (11 pages) RFC4098: Terminology for Benchmarking BGP Device Convergence in the Control Plane (36 pages) RFC4689: Terminology for Benchmarking Network-layer Traffic Control Mechanisms (34 pages) RFC4814: Hash and Stuffing: Overlooked Factors in Network Device Benchmarking (26 pages) RFC4883: Benchmarking Terminology for Resource Reservation Capable Routers (24 pages) RFC5180: IPv6 Benchmarking Methodology for Network Interconnect Devices (20 pages) RFC5695: MPLS Forwarding Benchmarking Methodology for IP Flows (27 pages) RFC6201: Device Reset Characterization (17 pages) RFC6412: Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence (29 pages) RFC6413: Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence (42 pages) RFC6414: Benchmarking Terminology for Protection Performance (33 pages) RFC6645: IP Flow Information Accounting and Export Benchmarking Methodology (39 pages) RFC6815: Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful (11 pages) RFC6894: Methodology for Benchmarking MPLS Traffic Engineered (MPLS-TE) Fast Reroute Protection (35 pages) RFC6985: IMIX Genome: Specification of Variable Packet Sizes for Additional Testing (10 pages) RFC7501: Terminology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration (20 pages) RFC7502: Methodology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration (21 pages) RFC7640: Traffic Management Benchmarking (51 pages) RFC7654: Benchmarking Methodology for In-Service Software Upgrade (ISSU) (16 pages) RFC7747: Basic BGP Convergence Benchmarking Methodology for Data-Plane Convergence (35 pages) RFC8161: Benchmarking the Neighbor Discovery Protocol (17 pages) RFC8172: Considerations for Benchmarking Virtual Network Functions and Their Infrastructure (15 pages) RFC8204: Benchmarking Virtual Switches in the Open Platform for NFV (OPNFV) (24 pages) RFC8219: Benchmarking Methodology for IPv6 Transition Technologies (30 pages) RFC8238: Data Center Benchmarking Terminology (20 pages) RFC8239: Data Center Benchmarking Methodology (19 pages) RFC8455: Terminology for Benchmarking Software-Defined Networking (SDN) Controller Performance (23 pages) RFC8456: Benchmarking Methodology for Software-Defined Networking (SDN) Controller Performance (64 pages) RFC9004: Updates for the Back-to-Back Frame Benchmark in RFC 2544 (13 pages) RFC9411: Benchmarking Methodology for Network Security Device Performance (51 pages) Domain Name System Operations (dnsop) ------------------------------------- Charter Last Modified: 2024-06-05 Current Status: Active Chairs: Benno Overeinder Suzanne Woolf Tim Wicinski Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari Operations and Management Area Advisor: Warren Kumari Mailing Lists: General Discussion: dnsop@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dnsop Archive: https://mailarchive.ietf.org/arch/browse/dnsop/ Description of Working Group: The DNS Operations Working Group will develop guidelines for the operation of DNS software and services and for the administration of DNS zones. 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. Describe practices 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, TLD name servers, or any other resolver or server functioning as part of the global DNS. 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 and services, including root, TLD, and recursive servers. 2. Publish documents concerning DNSSEC operational procedures. 3. Publish documents concerning DNS operational procedures in IPv6 and mixed IPv6-IPv4 networks, and provide documentation and guidance on DNS-related IPv6 transition and coexistence issues. 4. Publish documents to address operational issues with the DNS protocols by extending or performing protocol maintenance on them. Act as focal-point for operator discussion and provide advice to the Ops ADs and other WGs on EDNS0 options, new RRTYPEs, DNSSEC, record synthesis, or other mechanics of extending DNS to support other applications. 5. Serve as a home for drafts that document the problem space around existing or new DNS issues. The group, with the advice and consent of the responsible AD in coordination with other areas, will then decide whether these issues belong in DNSOP under the existing charter and, if not, will work with the authors and appropriate ADs to determine the proper place for the work to be carried out. 6. Publish documents that attempt to better define the overlapping area among the public DNS root, DNS-like names as used in local or restricted naming scopes, and the 'special names' registry that IETF manages, perhaps including how they might interact. This work must take into consideration issues that are strictly beyond the operation of the DNS itself, and the working group will consult with IETF liaisons to other organizations as appropriate. Goals and Milestones: Done - IESG Appoval for dnssec-key-timing Internet-Drafts: - A Common Operational Problem in DNS Servers - Failure To Respond. [draft-andrews-dns-no-response-issue-16] (16 pages) - Glue In DNS Referral Responses Is Not Optional [draft-andrews-dnsop-glue-is-not-optional-01] (5 pages) - The .onion Special-Use Domain Name [draft-appelbaum-dnsop-onion-tld-01] (6 pages) - DNS Error Reporting [draft-arends-dns-error-reporting-00] (10 pages) - Top-level Domains for Private Internets [draft-arends-private-use-tld-02] (12 pages) - DNSSEC Trust Anchor Publication for the Root Zone [draft-bash-rfc7958bis-01] (11 pages) - In the DNS, QDCOUNT is (usually) One [draft-bellis-dnsop-qdcount-is-one-01] (7 pages) - DNS Session Signaling [draft-bellis-dnsop-session-signal-02] (13 pages) - Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC [draft-belyavskiy-rfc5933-bis-02] (8 pages) - NXDOMAIN really means there is nothing underneath [draft-bortzmeyer-dnsop-nxdomain-cut-02] (9 pages) - DNS query name minimisation to improve privacy [draft-bortzmeyer-dns-qname-minimisation-02] (6 pages) - DNS Query Name Minimisation to Improve Privacy [draft-bortzmeyer-rfc7816bis-00] (12 pages) - DNS Scoped Data Through '_Underscore' Attribute Leaves [draft-crocker-dns-attrleaf-07] (13 pages) - DNS Transport over TCP - Implementation Requirements [draft-dickinson-dnsop-5966-bis-00] (12 pages) - C-DNS: A DNS Packet Capture Format [draft-dickinson-dnsop-dns-capture-format-00] (37 pages) - Providing Minimal-Sized Responses to DNS Queries with QTYPE=ANY [draft-dnsop-refuse-any-00] (16 pages) - Secret Key Transaction Authentication for DNS (TSIG) [draft-dupont-dnsop-rfc2845bis-01] (23 pages) - Negative Caching of DNS Resolution Failures [draft-dwmtwc-dnsop-caching-resolution-failures-01] (13 pages) - Domain Name System (DNS) Cookies [draft-eastlake-dnsext-cookies-05] (27 pages) - Classless IN-ADDR.ARPA delegation and dynamic reverse DNS UPDATE [draft-fanf-dnsop-rfc2317bis-01] (22 pages) - Fragmentation Avoidance in DNS [draft-fujiwara-dnsop-avoid-fragmentation-03] (10 pages) - Aggressive use of NSEC/NSEC3 [draft-fujiwara-dnsop-nsec-aggressiveuse-03] (14 pages) - Updating Resolver Algorithm [draft-fujiwara-dnsop-resolver-update-00] (9 pages) - Remove deprecated GOST algorithms from active use within DNSSEC [draft-hardaker-dnsop-must-not-ecc-gost-02] (5 pages) - Remove SHA-1 from active use within DNSSEC [draft-hardaker-dnsop-must-not-sha1-03] (5 pages) - DNSSEC Cryptographic Algorithm Recommendation Update Process [draft-hardaker-dnsop-rfc8624-bis-04] (12 pages) - Security Considerations for RFC5011 Publishers [draft-hardaker-rfc5011-security-considerations-04] (9 pages) - DNS Security Extensions (DNSSEC) [draft-hoffman-dnssec-00] (7 pages) - Revised IANA Considerations for DNSSEC [draft-hoffman-dnssec-iana-cons-01] (4 pages) - Terminology for DNS Transports and Location [draft-hoffman-dns-terminology-ter-02] (3 pages) - Reverse DNS in IPv6 for Internet Service Providers [draft-howard-isp-ip6rdns-08] (13 pages) - Address-specific DNS Name Redirection (ANAME) [draft-hunt-dnsop-aname-00] (10 pages) - Compact Denial of Existence in DNSSEC [draft-huque-dnsop-compact-lies-01] (8 pages) - Greasing Protocol Extension Points in the DNS [draft-huque-dnsop-grease-02] (8 pages) - Multi Provider DNSSEC models [draft-huque-dnsop-multi-provider-dnssec-04] (11 pages) - Delegation Revalidation by DNS Resolvers [draft-huque-dnsop-ns-revalidation-01] (7 pages) - A Sentinel for Detecting Trusted Keys in DNSSEC [draft-huston-kskroll-sentinel-04] (8 pages) - DNS Transport over TCP - Implementation Requirements [draft-ietf-dnsop-5966bis-06] (19 pages) - Running a Root Server Local to a Resolver [draft-ietf-dnsop-7706bis-12] (12 pages) - Algorithm Implementation Requirements and Usage Guidance for DNSSEC [draft-ietf-dnsop-algorithm-update-10] (11 pages) - The .alt Special-Use Top-Level Domain [draft-ietf-dnsop-alt-tld-25] (7 pages) - AS112 Redirection Using DNAME [draft-ietf-dnsop-as112-dname-06] (16 pages) - AS112 Nameserver Operations [draft-ietf-dnsop-as112-ops-09] (18 pages) - I'm Being Attacked by PRISONER.IANA.ORG! [draft-ietf-dnsop-as112-under-attack-help-help-06] (8 pages) - Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves [draft-ietf-dnsop-attrleaf-16] (15 pages) - DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names [draft-ietf-dnsop-attrleaf-fix-07] (15 pages) - IP Fragmentation Avoidance in DNS over UDP [draft-ietf-dnsop-avoid-fragmentation-18] (14 pages) - Observed DNS Resolution Misbehavior [draft-ietf-dnsop-bad-dns-res-06] (18 pages) - Negative Caching of DNS Resolution Failures [draft-ietf-dnsop-caching-resolution-failures-08] (19 pages) - Consistency for CDS/CDNSKEY and CSYNC is Mandatory [draft-ietf-dnsop-cds-consistency-04] (13 pages) - Child-to-Parent Synchronization in DNS [draft-ietf-dnsop-child-syncronization-07] (15 pages) - Compact Denial of Existence in DNSSEC [draft-ietf-dnsop-compact-denial-of-existence-04] (13 pages) - Domain Name System (DNS) Cookies [draft-ietf-dnsop-cookies-10] (25 pages) - Locally Served DNS Zones [draft-ietf-dnsop-default-local-zones-15] (10 pages) - The DELEGATION_ONLY DNSKEY flag [draft-ietf-dnsop-delegation-only-02] (11 pages) - Automating DNSSEC Delegation Trust Maintenance [draft-ietf-dnsop-delegation-trust-maintainance-14] (18 pages) - Compacted-DNS (C-DNS): A Format for DNS Packet Capture [draft-ietf-dnsop-dns-capture-format-10] (79 pages) - DNS Catalog Zones [draft-ietf-dnsop-dns-catalog-zones-09] (16 pages) - DNS Error Reporting [draft-ietf-dnsop-dns-error-reporting-08] (12 pages) - DNSSEC automation [draft-ietf-dnsop-dnssec-automation-02] (11 pages) - DNS Security Extensions (DNSSEC) [draft-ietf-dnsop-dnssec-bcp-06] (10 pages) - Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator [draft-ietf-dnsop-dnssec-bootstrapping-11] (18 pages) - A Framework for DNSSEC Policies and DNSSEC Practice Statements [draft-ietf-dnsop-dnssec-dps-framework-11] (27 pages) - Revised IANA Considerations for DNSSEC [draft-ietf-dnsop-dnssec-iana-cons-05] (5 pages) - DNSSEC Key Rollover Timing Considerations [draft-ietf-dnsop-dnssec-key-timing-06] (31 pages) - DNSSEC Operational Practices [draft-ietf-dnsop-dnssec-operational-practices-08] (35 pages) - DNSSEC Roadblock Avoidance [draft-ietf-dnsop-dnssec-roadblock-avoidance-05] (19 pages) - DNS Transport over TCP - Operational Requirements [draft-ietf-dnsop-dns-tcp-requirements-15] (29 pages) - DNS Terminology [draft-ietf-dnsop-dns-terminology-05] (27 pages) - Message Digest for DNS Zones [draft-ietf-dnsop-dns-zone-digest-14] (31 pages) - Domain Control Validation using DNS [draft-ietf-dnsop-domain-verification-techniques-05] (25 pages) - CHAIN Query Requests in DNS [draft-ietf-dnsop-edns-chain-query-07] (16 pages) - Client Subnet in DNS Queries [draft-ietf-dnsop-edns-client-subnet-08] (30 pages) - Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) [draft-ietf-dnsop-edns-key-tag-05] (13 pages) - The edns-tcp-keepalive EDNS0 Option [draft-ietf-dnsop-edns-tcp-keepalive-06] (11 pages) - Extended DNS Errors [draft-ietf-dnsop-extended-error-16] (13 pages) - Generalized DNS Notifications [draft-ietf-dnsop-generalized-notify-02] (18 pages) - DNS Glue Requirements in Referral Responses [draft-ietf-dnsop-glue-is-not-optional-09] (9 pages) - Distributing Authoritative Name Servers via Shared Unicast Addresses [draft-ietf-dnsop-hardie-shared-root-server-07] (11 pages) - YANG Types for DNS Classes and Resource Record Types [draft-ietf-dnsop-iana-class-type-yang-05] (14 pages) - IPv6 Host Configuration of DNS Server Information Approaches [draft-ietf-dnsop-ipv6-dns-configuration-06] (26 pages) - Operational Considerations and Issues with IPv6 DNS [draft-ietf-dnsop-ipv6-dns-issues-12] (29 pages) - DNS IPv6 Transport Operational Guidelines [draft-ietf-dnsop-ipv6-transport-guidelines-02] (5 pages) - Reverse DNS in IPv6 for Internet Service Providers [draft-ietf-dnsop-isp-ip6rdns-07] (15 pages) - A Root Key Trust Anchor Sentinel for DNSSEC [draft-ietf-dnsop-kskroll-sentinel-17] (19 pages) - Managing DS Records from the Parent via CDS/CDNSKEY [draft-ietf-dnsop-maintain-ds-06] (10 pages) - Common Misbehavior Against DNS Queries for IPv6 Addresses [draft-ietf-dnsop-misbehavior-against-aaaa-02] (6 pages) - Multi-Signer DNSSEC Models [draft-ietf-dnsop-multi-provider-dnssec-05] (13 pages) - Remove deprecated GOST algorithms from active use within DNSSEC [draft-ietf-dnsop-must-not-ecc-gost-00] (5 pages) - Remove SHA-1 from active use within DNSSEC [draft-ietf-dnsop-must-not-sha1-00] (5 pages) - Requirements for Management of Name Servers for the DNS [draft-ietf-dnsop-name-server-management-reqs-05] (17 pages) - Definition and Use of DNSSEC Negative Trust Anchors [draft-ietf-dnsop-negative-trust-anchors-13] (16 pages) - A Common Operational Problem in DNS Servers: Failure to Communicate [draft-ietf-dnsop-no-response-issue-23] (24 pages) - Guidance for NSEC3 Parameter Settings [draft-ietf-dnsop-nsec3-guidance-10] (10 pages) - Aggressive Use of DNSSEC-Validated Cache [draft-ietf-dnsop-nsec-aggressiveuse-10] (13 pages) - NSEC and NSEC3: TTLs and Aggressive Use [draft-ietf-dnsop-nsec-ttl-05] (8 pages) - Delegation Revalidation by DNS Resolvers [draft-ietf-dnsop-ns-revalidation-07] (13 pages) - NXDOMAIN: There Really Is Nothing Underneath [draft-ietf-dnsop-nxdomain-cut-05] (10 pages) - Moving DNSSEC Lookaside Validation (DLV) to Historic Status [draft-ietf-dnsop-obsolete-dlv-02] (6 pages) - The ".onion" Special-Use Domain Name [draft-ietf-dnsop-onion-tld-01] (7 pages) - In the DNS, QDCOUNT is (usually) One [draft-ietf-dnsop-qdcount-is-one-04] (7 pages) - DNS Query Name Minimisation to Improve Privacy [draft-ietf-dnsop-qname-minimisation-09] (11 pages) - Preventing Use of Recursive Nameservers in Reflector Attacks [draft-ietf-dnsop-reflectors-are-evil-06] (7 pages) - Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY [draft-ietf-dnsop-refuse-any-07] (10 pages) - Initializing a DNS Resolver with Priming Queries [draft-ietf-dnsop-resolver-priming-11] (7 pages) - DNS Referral Response Size Issues [draft-ietf-dnsop-respsize-15] (21 pages) - Classless IN-ADDR.ARPA delegation and dynamic reverse DNS UPDATE [draft-ietf-dnsop-rfc2317bis-00] (22 pages) - Secret Key Transaction Authentication for DNS (TSIG) [draft-ietf-dnsop-rfc2845bis-09] (22 pages) - DNSSEC Operational Practices, Version 2 [draft-ietf-dnsop-rfc4641bis-13] (71 pages) - Security Considerations for RFC5011 Publishers [draft-ietf-dnsop-rfc5011-security-considerations-13] (20 pages) - Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC [draft-ietf-dnsop-rfc5933-bis-14] (11 pages) - AS112 Nameserver Operations [draft-ietf-dnsop-rfc6304bis-06] (24 pages) - Adding 100.64.0.0/10 Prefixes to the IPv4 Locally-Served DNS Zones Registry [draft-ietf-dnsop-rfc6598-rfc6303-05] (6 pages) - DNS Query Name Minimisation to Improve Privacy [draft-ietf-dnsop-rfc7816bis-11] (11 pages) - DNSSEC Trust Anchor Publication for the Root Zone [draft-ietf-dnsop-rfc7958bis-06] (14 pages) - Initializing a DNS Resolver with Priming Queries [draft-ietf-dnsop-rfc8109bis-07] (11 pages) - DNS Terminology [draft-ietf-dnsop-rfc8499bis-10] (57 pages) - DNSSEC Cryptographic Algorithm Recommendation Update Process [draft-ietf-dnsop-rfc8624-bis-00] (12 pages) - Decreasing Access Time to Root Servers by Running One on Loopback [draft-ietf-dnsop-root-loopback-05] (12 pages) - Root Name Server Operational Requirements [draft-ietf-dnsop-root-opreq-04] (10 pages) - The "RRSERIAL" EDNS option for the SOA serial of a RR's zone [draft-ietf-dnsop-rrserial-01] (6 pages) - Interoperable Domain Name System (DNS) Server Cookies [draft-ietf-dnsop-server-cookies-05] (16 pages) - Requirements for a Mechanism Identifying a Name Server Instance [draft-ietf-dnsop-serverid-08] (8 pages) - Serving Stale Data to Improve DNS Resiliency [draft-ietf-dnsop-serve-stale-10] (12 pages) - DNS Stateful Operations [draft-ietf-dnsop-session-signal-20] (64 pages) - Structured Error Data for Filtered DNS [draft-ietf-dnsop-structured-dns-error-09] (23 pages) - Special-Use Domain Names Problem Statement [draft-ietf-dnsop-sutld-ps-08] (25 pages) - Using DNSSEC Authentication of Named Entities (DANE) with DNS Service Bindings (SVCB) and QUIC [draft-ietf-dnsop-svcb-dane-04] (13 pages) - Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) [draft-ietf-dnsop-svcb-https-12] (47 pages) - Service binding and parameter specification via the DNS (DNS SVCB and HTTPSSVC) [draft-ietf-dnsop-svcb-httpssvc-03] (39 pages) - DNS Terminology [draft-ietf-dnsop-terminology-bis-14] (50 pages) - Terminology for DNS Transports and Location [draft-ietf-dnsop-terminology-ter-02] (3 pages) - DNS TIMEOUT Resource Record [draft-ietf-dnsop-update-timeout-01] (18 pages) - The DNS Zone Version (ZONEVERSION) Option [draft-ietf-dnsop-zoneversion-11] (14 pages) - Providing Minimal-Sized Responses to DNS Queries with QTYPE=ANY [draft-jabley-dnsop-refuse-any-01] (16 pages) - Decreasing Access Time to Root Servers by Running One On The Same Server [draft-kh-dnsop-7706bis-01] (12 pages) - Initializing a DNS Resolver with Priming Queries [draft-klh-dnsop-rfc8109bis-06] (10 pages) - DNS Transport over TCP - Operational Requirements [draft-kristoff-dnsop-dns-tcp-requirements-02] (11 pages) - YANG Types for DNS Classes and Resource Record Types [draft-lhotka-dnsop-iana-class-type-yang-02] (24 pages) - Moving DNSSEC Lookaside Validation (DLV) to Historic Status [draft-mekking-dnsop-obsolete-dlv-00] (5 pages) - Recommendations for DNSSEC Resolvers Operators [draft-mglt-dnsop-dnssec-validator-requirements-09] (23 pages) - DNS Catalog Zones [draft-muks-dnsop-dns-catalog-zones-04] (16 pages) - Service binding and parameter specification via the DNS (DNS SVCB and HTTPSSVC) [draft-nygren-dnsop-svcb-httpssvc-00] (33 pages) - Managing DS records from parent via CDS/CDNSKEY [draft-ogud-dnsop-maintain-ds-00] (8 pages) - DNS TIMEOUT Resource Record [draft-pusateri-dnsop-update-timeout-05] (18 pages) - The DELEGATION_ONLY DNSKEY flag [draft-pwouters-powerbind-04] (11 pages) - Using Service Bindings with DANE [draft-rebs-dnsop-svcb-dane-01] (9 pages) - Survey of Domain Verification Techniques using DNS [draft-sahib-domain-verification-techniques-03] (12 pages) - DNS Resolver Information Self-publication [draft-sah-resolver-information-02] (9 pages) - The "RRSERIAL" EDNS option for the SOA serial of a RR's zone [draft-salgado-dnsop-rrserial-01] (6 pages) - DNS wire-format over HTTP [draft-song-dns-wireformat-http-04] (10 pages) - Interoperable Domain Name System (DNS) Server Cookies [draft-sury-toorop-dnsop-server-cookies-00] (14 pages) - Serving Stale Data to Improve DNS Resiliency [draft-tale-dnsop-serve-stale-02] (10 pages) - Consistency for CDS/CDNSKEY and CSYNC is Mandatory [draft-thomassen-dnsop-cds-consistency-03] (10 pages) - Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator [draft-thomassen-dnsop-dnssec-bootstrapping-03] (14 pages) - Generalized DNS Notifications [draft-thomassen-dnsop-generalized-dns-notify-02] (17 pages) - DNS Catalog Zones [draft-toorop-dnsop-dns-catalog-zones-01] (11 pages) - NSEC(3) TTLs and NSEC Aggressive Use [draft-vandijk-dnsop-nsec-ttl-00] (6 pages) - DNS Response Policy Zones (RPZ) [draft-vixie-dns-rpz-04] (30 pages) - Message Digest for DNS Zones [draft-wessels-dns-zone-digest-06] (27 pages) - The EDNS Key Tag Option [draft-wessels-edns-key-tag-00] (9 pages) - Let 'localhost' be localhost. [draft-west-let-localhost-be-localhost-06] (9 pages) - Structured Data for Filtered DNS [draft-wing-dnsop-structured-dns-error-page-05] (16 pages) - DNSSEC automation [draft-wisser-dnssec-automation-03] (12 pages) - The ALT Special Use Top Level Domain [draft-wkumari-dnsop-alt-tld-06] (10 pages) - Extended DNS Errors [draft-wkumari-dnsop-extended-error-02] (9 pages) - Decreasing Access Time to Root Servers by Running One on Loopback [draft-wkumari-dnsop-root-loopback-02] (9 pages) - Algorithm Implementation Requirements and Usage Guidance for DNSSEC [draft-wouters-sury-dnsop-algorithm-update-02] (9 pages) Requests for Comments: RFC2870: Root Name Server Operational Requirements (10 pages) * Obsoletes RFC7720 RFC3258: Distributing Authoritative Name Servers via Shared Unicast Addresses (11 pages) RFC3901: DNS IPv6 Transport Operational Guidelines (5 pages) RFC4074: Common Misbehavior Against DNS Queries for IPv6 Addresses (6 pages) RFC4339: IPv6 Host Configuration of DNS Server Information Approaches (26 pages) RFC4472: Operational Considerations and Issues with IPv6 DNS (29 pages) RFC4641: DNSSEC Operational Practices (35 pages) * Obsoletes RFC6781 RFC4697: Observed DNS Resolution Misbehavior (18 pages) * Updates RFC9520 RFC4892: Requirements for a Mechanism Identifying a Name Server Instance (8 pages) RFC5358: Preventing Use of Recursive Nameservers in Reflector Attacks (7 pages) RFC6168: Requirements for Management of Name Servers for the DNS (17 pages) RFC6303: Locally Served DNS Zones (10 pages) RFC6304: AS112 Nameserver Operations (18 pages) * Obsoletes RFC7534 RFC6305: I'm Being Attacked by PRISONER.IANA.ORG! (8 pages) RFC6781: DNSSEC Operational Practices, Version 2 (71 pages) RFC6841: A Framework for DNSSEC Policies and DNSSEC Practice Statements (27 pages) RFC7344: Automating DNSSEC Delegation Trust Maintenance (18 pages) * Updates RFC8078 * Updates RFC9615 RFC7477: Child-to-Parent Synchronization in DNS (15 pages) RFC7534: AS112 Nameserver Operations (24 pages) RFC7535: AS112 Redirection Using DNAME (16 pages) RFC7583: DNSSEC Key Rollover Timing Considerations (31 pages) RFC7646: Definition and Use of DNSSEC Negative Trust Anchors (16 pages) RFC7686: The ".onion" Special-Use Domain Name (7 pages) RFC7706: Decreasing Access Time to Root Servers by Running One on Loopback (12 pages) * Obsoletes RFC8806 RFC7719: DNS Terminology (27 pages) * Obsoletes RFC8499 RFC7766: DNS Transport over TCP - Implementation Requirements (19 pages) * Updates RFC8490 * Updates RFC9103 RFC7793: Adding 100.64.0.0/10 Prefixes to the IPv4 Locally-Served DNS Zones Registry (6 pages) RFC7816: DNS Query Name Minimisation to Improve Privacy (11 pages) * Obsoletes RFC9156 RFC7828: The edns-tcp-keepalive EDNS0 Option (11 pages) RFC7871: Client Subnet in DNS Queries (30 pages) RFC7873: Domain Name System (DNS) Cookies (25 pages) * Updates RFC9018 RFC7901: CHAIN Query Requests in DNS (16 pages) RFC8020: NXDOMAIN: There Really Is Nothing Underneath (10 pages) RFC8027: DNSSEC Roadblock Avoidance (19 pages) RFC8078: Managing DS Records from the Parent via CDS/CDNSKEY (10 pages) * Updates RFC9615 RFC8109: Initializing a DNS Resolver with Priming Queries (7 pages) RFC8145: Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) (13 pages) * Updates RFC8553 RFC8198: Aggressive Use of DNSSEC-Validated Cache (13 pages) * Updates RFC9077 RFC8244: Special-Use Domain Names Problem Statement (25 pages) RFC8482: Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY (10 pages) RFC8490: DNS Stateful Operations (64 pages) RFC8499: DNS Terminology (50 pages) * Obsoletes RFC9499 RFC8501: Reverse DNS in IPv6 for Internet Service Providers (15 pages) RFC8509: A Root Key Trust Anchor Sentinel for DNSSEC (19 pages) RFC8552: Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves (15 pages) RFC8553: DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names (15 pages) RFC8618: Compacted-DNS (C-DNS): A Format for DNS Packet Capture (79 pages) RFC8624: Algorithm Implementation Requirements and Usage Guidance for DNSSEC (11 pages) * Updates RFC9157 RFC8749: Moving DNSSEC Lookaside Validation (DLV) to Historic Status (6 pages) RFC8767: Serving Stale Data to Improve DNS Resiliency (12 pages) RFC8806: Running a Root Server Local to a Resolver (12 pages) RFC8901: Multi-Signer DNSSEC Models (13 pages) RFC8906: A Common Operational Problem in DNS Servers: Failure to Communicate (24 pages) RFC8914: Extended DNS Errors (13 pages) RFC8945: Secret Key Transaction Authentication for DNS (TSIG) (22 pages) RFC8976: Message Digest for DNS Zones (31 pages) RFC9018: Interoperable Domain Name System (DNS) Server Cookies (16 pages) RFC9077: NSEC and NSEC3: TTLs and Aggressive Use (8 pages) RFC9108: YANG Types for DNS Classes and Resource Record Types (14 pages) RFC9156: DNS Query Name Minimisation to Improve Privacy (11 pages) RFC9157: Revised IANA Considerations for DNSSEC (5 pages) RFC9210: DNS Transport over TCP - Operational Requirements (29 pages) RFC9276: Guidance for NSEC3 Parameter Settings (10 pages) RFC9364: DNS Security Extensions (DNSSEC) (10 pages) RFC9432: DNS Catalog Zones (16 pages) RFC9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) (47 pages) RFC9471: DNS Glue Requirements in Referral Responses (9 pages) RFC9476: The .alt Special-Use Top-Level Domain (7 pages) RFC9499: DNS Terminology (45 pages) RFC9520: Negative Caching of DNS Resolution Failures (14 pages) RFC9567: DNS Error Reporting (11 pages) RFC9615: Automatic DNSSEC Bootstrapping Using Authenticated Signals from the Zone's Operator (12 pages) RFC9619: In the DNS, QDCOUNT Is (Usually) One (7 pages) Global Routing Operations (grow) -------------------------------- Charter Last Modified: 2022-05-06 Current Status: Active Chairs: Chris Morrow Job Snijders Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari Operations and Management Area Advisor: Warren Kumari Mailing Lists: General Discussion: grow@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/grow Archive: https://mailarchive.ietf.org/arch/browse/grow/ Description of Working Group: The Border Gateway Protocol (BGP) is fundamental to the operation of the Internet. In recent years, occurrences of BGP related operational issues have increased, and while overall understanding of the default-free routing system has improved, there is still a long and growing list of concerns. Among these are routing table growth rates, interaction of interior and exterior routing protocols, dynamic properties of the routing system, and the effects of routing policy on both the size and dynamic nature of the routing table. In addition, new and innovative uses of BGP, such as the use of BGP as a signaling protocol for some types of Virtual Private Networks, have created new and unexpected operational issues. The purpose of the GROW is to consider the operational problems associated with the IPv4 and IPv6 global routing systems, including but not limited to routing table growth, the effects of the interactions between interior and exterior routing protocols, and the effect of address allocation policies and practices on the global routing system. Finally, where appropriate, the GROW documents the operational aspects of measurement, policy, security, and VPN infrastructures. GROW will also advise various working groups, including the IDR and RPSEC working groups, with respect to whether it is addressing the relevant operational needs, and where appropriate, suggest course corrections. Finally, operational requirements developed in GROW can also be used by any new working group charged with standardizing a next generation inter-domain routing protocol. GOALS: ----- (i). Evaluate and develop various methodologies of controlling policy information in order to reduce the effect of prefix sub-aggregates beyond the necessary diameter, so as to reduce the Network Layer Reachability Information (or NLRI; see e.g.,draft-ietf-idr-bgp4-23.txt) load on network infrastructure. (ii). Document and suggest operational solutions to problematic aspects of the currently deployed routing system. Examples include instability caused by oscillation of MULTI_EXIT_DISC (or MED; see RFC 3345) values. (iii). Analyze aspects of supporting new applications, including extending existing routing protocols and creating new ones. This includes risk, interference and application fit. (iv). Determine the effect of IGP extensions on the stability of the Internet routing system. (v). Document the operational aspects of securing the Internet routing system, and provide recommendations to other WGs. Some Relevant References: ------------------------- http://www.routeviews.org http://bgp.potaroo.net http://www.cidr-report.org http://www.pch.net/routing/BGP_table_size.ital http://moat.nlanr.net/AS http://www.apnic.net/stats/bgp http://www.merit.edu/ipma http://www.caida.org/projects/routing/atoms Goals and Milestones: Done - Publish Risk, Interference and Fit (RIFT) document as WG I-D Done - Publish Embedding Globally ...Considered Harmful as WG I-D Done - Publish MED Considerations Draft as WG I-D Done - Publish Collection Communities as WG I-D Done - Submit Collection Communities to IESG for BCP Done - Submit Embedding Globally ...Considered Harmful to IESG for Info Done - Submit MED Considerations to IESG for Info Internet-Drafts: - Support for Adj-RIB-Out in BGP Monitoring Protocol (BMP) [draft-evens-grow-bmp-adj-rib-out-01] (10 pages) - Support for Local RIB in BGP Monitoring Protocol (BMP) [draft-evens-grow-bmp-local-rib-00] (12 pages) - Updated BGP Operations and Security [draft-fiebig-grow-bgpopsecupd-00] (46 pages) - BMP Loc-RIB: Peer address [draft-francois-grow-bmp-loc-peer-04] (9 pages) - Bounding Longest Match Considered [draft-grow-bounded-longest-match-00] (8 pages) - Operation of Anycast Services [draft-ietf-grow-anycast-04] (24 pages) - A well-known BGP community to denote prefixes used for Anycast [draft-ietf-grow-anycast-community-03] (6 pages) - AS Path Prepending [draft-ietf-grow-as-path-prepending-13] (13 pages) - Requirements for the Graceful Shutdown of BGP Sessions [draft-ietf-grow-bgp-graceful-shutdown-requirements-07] (20 pages) - Graceful BGP Session Shutdown [draft-ietf-grow-bgp-gshut-13] (12 pages) - BGP MULTI_EXIT_DISC (MED) Considerations [draft-ietf-grow-bgp-med-considerations-05] (13 pages) - Updated BGP Operations and Security [draft-ietf-grow-bgpopsecupd-03] (8 pages) - Controlling the redistribution of BGP routes [draft-ietf-grow-bgp-redistribution-00] (16 pages) - Default External BGP (EBGP) Route Propagation Behavior without Policies [draft-ietf-grow-bgp-reject-08] (7 pages) - Mitigating the Negative Impact of Maintenance through BGP Session Culling [draft-ietf-grow-bgp-session-culling-05] (10 pages) - BGP Wedgies [draft-ietf-grow-bgp-wedgies-03] (10 pages) - BLACKHOLE Community [draft-ietf-grow-blackholing-03] (9 pages) - BGP Monitoring Protocol (BMP) [draft-ietf-grow-bmp-17] (27 pages) - Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP) [draft-ietf-grow-bmp-adj-rib-out-07] (9 pages) - Definition For New BMP Statistics Type [draft-ietf-grow-bmp-bgp-rib-stats-03] (10 pages) - Support for Local RIB in the BGP Monitoring Protocol (BMP) [draft-ietf-grow-bmp-local-rib-13] (14 pages) - BMP Extension for Path Status TLV [draft-ietf-grow-bmp-path-marking-tlv-01] (11 pages) - BMP Peer Up Message Namespace [draft-ietf-grow-bmp-peer-up-04] (8 pages) - Revision to Registration Procedures for Multiple BMP Registries [draft-ietf-grow-bmp-registries-change-04] (3 pages) - Logging of routing events in BGP Monitoring Protocol (BMP) [draft-ietf-grow-bmp-rel-02] (9 pages) - TCP-AO Protection for BGP Monitoring Protocol (BMP) [draft-ietf-grow-bmp-tcp-ao-00] (5 pages) - BMP v4: TLV support for BMP Route Monitoring and Peer Down Messages [draft-ietf-grow-bmp-tlv-14] (12 pages) - Support for Enterprise-specific TLVs in the BGP Monitoring Protocol [draft-ietf-grow-bmp-tlv-ebit-05] (7 pages) - BMP YANG Module [draft-ietf-grow-bmp-yang-04] (72 pages) - BGP Communities for Data Collection [draft-ietf-grow-collection-communities-08] (12 pages) - Distribution of Diverse BGP Paths [draft-ietf-grow-diverse-bgp-path-dist-08] (22 pages) - Embedding Globally-Routable Internet Addresses Considered Harmful [draft-ietf-grow-embed-addr-05] (10 pages) - Impact of BGP Filtering on Inter-Domain Routing Policies [draft-ietf-grow-filtering-threats-08] (16 pages) - Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions [draft-ietf-grow-geomrt-07] (8 pages) - Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration [draft-ietf-grow-irr-routing-policy-considerations-06] (18 pages) - Internet Exchange BGP Route Server Operations [draft-ietf-grow-ix-bgp-route-server-operations-05] (15 pages) - Recommendation to avoid use of BGP Extended Communities at Internet Exchange Route Servers [draft-ietf-grow-ixp-ext-comms-00] (5 pages) - Use of BGP Large Communities [draft-ietf-grow-large-communities-usage-07] (15 pages) - Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format [draft-ietf-grow-mrt-17] (33 pages) - Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Path Extensions [draft-ietf-grow-mrt-add-paths-03] (6 pages) - Time to Remove Filters for Previously Unallocated IPv4 /8s [draft-ietf-grow-no-more-unallocated-slash8s-04] (5 pages) - Near Real Time Mirroring (NRTM) version 4 [draft-ietf-grow-nrtm-v4-04] (22 pages) - Operational Requirements for Enhanced Error Handling Behaviour in BGP-4 [draft-ietf-grow-ops-reqs-for-bgp-error-handling-07] (14 pages) - Issues with Private IP Addressing in the Internet [draft-ietf-grow-private-ip-sp-cores-07] (14 pages) - Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan [draft-ietf-grow-rfc1519bis-04] (27 pages) - Operational Concerns and Considerations for Routing Protocol Design -- Risk, Interference, and Fit (RIFT) [draft-ietf-grow-rift-01] (39 pages) - Methods for Detection and Mitigation of BGP Route Leaks [draft-ietf-grow-route-leak-detection-mitigation-11] (10 pages) - Problem Definition and Classification of BGP Route Leaks [draft-ietf-grow-route-leak-problem-definition-06] (11 pages) - RPKI Autonomous Systems Cones: A Profile To Define Sets of Autonomous Systems Numbers To Facilitate BGP Filtering [draft-ietf-grow-rpki-as-cones-02] (10 pages) - The "import-via" and "export-via" attributes in RPSL Policy Specifications [draft-ietf-grow-rpsl-via-01] (10 pages) - Routing System Stability [draft-ietf-grow-rss-00] (13 pages) - Route-Leaks & MITM Attacks Against BGPSEC [draft-ietf-grow-simple-leak-attack-bgpsec-no-help-04] (8 pages) - Simple Virtual Aggregation (S-VA) [draft-ietf-grow-simple-va-12] (8 pages) - Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services [draft-ietf-grow-unique-origin-as-01] (10 pages) - FIB Suppression with Virtual Aggregation [draft-ietf-grow-va-06] (24 pages) - Auto-Configuration in Virtual Aggregation [draft-ietf-grow-va-auto-05] (6 pages) - GRE and IP-in-IP Tunnels for Virtual Aggregation [draft-ietf-grow-va-gre-00] (7 pages) - MPLS Tunnels for Virtual Aggregation [draft-ietf-grow-va-mpls-00] (5 pages) - Proposal to use an inner MPLS label to identify the remote ASBR VA [draft-ietf-grow-va-mpls-innerlabel-00] (6 pages) - Performance of Virtual Aggregation [draft-ietf-grow-va-perf-00] (16 pages) - Policy Behavior for Well-Known BGP Communities [draft-ietf-grow-wkc-behavior-08] (7 pages) - YANG Module for BGP Communities [draft-ietf-grow-yang-bgp-communities-02] (30 pages) - Logging of routing events in BGP Monitoring Protocol (BMP) [draft-lucente-grow-bmp-rel-03] (8 pages) - Definition For New BMP Statistics Type [draft-msri-grow-bmp-bgp-rib-stats-00] (5 pages) - YANG Module for BGP Communities [draft-pels-grow-yang-bgp-communities-00] (23 pages) - Peering API [draft-ramseyer-grow-peering-api-05] (26 pages) - Revision to Registration Procedures for Multiple BMP Registries [draft-scudder-grow-bmp-registries-change-00] (3 pages) - Usage of Large BGP Communities [draft-snijders-grow-large-communities-usage-00] (10 pages) - The "import-via" and "export-via" attributes in RPSL Policy Specifications [draft-snijders-rpsl-via-03] (9 pages) Requests for Comments: RFC4085: Embedding Globally-Routable Internet Addresses Considered Harmful (10 pages) RFC4264: BGP Wedgies (10 pages) RFC4384: BGP Communities for Data Collection (12 pages) RFC4451: BGP MULTI_EXIT_DISC (MED) Considerations (13 pages) RFC4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan (27 pages) RFC4786: Operation of Anycast Services (24 pages) RFC6198: Requirements for the Graceful Shutdown of BGP Sessions (20 pages) RFC6382: Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services (10 pages) RFC6396: Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format (33 pages) RFC6397: Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions (8 pages) RFC6441: Time to Remove Filters for Previously Unallocated IPv4 /8s (5 pages) RFC6752: Issues with Private IP Addressing in the Internet (14 pages) RFC6769: Simple Virtual Aggregation (S-VA) (8 pages) RFC6774: Distribution of Diverse BGP Paths (22 pages) RFC7682: Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration (18 pages) RFC7789: Impact of BGP Filtering on Inter-Domain Routing Policies (16 pages) RFC7854: BGP Monitoring Protocol (BMP) (27 pages) * Updates RFC8671 * Updates RFC9069 * Updates RFC9515 RFC7908: Problem Definition and Classification of BGP Route Leaks (11 pages) RFC7948: Internet Exchange BGP Route Server Operations (15 pages) RFC7999: BLACKHOLE Community (9 pages) RFC8050: Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Path Extensions (6 pages) RFC8195: Use of BGP Large Communities (15 pages) RFC8212: Default External BGP (EBGP) Route Propagation Behavior without Policies (7 pages) RFC8326: Graceful BGP Session Shutdown (12 pages) RFC8327: Mitigating the Negative Impact of Maintenance through BGP Session Culling (10 pages) RFC8642: Policy Behavior for Well-Known BGP Communities (7 pages) RFC8671: Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP) (9 pages) RFC9069: Support for Local RIB in the BGP Monitoring Protocol (BMP) (14 pages) RFC9515: Revision to Registration Procedures for Multiple BMP Registries (3 pages) IOT Operations (iotops) ----------------------- Charter Last Modified: 2022-05-06 Current Status: Active Chairs: Alexey Melnikov Henk Birkholz Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari Operations and Management Area Advisor: Warren Kumari Editor: Warren Kumari Mailing Lists: General Discussion: iotops@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/iotops Archive: https://mailarchive.ietf.org/arch/browse/iotops/ Description of Working Group: The IOTOPS Working Group is chartered for the discussion of operational issues related to Internet of Things (IoT) devices, in particular related to device onboarding and lifecycle management. IoT has a rather nebulous definition with different meanings for different people. For the purposes of this WG, its focus is on devices that - are networked, either to the Internet or within limited administrative domains - have a very limited end user interface or no end-user interface at all - are deployed in sufficiently large numbers that they cannot easily be managed or maintained manually The IETF works on a number of technologies related to IoT. This includes, but is not limited to work done in ACE, ANIMA, CBOR, CORE, DRIP, LAKE, LPWAN, LWIG, ROLL, SUIT, TEEP, 6LO, 6TISCH, and other working groups. IOTOPS is intended to be a discussion venue where people can discuss how various IoT-related technologies fit together. IOTOPS provides a venue for IoT experts and other interested parties to engage in discussions of operational IoT requirements, as well as proposals for new uses of IP technology related to IoT devices and network operations. Revision, updates, and extensions to work from existing WGs will be done in those WGs. Where new work may be needed, IOTOPS will help identify candidate venues within IETF for their development. IOTOPS WG charter is restricted to: 1) Taking input and discussing issues related to the operational management of IoT devices. This includes (but is not limited to): - factory provisioning of devices - onboarding of devices - access control of devices to network resources - administrative control of devices - software/firmware upgrades - isolation/quarantine of devices - remediation of broken devices - end of life management of devices 2) Taking input and discussing issues related to IoT operational security. 3) Publishing operational practices. 4) Documenting requirements. Approximately one year after chartering, the WG chairs will prepare a report for the IESG summarizing what the group has accomplished; this is both as a checkpoint for this working group and as a demonstration to the IESG that this style of working groups such as this have value and should be considered more often. Goals and Milestones: Internet-Drafts: - Terminology for Constrained-Node Networks [draft-bormann-iotops-ietf-lwig-7228bis-00] (28 pages) - Terminology for Constrained-Node Networks [draft-ietf-iotops-7228bis-00] (28 pages) - Comparison of CoAP Security Protocols [draft-ietf-iotops-security-protocol-comparison-06] (54 pages) - A summary of security-enabling technologies for IoT devices [draft-ietf-iotops-security-summary-02] (27 pages) - A summary of security-enabling technologies for IoT devices [draft-moran-iot-nets-03] (19 pages) No Requests for Comments IP Performance Measurement (ippm) --------------------------------- Charter Last Modified: 2024-06-24 Current Status: Active Chairs: Marcus Ihlar Tommy Pauly Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari Operations and Management Area Advisor: Warren Kumari Mailing Lists: General Discussion: ippm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ippm Archive: https://mailarchive.ietf.org/arch/browse/ippm/ Description of Working Group: The IP Performance Measurement (IPPM) Working Group develops and maintains standard metrics that can be applied to the quality, performance, and reliability of Internet data delivery services and applications running over transport layer protocols (e.g. TCP, UDP) over IP. It also develops and maintains methodologies and protocols for the measurement of these metrics. These metrics, protocols, and methodologies are designed such that they can be used by network operators, end users, or independent testing groups. Metrics developed by the IPPM WG are intended to provide unbiased quantitative performance measurements. The IPPM WG works to foster commonality and comparability of metrics and measurements across IETF protocols at different layers. Its work is limited to metrics and methodologies which are applicable over transport-layer protocols over IP, and does not specify encapsulations required for measurements over non-IP layers. The IPPM WG has produced documents that define specific metrics and procedures for accurately measuring and documenting these metrics. The working group will continue advancing the most useful of these metrics along the standards track, using the guidelines stated in RFC 6576. To the extent possible, these metrics will be used as the basis for future work on metrics in the WG. The WG will seek to develop new metrics and models to accurately characterize the network paths under test and/or the performance of transport and application layer protocols on these paths. The WG will balance the need for new metrics with the desire to minimize the introduction of new metrics, and will require that new metric definitions state how the definition improves on an existing metric definition, or assesses a property of network performance not previously covered by a defined metric. Metric definitions will follow the template given in RFC 6390. Additional methods will be defined for the composition and calibration of IPPM-defined metrics, as well as active, passive and hybrid measurement methods for these metrics. In addition, the WG encourages work which describes the applicability of metrics and measurement methods, especially to improve understanding of the tradeoffs involved among active, passive, and hybrid methods. The WG may update its core framework RFC 2330 as necessary to accommodate these activities. The WG has produced protocols for communication among test equipment to enable the measurement of the one- and two-way metrics (OWAMP and TWAMP respectively). These protocols will be advanced along the standards track. The work of the WG will take into account the suitability of measurements for automation, in order to support large-scale measurement efforts. This may result in further developments in protocols such as OWAMP and TWAMP. Agreement about the definitions of metrics and methods of measurement enables accurate, reproducible, and equivalent results across different implementations. To this end, the WG defines and maintains a registry of metric definitions. The WG encourages work which assesses the comparability of measurements of IPPM metrics with metrics developed elsewhere. The WG also encourages work which improves the availability of information about the context in which measurements were taken, for example (but not limited to) measurement implementation information, estimates of confidence in these measurements, conditions on the network(s) on which measurements are taken, and/or information about the data-plane topology of these network(s). In the interest of measurement comparability, the WG may define data formats and information models for the storage and exchange of the results of measurements defined within IPPM. The IPPM WG seeks cooperation with other appropriate standards bodies and forums to promote consistent approaches and metrics. Within the IETF process, IPPM metric definitions and measurement protocols will be subject to as rigorous a scrutiny for usefulness, clarity, and accuracy as other protocol standards. The IPPM WG will interact with other areas of IETF activity whose scope intersects with the requirement of these specific metrics. The WG will, on request, provide input to other IETF working groups on the use and implementation of these metrics. Goals and Milestones: Done - submit a Standards Track document to the IESG for a YANG model for managing TWAMP clients and servers Done - Submit an Experimental draft on coloring-based hybrid measurement methodologies for loss and delay to the IESG Done - Submit a Standards Track draft defining well-known ports for OWAMP and TWAMP to the IESG Done - submit a Standards Track document to the IESG defining initial contents of performance metric registry Done - submit a Standards Track document to the IESG updating RFC2330 to cover IPv6 Done - Submit a Standards Track drafts defining a simple two-way active measurement protocol based on TWAMP-Test, and a YANG data model to control it, to the IESG Done - Submit draft on core registry for performance metrics to IESG as Proposed Standard Done - submit a Standards Track draft on inband OAM based measurement methodologies to the IESG Done - Submit a Standards Track draft defining a metric for unidirectional route assessment to the IESG Done - Submit a Standards Track document on Direct Export for IOAM Done - Submit a Standards Track document on Metrics and Methods for IP Capacity Measurement Internet-Drafts: - Integrity of In-situ OAM Data Fields [draft-brockners-ippm-ioam-data-integrity-03] (16 pages) - In-situ OAM Deployment [draft-brockners-opsawg-ioam-deployment-03] (23 pages) - Two-Way Active Measurement Protocol (TWAMP) Data Model [draft-cmzrjp-ippm-twamp-yang-02] (56 pages) - IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option [draft-elkins-ippm-encrypted-pdmv2-02] (17 pages) - Multipoint Alternate Marking method for passive and hybrid performance monitoring [draft-fioccola-ippm-multipoint-alt-mark-04] (20 pages) - Alternate-Marking Method [draft-fioccola-rfc8321bis-04] (27 pages) - Multipoint Alternate-Marking Method [draft-fioccola-rfc8889bis-04] (27 pages) - Alternate Marking Deployment Framework [draft-fz-ippm-alt-mark-deployment-01] (17 pages) - Simple TWAMP (STAMP) Extensions for Segment Routing Networks [draft-gandhi-ippm-stamp-srpm-03] (12 pages) - TWAMP Light Extensions for Segment Routing Networks [draft-gandhi-ippm-twamp-srpm-00] (13 pages) - A Connectivity Monitoring Metric for IPPM [draft-geib-ippm-connectivity-monitoring-03] (13 pages) - Differentiated Service Code Point and Explicit Congestion Notification Monitoring in Two-Way Active Measurement Protocol (TWAMP) [draft-hedin-ippm-type-p-monitor-04] (10 pages) - IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework [draft-ietf-ippm-2330-ipv6-06] (15 pages) - Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM) [draft-ietf-ippm-2330-update-05] (17 pages) - A One-Way Delay Metric for IP Performance Metrics (IPPM) [draft-ietf-ippm-2679-bis-05] (27 pages) - A One-Way Loss Metric for IP Performance Metrics (IPPM) [draft-ietf-ippm-2680-bis-05] (22 pages) - IPv6 Performance and Diagnostic Metrics (PDM) Destination Option [draft-ietf-ippm-6man-pdm-option-13] (30 pages) - Active and Passive Metrics and Methods (with Hybrid Types In-Between) [draft-ietf-ippm-active-passive-06] (14 pages) - Alternate-Marking Method for Passive and Hybrid Performance Monitoring [draft-ietf-ippm-alt-mark-14] (33 pages) - Alternate Marking Deployment Framework [draft-ietf-ippm-alt-mark-deployment-01] (17 pages) - Performance Measurement with Asymmetrical Packets in STAMP [draft-ietf-ippm-asymmetrical-pkts-01] (11 pages) - A Framework for Defining Empirical Bulk Transfer Capacity Metrics [draft-ietf-ippm-btc-framework-05] (16 pages) - Defining Network Capacity [draft-ietf-ippm-bw-capacity-05] (14 pages) - Metrics and Methods for One-Way IP Capacity [draft-ietf-ippm-capacity-metric-method-12] (33 pages) - Test Protocol for One-way IP Capacity Measurement [draft-ietf-ippm-capacity-protocol-07] (56 pages) - UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) [draft-ietf-ippm-checksum-trailer-06] (15 pages) - IPPM Metrics for Measuring Connectivity [draft-ietf-ippm-connectivity-04] (10 pages) - A Connectivity Monitoring Metric for IPPM [draft-ietf-ippm-connectivity-monitoring-09] (29 pages) - A One-way Delay Metric for IPPM [draft-ietf-ippm-delay-07] (20 pages) - Packet Delay Variation Applicability Statement [draft-ietf-ippm-delay-var-as-02] (39 pages) - A One-Way Packet Duplication Metric [draft-ietf-ippm-duplicate-08] (14 pages) - IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option [draft-ietf-ippm-encrypted-pdmv2-08] (21 pages) - Explicit Host-to-Network Flow Measurements Techniques [draft-ietf-ippm-explicit-flow-measurements-07] (37 pages) - Framework for IP Performance Metrics [draft-ietf-ippm-framework-02] (40 pages) - Framework for Metric Composition [draft-ietf-ippm-framework-compagg-09] (18 pages) - Hybrid Two-Step Performance Measurement Method [draft-ietf-ippm-hybrid-two-step-02] (20 pages) - Overview of Implementation reports relating to IETF work on IP Performance Measurements (IPPM, RFC 2678 - 2681) [draft-ietf-ippm-implement-02] (24 pages) - Initial Performance Metrics Registry Entries [draft-ietf-ippm-initial-registry-16] (71 pages) - Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities [draft-ietf-ippm-ioam-conf-state-10] (17 pages) - Data Fields for In Situ Operations, Administration, and Maintenance (IOAM) [draft-ietf-ippm-ioam-data-17] (40 pages) - Integrity Protection of In Situ Operations, Administration, and Maintenance (IOAM) Data Fields [draft-ietf-ippm-ioam-data-integrity-12] (22 pages) - In Situ Operations, Administration, and Maintenance (IOAM) Deployment [draft-ietf-ippm-ioam-deployment-05] (20 pages) - In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting [draft-ietf-ippm-ioam-direct-export-11] (13 pages) - In Situ Operations, Administration, and Maintenance (IOAM) Loopback and Active Flags [draft-ietf-ippm-ioam-flags-10] (13 pages) - IPv6 Options for In Situ Operations, Administration, and Maintenance (IOAM) [draft-ietf-ippm-ioam-ipv6-options-12] (10 pages) - A YANG Data Model for In-Situ OAM [draft-ietf-ippm-ioam-yang-13] (31 pages) - IP Packet Delay Variation Metric for IP Performance Metrics (IPPM) [draft-ietf-ippm-ipdv-09] (21 pages) - IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) [draft-ietf-ippm-ipsec-11] (15 pages) - A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance [draft-ietf-ippm-lmap-path-07] (17 pages) - A One-way Packet Loss Metric for IPPM [draft-ietf-ippm-loss-07] (15 pages) - Loss Episode Metrics for IP Performance Metrics (IPPM) [draft-ietf-ippm-loss-episode-metrics-04] (21 pages) - One-way Loss Pattern Sample Metrics [draft-ietf-ippm-loss-pattern-06] (15 pages) - Registry for Performance Metrics [draft-ietf-ippm-metric-registry-24] (35 pages) - IP Performance Metrics (IPPM) Metrics Registry [draft-ietf-ippm-metrics-registry-08] (14 pages) - IP Performance Metrics (IPPM) Standard Advancement Testing [draft-ietf-ippm-metrictest-05] (37 pages) - Model-Based Metrics for Bulk Transport Capacity [draft-ietf-ippm-model-based-metrics-13] (55 pages) - Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP) [draft-ietf-ippm-more-twamp-02] (8 pages) - IP Performance Metrics (IPPM): Spatial and Multicast [draft-ietf-ippm-multimetrics-12] (57 pages) - Multipoint Alternate-Marking Method for Passive and Hybrid Performance Monitoring [draft-ietf-ippm-multipoint-alt-mark-09] (23 pages) - Network performance measurement with periodic streams [draft-ietf-ippm-npmps-07] (23 pages) - One-way/Two-way Active Measurement Protocol Extensions for Performance Measurement on LAG [draft-ietf-ippm-otwamp-on-lag-08] (14 pages) - Registries for the One-Way Active Measurement Protocol (OWAMP) [draft-ietf-ippm-owamp-registry-03] (7 pages) - A One-way Active Measurement Protocol (OWAMP) [draft-ietf-ippm-owdp-16] (56 pages) - One-way Active Measurement Protocol (OWAMP) Requirements [draft-ietf-ippm-owdp-reqs-06] (11 pages) - Precision Availability Metrics for Services Governed by Service Level Objectives (SLOs) [draft-ietf-ippm-pam-09] (14 pages) - Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) [draft-ietf-ippm-port-twamp-test-04] (11 pages) - Quality of Outcome [draft-ietf-ippm-qoo-00] (27 pages) - Rate Measurement Test Protocol Problem Statement and Requirements [draft-ietf-ippm-rate-problem-10] (14 pages) - Active Performance Metric Sub-Registry [draft-ietf-ippm-registry-active-01] (27 pages) - Passive Performance Metrics Sub-Registry [draft-ietf-ippm-registry-passive-01] (23 pages) - Packet Reordering Metrics [draft-ietf-ippm-reordering-13] (45 pages) - Reporting IP Performance Metrics to Users [draft-ietf-ippm-reporting-06] (42 pages) - Reporting IP Network Performance Metrics: Different Points of View [draft-ietf-ippm-reporting-metrics-09] (27 pages) - IP Performance Metrics (IPPM) reporting Information Base (MIB) [draft-ietf-ippm-reporting-mib-06] (80 pages) - Responsiveness under Working Conditions [draft-ietf-ippm-responsiveness-04] (26 pages) - Alternate-Marking Method [draft-ietf-ippm-rfc8321bis-03] (22 pages) - Clustered Alternate-Marking Method [draft-ietf-ippm-rfc8889bis-04] (24 pages) - Advanced Unidirectional Route Assessment (AURA) [draft-ietf-ippm-route-10] (23 pages) - A Round-trip Delay Metric for IPPM [draft-ietf-ippm-rt-delay-01] (20 pages) - Round-Trip Packet Loss Metrics [draft-ietf-ippm-rt-loss-05] (14 pages) - Spatial Composition of Metrics [draft-ietf-ippm-spatial-composition-16] (29 pages) - Simple Two-Way Active Measurement Protocol [draft-ietf-ippm-stamp-10] (15 pages) - Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet Extension Headers [draft-ietf-ippm-stamp-ext-hdr-00] (15 pages) - Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on LAG [draft-ietf-ippm-stamp-on-lag-06] (9 pages) - Simple Two-Way Active Measurement Protocol Optional Extensions [draft-ietf-ippm-stamp-option-tlv-10] (29 pages) - Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Segment Routing Networks [draft-ietf-ippm-stamp-srpm-18] (16 pages) - Simple Two-way Active Measurement Protocol (STAMP) Data Model [draft-ietf-ippm-stamp-yang-12] (44 pages) - Information Model and XML Data Model for Traceroute Measurements [draft-ietf-ippm-storetraceroutes-12] (75 pages) - Framework for TCP Throughput Testing [draft-ietf-ippm-tcp-throughput-tm-13] (27 pages) - Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track [draft-ietf-ippm-testplan-rfc2679-03] (29 pages) - Test Plan and Results for Advancing RFC 2680 on the Standards Track [draft-ietf-ippm-testplan-rfc2680-05] (31 pages) - A Two-Way Active Measurement Protocol (TWAMP) [draft-ietf-ippm-twamp-09] (26 pages) - Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features [draft-ietf-ippm-twamp-reflect-octets-09] (18 pages) - Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP) [draft-ietf-ippm-twamp-session-cntrl-07] (17 pages) - Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP) [draft-ietf-ippm-twamp-time-format-06] (8 pages) - Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets [draft-ietf-ippm-twamp-value-added-octets-09] (15 pages) - Two-Way Active Measurement Protocol (TWAMP) YANG Data Model [draft-ietf-ippm-twamp-yang-13] (60 pages) - Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP) [draft-ietf-ippm-type-p-monitor-03] (11 pages) - In-situ OAM IPv6 Options [draft-ioametal-ippm-6man-ioam-ipv6-options-02] (9 pages) - In-situ OAM Direct Exporting [draft-ioamteam-ippm-ioam-direct-export-00] (11 pages) - Explicit Flow Measurements Techniques [draft-mdt-ippm-explicit-flow-measurements-02] (40 pages) - Precision Availability Metrics for SLO-Governed End-to-End Services [draft-mhmcsfh-ippm-pam-03] (13 pages) - Performance Measurement with Asymmetrical Packets in STAMP [draft-mirsky-ippm-asymmetrical-pkts-04] (11 pages) - Hybrid Two-Step Performance Measurement Method [draft-mirsky-ippm-hybrid-two-step-15] (19 pages) - Simple Two-way Active Measurement Protocol Optional Extensions [draft-mirsky-ippm-stamp-option-tlv-05] (16 pages) - UDP Checksum Trailer in OWAMP and TWAMP [draft-mizrahi-ippm-checksum-trailer-02] (11 pages) - In-situ OAM Flags [draft-mizrahi-ippm-ioam-flags-00] (10 pages) - A One-Way Delay Metric for IPPM [draft-morton-ippm-2679-bis-06] (24 pages) - A One-Way Loss Metric for IPPM [draft-morton-ippm-2680-bis-04] (20 pages) - Metrics and Methods for IP Capacity [draft-morton-ippm-capacity-metric-method-01] (20 pages) - Test Protocol for One-way IP Capacity Measurement [draft-morton-ippm-capacity-metric-protocol-02] (30 pages) - Initial Performance Metric Registry Entries [draft-morton-ippm-initial-registry-04] (62 pages) - RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete [draft-morton-ippm-rfc4148-obsolete-03] (6 pages) - Quality of Outcome [draft-olden-ippm-qoo-02] (16 pages) - Echo Request/Reply for Enabled In-situ OAM Capabilities [draft-xiao-ippm-ioam-conf-state-10] (18 pages) - A YANG Data Model for In-Situ OAM [draft-zhou-ippm-ioam-yang-08] (25 pages) Requests for Comments: RFC2330: Framework for IP Performance Metrics (40 pages) * Updates RFC7312 * Updates RFC8468 * Updates RFC9198 RFC2498: IPPM Metrics for Measuring Connectivity (10 pages) * Obsoletes RFC2678 RFC2679: A One-way Delay Metric for IPPM (20 pages) * Obsoletes RFC7679 RFC2680: A One-way Packet Loss Metric for IPPM (15 pages) * Obsoletes RFC7680 RFC2681: A Round-trip Delay Metric for IPPM (20 pages) RFC3148: A Framework for Defining Empirical Bulk Transfer Capacity Metrics (16 pages) RFC3357: One-way Loss Pattern Sample Metrics (15 pages) RFC3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM) (21 pages) RFC3432: Network performance measurement with periodic streams (23 pages) RFC3763: One-way Active Measurement Protocol (OWAMP) Requirements (11 pages) RFC4148: IP Performance Metrics (IPPM) Metrics Registry (14 pages) * Obsoletes RFC6248 RFC4656: A One-way Active Measurement Protocol (OWAMP) (56 pages) * Updates RFC7717 * Updates RFC7718 * Updates RFC8545 RFC4737: Packet Reordering Metrics (45 pages) * Updates RFC6248 RFC5136: Defining Network Capacity (14 pages) RFC5357: A Two-Way Active Measurement Protocol (TWAMP) (26 pages) * Updates RFC5618 * Updates RFC5938 * Updates RFC6038 * Updates RFC7717 * Updates RFC7750 * Updates RFC8545 RFC5388: Information Model and XML Data Model for Traceroute Measurements (75 pages) RFC5481: Packet Delay Variation Applicability Statement (39 pages) RFC5560: A One-Way Packet Duplication Metric (14 pages) * Updates RFC6248 RFC5618: Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP) (8 pages) RFC5644: IP Performance Metrics (IPPM): Spatial and Multicast (57 pages) * Updates RFC6248 RFC5835: Framework for Metric Composition (18 pages) RFC5938: Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP) (17 pages) RFC6038: Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features (18 pages) RFC6049: Spatial Composition of Metrics (29 pages) * Updates RFC6248 RFC6248: RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete (6 pages) RFC6349: Framework for TCP Throughput Testing (27 pages) RFC6534: Loss Episode Metrics for IP Performance Metrics (IPPM) (21 pages) RFC6576: IP Performance Metrics (IPPM) Standard Advancement Testing (37 pages) RFC6673: Round-Trip Packet Loss Metrics (14 pages) RFC6703: Reporting IP Network Performance Metrics: Different Points of View (27 pages) RFC6802: Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets (15 pages) RFC6808: Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track (29 pages) RFC7290: Test Plan and Results for Advancing RFC 2680 on the Standards Track (31 pages) RFC7312: Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM) (17 pages) RFC7398: A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance (17 pages) RFC7497: Rate Measurement Test Protocol Problem Statement and Requirements (14 pages) RFC7679: A One-Way Delay Metric for IP Performance Metrics (IPPM) (27 pages) RFC7680: A One-Way Loss Metric for IP Performance Metrics (IPPM) (22 pages) RFC7717: IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) (15 pages) RFC7718: Registries for the One-Way Active Measurement Protocol (OWAMP) (7 pages) RFC7750: Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP) (11 pages) RFC7799: Active and Passive Metrics and Methods (with Hybrid Types In-Between) (14 pages) RFC7820: UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) (15 pages) RFC8186: Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP) (8 pages) RFC8250: IPv6 Performance and Diagnostic Metrics (PDM) Destination Option (30 pages) RFC8321: Alternate-Marking Method for Passive and Hybrid Performance Monitoring (33 pages) * Obsoletes RFC9341 RFC8337: Model-Based Metrics for Bulk Transport Capacity (55 pages) RFC8468: IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework (15 pages) RFC8545: Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) (11 pages) RFC8762: Simple Two-Way Active Measurement Protocol (15 pages) * Updates RFC8972 RFC8889: Multipoint Alternate-Marking Method for Passive and Hybrid Performance Monitoring (23 pages) * Obsoletes RFC9342 RFC8911: Registry for Performance Metrics (35 pages) RFC8912: Initial Performance Metrics Registry Entries (71 pages) RFC8913: Two-Way Active Measurement Protocol (TWAMP) YANG Data Model (60 pages) RFC8972: Simple Two-Way Active Measurement Protocol Optional Extensions (29 pages) RFC9097: Metrics and Methods for One-Way IP Capacity (33 pages) RFC9197: Data Fields for In Situ Operations, Administration, and Maintenance (IOAM) (40 pages) RFC9198: Advanced Unidirectional Route Assessment (AURA) (23 pages) RFC9322: In Situ Operations, Administration, and Maintenance (IOAM) Loopback and Active Flags (13 pages) RFC9326: In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting (13 pages) RFC9341: Alternate-Marking Method (22 pages) RFC9342: Clustered Alternate-Marking Method (24 pages) RFC9359: Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities (17 pages) RFC9378: In Situ Operations, Administration, and Maintenance (IOAM) Deployment (20 pages) RFC9486: IPv6 Options for In Situ Operations, Administration, and Maintenance (IOAM) (10 pages) RFC9503: Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Segment Routing Networks (16 pages) RFC9506: Explicit Host-to-Network Flow Measurements Techniques (37 pages) RFC9533: One-Way and Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group (13 pages) RFC9534: Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group (8 pages) RFC9544: Precision Availability Metrics (PAMs) for Services Governed by Service Level Objectives (SLOs) (12 pages) RFC9617: A YANG Data Model for In Situ Operations, Administration, and Maintenance (IOAM) (28 pages) Network Inventory YANG (ivy) ---------------------------- Charter Last Modified: 2024-07-23 Current Status: Active Chairs: Daniele Ceccarelli Qiufang Ma Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari Operations and Management Area Advisor: Mahesh Jethanandani Editors: Adrian Farrel Daniele Ceccarelli Robert Wilton Mailing Lists: General Discussion: inventory-yang@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/inventory-yang Archive: https://mailarchive.ietf.org/arch/browse/inventory-yang/ Description of Working Group: Network inventory is a foundation for network management in all types of networks: Network operators need to keep a record of what equipment is planned and installed in their networks (including a variety of information such as product name, vendor, product series, embedded software, and hardware/software versions). Network inventories may be constructed from management system data to represent the expected devices present in the network, and also be used to audit and catalog what devices are discovered in the network, and to expose that information in a consistent way. The purpose of the IVY WG is to provide a venue for discussion of inventory YANG models from across IETF Areas under a common umbrella to facilitate distribution of the work, clarify the scope of each model, and minimize overlap between them. The Working Group may also dispatch some inventory work towards Working Groups in the Operations and Management Area as well as other Areas, if appropriate. An objective of this effort is to derive common building-blocks for inventory modeling that can be augmented, imported, or reused by other IETF models. The WG will also identify a set of requirements and guidelines to ensure consistency across models related to inventory. The scope of the work extends to the inventory of network elements, with a primary focus on those that operate at layers 0-3, and includes both hardware and software inventory. Mapping the inventory models that will be produced by the WG into existing IETF models (e.g., ietf-network-topology) is also in scope. The Working Group will consider existing IETF work, including RFC 8348 and RFC 8345. Work specifying the use of inventory content is outside the scope of the Working Group, but informative examples describing how the inventory data may be used is within scope. The IVY WG will initially focus on developing a core network inventory model that can be used as a foundation by other models to establish inventory models that are specific to different hardware technologies. The following activities will be used to help achieve this goal. It is expected that many of these items will not lead to the publication of RFCs, although Internet-Drafts may be used to track discussions and establish consensus: A. Terminology and Scope: Definition of the scope of inventory as well as a common architecture and terminology. An effort will be made to keep terminology aligned with, or mapped to, industry-wide activities including initiatives in the IEEE, ITU-T, TMF, MEF, Openconfig, ONF, and 3GPP. B. Hardware/Software components including licenses: Hardware and Software component management to allow network operators to keep track of which physical/virtual devices are deployed in the network, including software and hardware versions as well as licenses/entitlement. C. Physical locations: Indicate the physical position of the network elements (such as, site, room, rack, shelf, slot) to provide precise location information. D. Multi-domain and multi-layer: Consistent representation and reporting of network inventory to maintain a centralized view of all network element component types across multiple network segments and layers of the underlying network under the same management and ownership. E. Mapping and correlation semantics: Correlating the inventory with existing IETF models e.g., topology, service attachment points (SAP), etc. F. Security and privacy issues: The information in a network inventory is highly sensitive as it potentially exposes critical information about the internal topology, characterization of the components that are used to build that topology, and precise device location information that could indirectly identify user locations. Standard protocol mechanisms, e.g., the use of NACM [RFC 8341], are expected to be used to prevent unauthorized access. However, the Working Group must consider whether additional security mechanisms (such as specific operational guidance, or data minimization of precise location data) are needed to protect this information from unauthorized access, manipulation, or the indirect exposition of private user identifying data. Goals and Milestones: Oct 2023 - Adopt an Internet-Draft describing a core network inventory YANG data model that can be used as a foundation by other YANG models to establish technology-specific inventory models. Jul 2024 - Request publication of the below YANG data model. Internet-Drafts: - A Network Inventory Topology Model [draft-ietf-ivy-network-inventory-topology-00] (18 pages) - A YANG Data Model for Network Inventory [draft-ietf-ivy-network-inventory-yang-03] (33 pages) - A YANG Data Model for Network Inventory Location [draft-wbbpb-ivy-network-inventory-location-02] (18 pages) - A YANG Data Model for Network Inventory [draft-y3bp-ivy-network-inventory-yang-00] (30 pages) No Requests for Comments MBONE Deployment (mboned) ------------------------- Charter Last Modified: 2023-03-24 Current Status: Active Chairs: Greg Shepherd Lenny Giuliano Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari Operations and Management Area Advisor: Warren Kumari Tech Advisor: Scott Bradner Mailing Lists: General Discussion: mboned@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mboned Archive: https://mailarchive.ietf.org/arch/browse/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, inter-domain and single domain. This activity will include, but not be limited to: - Document 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. - Analyze the need for IPv4 - IPv6 multicast transition solutions - Develop tools, extend protocols and provide operational and implementation advice that assists in multicast administration, diagnostics, troubleshooting and deployment between/within native and non-native environments. - Development of routing and group membership protocols is out of scope. This working group may develop requirements and assist in review and feedback of documents in other working groups responsible for such protocols. Goals and Milestones: Jan 2014 - Submit Mtracev2 to IESG for Proposed Standards Mar 2014 - Work with TSV area to submit multicast transport guidelines for congestion control Mar 2014 - Submit Overview of Multicast in the Data Center to IESG for Informational Internet-Drafts: - IPv6 Multicast Address With Embedded IPv4 Multicast Address [draft-ietf-mboned-64-multicast-address-format-06] (12 pages) - Overview of the Internet Multicast Addressing Architecture [draft-ietf-mboned-addrarch-07] (14 pages) - Lightweight Multicast Address Discovery Problem Space [draft-ietf-mboned-addrdisc-problems-02] (11 pages) - Administratively Scoped IP Multicast [draft-ietf-mboned-admin-ip-space-05] (8 pages) - Asymmetric Manifest Based Integrity [draft-ietf-mboned-ambi-03] (29 pages) - YANG Data Model for Automatic Multicast Tunneling [draft-ietf-mboned-amt-yang-02] (22 pages) - Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP) [draft-ietf-mboned-anycast-rp-08] (7 pages) - Automatic Multicast Tunneling [draft-ietf-mboned-auto-multicast-18] (82 pages) - Circuit Breaker Assisted Congestion Control [draft-ietf-mboned-cbacc-04] (20 pages) - Multicast in the Data Center Overview [draft-ietf-mboned-dc-deploy-09] (18 pages) - Deprecating Any-Source Multicast (ASM) for Interdomain Multicast [draft-ietf-mboned-deprecate-interdomain-asm-07] (14 pages) - Discovery Of Restconf Metadata for Source-specific multicast [draft-ietf-mboned-dorms-04] (26 pages) - DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery [draft-ietf-mboned-driad-amt-discovery-13] (33 pages) - Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address [draft-ietf-mboned-embeddedrp-07] (18 pages) - Multicast Geo-Distribution Control [draft-ietf-mboned-geo-distribution-control-00] (8 pages) - GLOP Addressing in 233/8 [draft-ietf-mboned-glop-addressing-02] (5 pages) - Extended Assignments in 233/8 [draft-ietf-mboned-glop-extensions-02] (4 pages) - GLOP Addressing in 233/8 [draft-ietf-mboned-glop-update-01] (5 pages) - IANA Guidelines for IPv4 Multicast Address Assignments [draft-ietf-mboned-iana-ipv4-mcast-guidelines-04] (8 pages) - Multicast Considerations over IEEE 802 Wireless Media [draft-ietf-mboned-ieee802-mcast-problems-15] (22 pages) - Internet Multicast Gap Analysis from the MBONED Working Group for the IESG [draft-ietf-mboned-iesg-gap-analysis-00] (14 pages) - Some Issues for an Inter-domain Multicast Routing Protocol [draft-ietf-mboned-imrp-some-issues-03] (12 pages) - Use of Multicast across Inter-domain Peering Points [draft-ietf-mboned-interdomain-peering-bcp-14] (44 pages) - Introduction to IP Multicast Routing [draft-ietf-mboned-intro-multicast-03] (60 pages) - IP Multicast MIB [draft-ietf-mboned-ip-mcast-mib-07] (59 pages) - Requirements for IP multicast performance monitoring [draft-ietf-mboned-ip-multicast-pm-requirement-01] (15 pages) - IPv4 Multicast Best Current Practice [draft-ietf-mboned-ipv4-mcast-bcp-01] (12 pages) - IPv4 Multicast Unusable Group And Source Addresses [draft-ietf-mboned-ipv4-mcast-unusable-01] (7 pages) - Unicast-Prefix-Based IPv4 Multicast Addresses [draft-ietf-mboned-ipv4-uni-based-mcast-06] (5 pages) - IPv6 Multicast Deployment Issues [draft-ietf-mboned-ipv6-multicast-issues-02] (12 pages) - Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols [draft-ietf-mboned-lightweight-igmpv3-mldv2-06] (17 pages) - Guidelines for Rate Limits on the MBONE [draft-ietf-mboned-limit-rate-guide-00] (3 pages) - Using MSDP to create Logical RPs [draft-ietf-mboned-logical-rp-00] (7 pages) - Requirements for Multicast AAA coordinated between Content Provider(s) and Network Service Provider(s) [draft-ietf-mboned-maccnt-req-10] (18 pages) - Multicast Addresses for Documentation [draft-ietf-mboned-mcaddrdoc-04] (7 pages) - IP Multicast Applications: Challenges and Solutions [draft-ietf-mboned-mcast-apps-02] (28 pages) - Moving MCAST.NET into the ARPA infrastructure top level domain [draft-ietf-mboned-mcast-arpa-03] (9 pages) - Connecting Multicast Domains [draft-ietf-mboned-mcast-connect-00] (14 pages) - IP Multicast and Firewalls [draft-ietf-mboned-mcast-firewall-02] (12 pages) - Multicast Debugging Handbook [draft-ietf-mboned-mdh-05] (34 pages) - Multicast-Friendly Internet Exchange (MIX) [draft-ietf-mboned-mix-01] (10 pages) - Multicast Network Address Translation [draft-ietf-mboned-mnat-01] (23 pages) - Multicast Reachability Monitor (MRM) [draft-ietf-mboned-mrm-01] (22 pages) - Justification for and use of the Multicast Routing Monitor (MRM) Protocol [draft-ietf-mboned-mrm-use-00] (9 pages) - Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements [draft-ietf-mboned-mroutesec-04] (23 pages) - Multicast Source Discovery Protocol (MSDP) Deployment Scenarios [draft-ietf-mboned-msdp-deploy-06] (14 pages) - Multicast Source Discovery Protocol (MSDP) MIB [draft-ietf-mboned-msdp-mib-01] (32 pages) - Mtrace Version 2: Traceroute Facility for IP Multicast [draft-ietf-mboned-mtrace-v2-26] (41 pages) - AAA and Admission Control Framework for Multicasting [draft-ietf-mboned-multiaaa-framework-12] (22 pages) - Multicast On-path Telemetry using IOAM [draft-ietf-mboned-multicast-telemetry-12] (13 pages) - Multicast YANG Data Model [draft-ietf-mboned-multicast-yang-model-11] (42 pages) - Address Acquisition For Multicast Content When Source and Receiver Support Differing IP Versions [draft-ietf-mboned-multrans-addr-acquisition-07] (10 pages) - Multicast-Scope Zone Announcement Protocol (MZAP) [draft-ietf-mboned-mzap-06] (27 pages) - Administratively Scoped IP Multicast [draft-ietf-mboned-oops-disregard-00] (6 pages) - PIM Multicast Border Router (PMBR) specification for connecting PIM-SM domains to a DVMRP Backbone [draft-ietf-mboned-pmbr-spec-00] (8 pages) - Multicast pruning a necessity [draft-ietf-mboned-pruning-02] (3 pages) - Issues Related to Receiver Access Control in the Current Multicast Protocols [draft-ietf-mboned-rac-issues-03] (24 pages) - Multicast Redundant Ingress Router Failover [draft-ietf-mboned-redundant-ingress-failover-05] (14 pages) - IANA Guidelines for IPv4 Multicast Address Assignments [draft-ietf-mboned-rfc3171bis-08] (11 pages) - IANA Guidelines for IPv4 Multicast Address Assignments [draft-ietf-mboned-rfc3171-update-00] (9 pages) - Overview of the Internet Multicast Routing Architecture [draft-ietf-mboned-routingarch-12] (25 pages) - Scoped Address Discovery Protocol (SADP) [draft-ietf-mboned-sadp-02] (14 pages) - Requirements for IP Multicast Session Announcement [draft-ietf-mboned-session-announcement-req-03] (14 pages) - The Use of SNTP as a Multicast Heartbeat [draft-ietf-mboned-sntp-heart-00] (8 pages) - Source-Specific Protocol Independent Multicast in 232/8 [draft-ietf-mboned-ssm232-09] (7 pages) - Multicast Ping Protocol [draft-ietf-mboned-ssmping-09] (24 pages) - Static Allocations in 233/8 [draft-ietf-mboned-static-allocation-00] (5 pages) - IPv4-IPv6 Multicast: Problem Statement and Use Cases [draft-ietf-mboned-v4v6-mcast-ps-04] (20 pages) - Asymmetric Manifest Based Integrity [draft-jholland-mboned-ambi-05] (22 pages) - Circuit Breaker Assisted Congestion Control [draft-jholland-mboned-cbacc-01] (15 pages) - Discovery Of Restconf Metadata for Source-specific multicast [draft-jholland-mboned-dorms-02] (17 pages) - Multicasting Applications Across Inter-Domain Peering Points [draft-tarapore-mboned-multicast-cdni-07] (27 pages) Requests for Comments: RFC2365: Administratively Scoped IP Multicast (8 pages) RFC2588: IP Multicast and Firewalls (12 pages) RFC2770: GLOP Addressing in 233/8 (5 pages) * Obsoletes RFC3180 RFC2776: Multicast-Scope Zone Announcement Protocol (MZAP) (27 pages) RFC3138: Extended Assignments in 233/8 (4 pages) * Obsoletes RFC5771 RFC3170: IP Multicast Applications: Challenges and Solutions (28 pages) RFC3171: IANA Guidelines for IPv4 Multicast Address Assignments (8 pages) * Obsoletes RFC5771 RFC3180: GLOP Addressing in 233/8 (5 pages) RFC3446: Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP) (7 pages) RFC3956: Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address (18 pages) * Updates RFC7371 RFC4608: Source-Specific Protocol Independent Multicast in 232/8 (7 pages) RFC4609: Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements (23 pages) RFC4611: Multicast Source Discovery Protocol (MSDP) Deployment Scenarios (14 pages) RFC4624: Multicast Source Discovery Protocol (MSDP) MIB (32 pages) RFC5110: Overview of the Internet Multicast Routing Architecture (25 pages) RFC5132: IP Multicast MIB (59 pages) RFC5771: IANA Guidelines for IPv4 Multicast Address Assignments (11 pages) RFC5790: Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols (17 pages) RFC6034: Unicast-Prefix-Based IPv4 Multicast Addresses (5 pages) RFC6308: Overview of the Internet Multicast Addressing Architecture (14 pages) RFC6450: Multicast Ping Protocol (24 pages) RFC6676: Multicast Addresses for Documentation (7 pages) RFC7450: Automatic Multicast Tunneling (82 pages) * Updates RFC8777 * Updates RFC9601 RFC8313: Use of Multicast across Inter-domain Peering Points (44 pages) RFC8487: Mtrace Version 2: Traceroute Facility for IP Multicast (41 pages) RFC8777: DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery (33 pages) RFC8815: Deprecating Any-Source Multicast (ASM) for Interdomain Multicast (14 pages) RFC9119: Multicast Considerations over IEEE 802 Wireless Media (22 pages) RFC9630: Multicast On-Path Telemetry Using In Situ Operations, Administration, and Maintenance (IOAM) (12 pages) Media OPerationS (mops) ----------------------- Charter Last Modified: 2023-03-30 Current Status: Active Chairs: Kyle Rose Leslie Daigle Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari Operations and Management Area Advisor: Éric Vyncke Tech Advisors: Glenn Deen Warren Kumari Mailing Lists: General Discussion: mops@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mops Archive: https://mailarchive.ietf.org/arch/browse/mops/ Description of Working Group: Internet-wide and within-domain IP-delivered media is widespread, leading to significant technology development across industries not traditionally thought of as Internet technology developers or operators, as well as considerable quantities of traffic on local and transit networks. The focus of MOPS is on identifying areas where existing protocols and/or networks are challenged by updated requirements. MOPS will solicit input on media-related operational issues and practices; existing and proposed technologies related to the deployment, engineering, and operation of media streaming and manipulation protocols and procedures in the global Internet (inter-domain) and within-domain networking. In the context of this working group, media is considered to include the transport of video, audio, objects and any combination thereof, possibly non-sequentially. The scope is media and media protocols’ interactions with the network, but not the technologies of control protocols or media formats. MOPS provides a venue for both video industry and Internet engineering experts to engage in discussion of video technology’s requirements of networking standards, as well as proposals for new uses of IP technology in video. Where new protocols are needed, MOPS will help identify candidate venues for their development. The goals of MOPS include documenting existing protocol and operational issues with media on the Internet, and identifying requirements for potential IETF work. The general process of elaboration through documentation will be for issues to be identified (on the mailing list) and presentations made at WG meetings. When topics merit more coherent documentation, MOPS will adopt working group documents to capture the information in Internet-Drafts. If the working group consensus is that the material of the Internet-Draft is generally useful for archival purposes, the WG will seek publication of the work items as RFCs. At any point — from early discussion of topics, through later documentation stages — MOPS may identify a more appropriate WG for the matter and/or document, and dispatch it. With that in mind, MOPS will: 1/ Solicit regular updates from other media technology developing consortia/standards bodies working with IETF-developed protocols. 2/ Solicit input from network operators and users to identify operational issues with media delivery in and across networks, and determine solutions or workarounds to those issues. 3/ Solicit discussion and documentation of the issues and opportunities in media acquisition and delivery, and of the resulting protocols and technologies developed outside the IETF. 4/ Document operational requirements for media acquisition (for example, from cameras and recording devices) and delivery. 5/ Develop operational information to aid in operation of media technologies in the global Internet. These activities should document media operational experience, including global Internet, inter-domain and within-domain operations. In all cases of working with other organizations mentioned above, MOPS will work with existing liaison managers where the IETF has them, and informal connections with other organizations otherwise. If new formal liaison relationships are required, MOPS will work with the IAB to help establish them. Media operational and deployment issues with specific protocols or technologies (such as Applications, Transport Protocols, Routing Protocols, DNS or Sub-IP Protocols) remain the responsibility of the groups or areas responsible for those protocols or technologies. However, the MOPS Working Group may provide input to those areas/groups, as needed, and cooperate with those areas/groups in reviewing solutions to MOPS operational and deployment problems. There must be a continuing expression of interest for the Working Group to work on a particular work item. If there is no longer sufficient interest in the Working Group in a work item, the item may be removed from the list of Working Group items. The IESG is establishing this working group on an experimental basis and intends to review it, for rechartering to continue or else closure, in 2 years. Goals and Milestones: Jul 2022 - Draft documenting Streaming Video Alliance (SVA) reliance on IETF protocols Nov 2022 - Last-call document on operational considerations for low latency streaming video applications Nov 2022 - Last-call document on Streaming Video Alliance (SVA) reliance on IETF protocols (including explicit outreach to SVA) Done - Draft of edge network operational considerations for streaming media Done - Revised draft of edge network operational considerations for streaming media Done - Develop work items specific to media acquisition and delivery Done - Initial draft operational considerations for low latency streaming video applications Done - IESG to decide whether continue, re-charter or close MOPS WG Done - Revised draft operational considerations for low latency streaming video applications Internet-Drafts: - Media Operations Use Case for an Extended Reality Application on Edge Computing Infrastructure [draft-ietf-mops-ar-use-case-18] (18 pages) - Operational Considerations for Streaming Media [draft-ietf-mops-streaming-opcons-12] (37 pages) - TreeDN- Tree-based CDNs for Live Streaming to Mass Audiences [draft-ietf-mops-treedn-07] (17 pages) Requests for Comments: RFC9317: Operational Considerations for Streaming Media (37 pages) Network Configuration (netconf) ------------------------------- Charter Last Modified: 2024-07-31 Current Status: Active Chairs: Kent Watsen Per Andersson Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari Operations and Management Area Advisor: Mahesh Jethanandani Secretary: Reshad Rahman Mailing Lists: General Discussion: netconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netconf Archive: https://mailarchive.ietf.org/arch/browse/netconf/ Description of Working Group: The NETCONF Working Group, previously named after the NETCONF protocol, now renamed as the NETwork CONFiguration Working Group, is responsible for the development and maintenance of protocols such as NETCONF and RESTCONF for YANG data model-driven management (for the purposes of, for example, configuration, monitoring, telemetry, and zero-touch), their transports and encodings, defining data models necessary to support the protocols, and defining mechanisms supporting the operational deployment of systems using the protocols. The NETCONF protocol is data modeling language independent, but YANG (RFC 7950) is the recommended NETCONF data modeling language, which introduces advanced language features for configuration management. The NETCONF WG is currently responsible for: a) The network management protocol NETCONF (RFC 6241). This effort entails periodically updating the NETCONF related specifications to address new requirements as they arise. b) The network management protocol RESTCONF (RFC 8040). This effort entails periodically updating the RESTCONF related specifications to address new requirements as they arise. c) The transports and encodings used by the data model-driven protocols. d) The data models and mechanisms related to network management protocols. Specifically, data models enabling the configuration and/or monitoring of the protocols themselves. Other examples include data models for configuring access controls or discovering server metadata. e) The data models for subscriptions to data, and protocol bindings for pushing subscribed data to clients, for the purpose of monitoring and telemetry. f) The mechanisms enabling devices zero-touch provisioning and the related call home functions. The NETCONF working group consults with the NETMOD working group to ensure that new requirements are understood and can be met by the YANG data modeling language (RFC 7950) developed within that working group. Goals and Milestones: Internet-Drafts: - YANG Groupings for QUIC clients and QUIC servers [draft-andersson-netconf-quic-client-server-00] (12 pages) - Using NETCONF over QUIC connection [draft-dai-netconf-quic-netconf-over-quic-06] (10 pages) - RESTCONF Update to Support the NMDA [draft-dsdt-netconf-restconf-nmda-00] (6 pages) - NETCONF Model for NMDA [draft-dsdt-nmda-netconf-01] (13 pages) - Network Configuration Protocol (NETCONF) [draft-ietf-netconf-4741bis-10] (113 pages) - Network Configuration Protocol (NETCONF) Access Control Model [draft-ietf-netconf-access-control-07] (49 pages) - Adaptive Subscription to YANG Notification [draft-ietf-netconf-adaptive-subscription-06] (37 pages) - Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) [draft-ietf-netconf-beep-10] (10 pages) - NETCONF Call Home and RESTCONF Call Home [draft-ietf-netconf-call-home-17] (13 pages) - External Trace ID for Configuration Tracing [draft-ietf-netconf-configuration-tracing-01] (17 pages) - YANG Data Types and Groupings for Cryptography [draft-ietf-netconf-crypto-types-34] (66 pages) - Subscription to Distributed Notifications [draft-ietf-netconf-distributed-notif-09] (22 pages) - YANG Groupings for HTTP Clients and HTTP Servers [draft-ietf-netconf-http-client-server-23] (35 pages) - An HTTPS-based Transport for YANG Notifications [draft-ietf-netconf-https-notif-15] (29 pages) - A YANG Data Model for a Keystore and Keystore Operations [draft-ietf-netconf-keystore-35] (55 pages) - List Pagination for YANG-driven Protocols [draft-ietf-netconf-list-pagination-04] (65 pages) - NETCONF Extensions to Support List Pagination [draft-ietf-netconf-list-pagination-nc-04] (13 pages) - RESTCONF Extensions to Support List Pagination [draft-ietf-netconf-list-pagination-rc-04] (16 pages) - YANG Module for NETCONF Monitoring [draft-ietf-netconf-monitoring-15] (28 pages) - NETCONF Client and Server Models [draft-ietf-netconf-netconf-client-server-37] (65 pages) - Dynamic Subscription to YANG Events and Datastores over NETCONF [draft-ietf-netconf-netconf-event-notifications-22] (19 pages) - NETCONF Extensions to Support the Network Management Datastore Architecture [draft-ietf-netconf-nmda-netconf-08] (23 pages) - RESTCONF Extensions to Support the Network Management Datastore Architecture [draft-ietf-netconf-nmda-restconf-05] (9 pages) - NETCONF Event Notifications [draft-ietf-netconf-notification-14] (35 pages) - YANG Modules Describing Capabilities for Systems and Datastore Update Notifications [draft-ietf-netconf-notification-capabilities-21] (22 pages) - Notification Message Headers and Bundles [draft-ietf-netconf-notification-messages-08] (23 pages) - Updates to Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication [draft-ietf-netconf-over-tls13-04] (6 pages) - Partial Lock Remote Procedure Call (RPC) for NETCONF [draft-ietf-netconf-partial-lock-11] (23 pages) - NETCONF Private Candidates [draft-ietf-netconf-privcand-04] (59 pages) - NETCONF Configuration Protocol [draft-ietf-netconf-prot-12] (95 pages) - RESTCONF Protocol [draft-ietf-netconf-restconf-18] (137 pages) - RESTCONF Client and Server Models [draft-ietf-netconf-restconf-client-server-38] (57 pages) - RESTCONF Collection Resource [draft-ietf-netconf-restconf-collection-00] (17 pages) - Dynamic Subscription to YANG Events and Datastores over RESTCONF [draft-ietf-netconf-restconf-notif-15] (23 pages) - RESTCONF Extension to support Trace Context Headers [draft-ietf-netconf-restconf-trace-ctx-headers-01] (9 pages) - NETCONF Call Home using SSH [draft-ietf-netconf-reverse-ssh-06] (11 pages) - Using the NETCONF Protocol over Secure Shell (SSH) [draft-ietf-netconf-rfc4742bis-08] (11 pages) - RFC4743 and RFC4744 to Historic status [draft-ietf-netconf-rfc4743-rfc4744-to-historic-00] (4 pages) - Subscribing to Event Notifications [draft-ietf-netconf-rfc5277bis-01] (46 pages) - Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication [draft-ietf-netconf-rfc5539bis-10] (11 pages) - Network Configuration Access Control Model [draft-ietf-netconf-rfc6536bis-09] (58 pages) - YANG Library [draft-ietf-netconf-rfc7895bis-07] (32 pages) - NETCONF Server and RESTCONF Server Configuration Models [draft-ietf-netconf-server-model-09] (74 pages) - Using NETCONF over the Simple Object Access Protocol (SOAP) [draft-ietf-netconf-soap-08] (20 pages) - Using the NETCONF Configuration Protocol over Secure SHell (SSH) [draft-ietf-netconf-ssh-06] (10 pages) - YANG Groupings for SSH Clients and SSH Servers [draft-ietf-netconf-ssh-client-server-40] (152 pages) - Subscription to YANG Notifications [draft-ietf-netconf-subscribed-notifications-26] (77 pages) - System Keychain Model [draft-ietf-netconf-system-keychain-00] (33 pages) - Network Configuration Protocol (NETCONF) Base Notifications [draft-ietf-netconf-system-notifications-07] (15 pages) - Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request [draft-ietf-netconf-sztp-csr-14] (36 pages) - YANG Groupings for TCP Clients and TCP Servers [draft-ietf-netconf-tcp-client-server-26] (39 pages) - NETCONF over Transport Layer Security (TLS) [draft-ietf-netconf-tls-07] (7 pages) - YANG Groupings for TLS Clients and TLS Servers [draft-ietf-netconf-tls-client-server-41] (158 pages) - NETCONF Extension to support Trace Context propagation [draft-ietf-netconf-trace-ctx-extension-01] (21 pages) - Transaction ID Mechanism for NETCONF [draft-ietf-netconf-transaction-id-06] (76 pages) - A YANG Data Model for a Truststore [draft-ietf-netconf-trust-anchors-28] (43 pages) - YANG Groupings for UDP Clients and UDP Servers [draft-ietf-netconf-udp-client-server-03] (12 pages) - UDP-based Transport for Configured Subscriptions [draft-ietf-netconf-udp-notif-14] (33 pages) - UDP based Publication Channel for Streaming Telemetry [draft-ietf-netconf-udp-pub-channel-05] (21 pages) - With-defaults Capability for NETCONF [draft-ietf-netconf-with-defaults-14] (26 pages) - YANG Module Library [draft-ietf-netconf-yang-library-06] (13 pages) - Support of Versioning in YANG Notifications Subscription [draft-ietf-netconf-yang-notifications-versioning-05] (26 pages) - YANG Patch Media Type [draft-ietf-netconf-yang-patch-14] (39 pages) - Subscription to YANG Notifications for Datastore Updates [draft-ietf-netconf-yang-push-25] (58 pages) - Secure Zero Touch Provisioning (SZTP) [draft-ietf-netconf-zerotouch-29] (87 pages) - Augmented-by Addition into the IETF-YANG-Library [draft-lincla-netconf-yang-library-augmentedby-02] (29 pages) - RESTCONF Extension to support Trace Context Headers [draft-netconf-restconf-trace-ctx-headers-00] (7 pages) - NETCONF Extension to support Trace Context propagation [draft-netconf-trace-ctx-extension-00] (19 pages) - YANG Library [draft-nmdsdt-netconf-rfc7895bis-01] (23 pages) - External Trace ID for Configuration Tracing [draft-quilbeuf-netconf-configuration-tracing-00] (16 pages) - RESTCONF Extension to support Trace Context Headers [draft-rogaglia-netconf-restconf-trace-ctx-headers-00] (7 pages) - NETCONF Extension to support Trace Context propagation [draft-rogaglia-netconf-trace-ctx-extension-03] (19 pages) Requests for Comments: RFC4741: NETCONF Configuration Protocol (95 pages) * Obsoletes RFC6241 RFC4742: Using the NETCONF Configuration Protocol over Secure SHell (SSH) (10 pages) * Obsoletes RFC6242 RFC4743: Using NETCONF over the Simple Object Access Protocol (SOAP) (20 pages) * Updates RFC8996 RFC4744: Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) (10 pages) * Updates RFC8996 RFC5277: NETCONF Event Notifications (35 pages) RFC5539: NETCONF over Transport Layer Security (TLS) (7 pages) * Obsoletes RFC7589 RFC5717: Partial Lock Remote Procedure Call (RPC) for NETCONF (23 pages) RFC6022: YANG Module for NETCONF Monitoring (28 pages) RFC6241: Network Configuration Protocol (NETCONF) (113 pages) * Updates RFC7803 * Updates RFC8526 RFC6242: Using the NETCONF Protocol over Secure Shell (SSH) (11 pages) RFC6243: With-defaults Capability for NETCONF (26 pages) RFC6470: Network Configuration Protocol (NETCONF) Base Notifications (15 pages) RFC6536: Network Configuration Protocol (NETCONF) Access Control Model (49 pages) * Obsoletes RFC8341 RFC7589: Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication (11 pages) RFC7895: YANG Module Library (13 pages) * Obsoletes RFC8525 RFC8040: RESTCONF Protocol (137 pages) * Updates RFC8527 RFC8071: NETCONF Call Home and RESTCONF Call Home (13 pages) RFC8072: YANG Patch Media Type (39 pages) RFC8341: Network Configuration Access Control Model (58 pages) RFC8525: YANG Library (32 pages) RFC8526: NETCONF Extensions to Support the Network Management Datastore Architecture (23 pages) RFC8527: RESTCONF Extensions to Support the Network Management Datastore Architecture (9 pages) RFC8572: Secure Zero Touch Provisioning (SZTP) (87 pages) RFC8639: Subscription to YANG Notifications (77 pages) RFC8640: Dynamic Subscription to YANG Events and Datastores over NETCONF (19 pages) RFC8641: Subscription to YANG Notifications for Datastore Updates (58 pages) RFC8650: Dynamic Subscription to YANG Events and Datastores over RESTCONF (23 pages) RFC9196: YANG Modules Describing Capabilities for Systems and Datastore Update Notifications (22 pages) Network Modeling (netmod) ------------------------- Charter Last Modified: 2024-07-08 Current Status: Active Chairs: Kent Watsen Lou Berger Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari Operations and Management Area Advisor: Mahesh Jethanandani Secretary: James Cumming Mailing Lists: General Discussion: netmod@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netmod Archive: https://mailarchive.ietf.org/arch/browse/netmod/ Description of Working Group: The Network Modeling (NETMOD) working group is responsible for the YANG data modeling language, which can be used to specify network management data models that are transported over such protocols as NETCONF and RESTCONF, and guidelines for developing YANG models. The NETMOD working group addresses general topics related to the use of the YANG language and YANG models, for example, the mapping of YANG modeled data into various encodings. Finally, the NETMOD working group also defines core YANG models used as basic YANG building blocks, and YANG models that do not otherwise fall under the charter of any other IETF working group. The NETMOD WG may include work on YANG modules device profiles that do not otherwise fall under the charter of any other IETF working group. The NETMOD WG is responsible for: a) Maintaining the data modeling language YANG. This effort entails periodically updating the specification to address new requirements as they arise. b) Maintaining the guidelines for developing YANG models. This effort is primarily driven by updates made to the YANG specification. c) Maintaining a conceptual framework in which YANG models are used. This effort entails describing the generic context that in YANG exists and how certain YANG statements interact in that context. An example of this is YANG's relationship with datastores. d) Maintaining encodings for YANG modeled data. This effort entails updating encodings already defined by the NETMOD working group (XML and JSON) to accommodate changes to the YANG specification, and defining new YANG encodings that are needed, and yet do not fall under the charter of any other active IETF working group. e) Maintaining YANG models used as basic YANG building blocks. This effort entails updating existing YANG models (ietf-yang-types and ietf-inet-types) as needed, as well as defining additional core YANG data models when necessary. f) Defining and maintaining YANG models that do not fall under the charter of any other active IETF working group. The NETMOD working group consults with the NETCONF working group to ensure that new requirements are understood and can be met by the protocols (e.g., NETCONF and RESTCONF) developed within that working group. The NETMOD working group does not serve as a review team for YANG modules developed by other working groups. Instead, the YANG doctors, [1] as organized by the OPS area director responsible for network management, will act as advisors for other working groups and provide YANG reviews for the OPS area directors. [1] http://www.ietf.org/iesg/directorate/yang-doctors.html Goals and Milestones: Internet-Drafts: - YANG Data Extensions [draft-bierman-netmod-yang-data-ext-01] (10 pages) - A YANG Data Model for Interface Management [draft-bjorklund-netmod-rfc7223bis-00] (47 pages) - A YANG Data Model for IP Management [draft-bjorklund-netmod-rfc7277bis-00] (32 pages) - Guidelines for Authors and Reviewers of Documents Containing YANG Data Models [draft-boucadair-netmod-rfc8407bis-02] (70 pages) - Extensions to the Access Control Lists (ACLs) YANG Model [draft-dbb-netmod-acl-03] (32 pages) - Representing Unknown YANG bits in Operational State [draft-haas-netmod-unknown-bits-02] (18 pages) - Extensions to the Access Control Lists (ACLs) YANG Model [draft-ietf-netmod-acl-extensions-10] (82 pages) - YANG Data Model for Network Access Control Lists (ACLs) [draft-ietf-netmod-acl-model-21] (60 pages) - An Architecture for Network Management Using NETCONF and YANG [draft-ietf-netmod-arch-10] (30 pages) - Handling Long Lines in Content of Internet-Drafts and RFCs [draft-ietf-netmod-artwork-folding-12] (28 pages) - Representing Netconf Data Models using Document Schema Definition Languages (DSDL) [draft-ietf-netmod-dsdl-00] (72 pages) - Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content [draft-ietf-netmod-dsdl-map-10] (100 pages) - A YANG Data model for ECA Policy Management [draft-ietf-netmod-eca-policy-01] (54 pages) - A YANG Data Model for Hardware Management [draft-ietf-netmod-entity-08] (60 pages) - A YANG Data Model for Factory Default Settings [draft-ietf-netmod-factory-default-15] (10 pages) - A YANG Grouping for Geographic Locations [draft-ietf-netmod-geo-location-11] (22 pages) - IANA Address Family Numbers and Subsequent Address Family Identifiers YANG Module [draft-ietf-netmod-iana-afn-safi-00] (20 pages) - IANA Interface Type YANG Module [draft-ietf-netmod-iana-if-type-10] (37 pages) - IANA Timezone Database YANG Module [draft-ietf-netmod-iana-timezones-03] (40 pages) - YANG Metadata Annotation for Immutable Flag [draft-ietf-netmod-immutable-flag-01] (19 pages) - A YANG Data Model for Interface Management [draft-ietf-netmod-interfaces-cfg-16] (39 pages) - Common Interface Extension YANG Data Models [draft-ietf-netmod-intf-ext-yang-14] (37 pages) - A YANG Data Model for IP Management [draft-ietf-netmod-ip-cfg-14] (30 pages) - YANG Module Tags [draft-ietf-netmod-module-tags-10] (19 pages) - Comparison of Network Management Datastore Architecture (NMDA) Datastores [draft-ietf-netmod-nmda-diff-12] (16 pages) - Node Tags in YANG Modules [draft-ietf-netmod-node-tags-11] (30 pages) - Terminology and Requirements for Enhanced Handling of Operational State [draft-ietf-netmod-opstate-reqs-04] (6 pages) - Network Management Datastore Architecture (NMDA) [draft-ietf-netmod-revised-datastores-10] (44 pages) - The YANG 1.1 Data Modeling Language [draft-ietf-netmod-rfc6020bis-14] (217 pages) - Common YANG Data Types [draft-ietf-netmod-rfc6021-bis-03] (30 pages) - Guidelines for Authors and Reviewers of Documents Containing YANG Data Models [draft-ietf-netmod-rfc6087bis-20] (63 pages) - Common YANG Data Types [draft-ietf-netmod-rfc6991-bis-16] (43 pages) - A YANG Data Model for Interface Management [draft-ietf-netmod-rfc7223bis-03] (49 pages) - A YANG Data Model for IP Management [draft-ietf-netmod-rfc7277bis-03] (34 pages) - A YANG Data Model for Routing Management (NMDA Version) [draft-ietf-netmod-rfc8022bis-11] (80 pages) - Guidelines for Authors and Reviewers of Documents Containing YANG Data Models [draft-ietf-netmod-rfc8407bis-15] (92 pages) - A YANG Data Model for Routing Management [draft-ietf-netmod-routing-cfg-25] (64 pages) - A Common YANG Data Model for Scheduling [draft-ietf-netmod-schedule-yang-02] (58 pages) - YANG Schema Mount [draft-ietf-netmod-schema-mount-12] (28 pages) - Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules [draft-ietf-netmod-smi-yang-05] (36 pages) - A YANG Data Model for SNMP Configuration [draft-ietf-netmod-snmp-cfg-08] (88 pages) - Sub-interface VLAN YANG Data Models [draft-ietf-netmod-sub-intf-vlan-model-11] (34 pages) - A YANG Data Model for Syslog Configuration [draft-ietf-netmod-syslog-model-32] (44 pages) - System-defined Configuration [draft-ietf-netmod-system-config-08] (47 pages) - A YANG Data Model for System Management [draft-ietf-netmod-system-mgmt-16] (35 pages) - YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) [draft-ietf-netmod-yang-13] (173 pages) - YANG Data Structure Extensions [draft-ietf-netmod-yang-data-ext-05] (16 pages) - A File Format for YANG Instance Data [draft-ietf-netmod-yang-instance-file-format-21] (24 pages) - JSON Encoding of Data Modeled with YANG [draft-ietf-netmod-yang-json-10] (20 pages) - Defining and Using Metadata with YANG [draft-ietf-netmod-yang-metadata-07] (21 pages) - YANG Module Classification [draft-ietf-netmod-yang-model-classification-08] (11 pages) - YANG module file name convention [draft-ietf-netmod-yang-module-filename-00] (5 pages) - Updated YANG Module Revision Handling [draft-ietf-netmod-yang-module-versioning-12] (36 pages) - YANG Packages [draft-ietf-netmod-yang-packages-03] (53 pages) - YANG Schema Comparison [draft-ietf-netmod-yang-schema-comparison-02] (24 pages) - YANG Semantic Versioning [draft-ietf-netmod-yang-semver-17] (34 pages) - YANG Versioning Solution Overview [draft-ietf-netmod-yang-solutions-01] (8 pages) - YANG Tree Diagrams [draft-ietf-netmod-yang-tree-diagrams-06] (13 pages) - Common YANG Data Types [draft-ietf-netmod-yang-types-09] (26 pages) - Guidelines for Authors and Reviewers of YANG Data Model Documents [draft-ietf-netmod-yang-usage-11] (26 pages) - YANG Schema Selection [draft-ietf-netmod-yang-ver-selection-00] (32 pages) - YANG Module Versioning Requirements [draft-ietf-netmod-yang-versioning-reqs-10] (12 pages) - Handling Long Lines in Artwork in Internet-Drafts and RFCs [draft-kwatsen-netmod-artwork-folding-08] (17 pages) - YANG Based Instance Data Files Format [draft-lengyel-netmod-yang-instance-data-05] (14 pages) - YANG Metadata Annotation for Immutable Flag [draft-ma-netmod-immutable-flag-09] (19 pages) - System-defined Configuration [draft-ma-netmod-with-system-05] (43 pages) - A Revised Conceptual Model for YANG Datastores [draft-nmdsdt-netmod-revised-datastores-00] (20 pages) - Catalog and registry for YANG models [draft-openconfig-netmod-model-catalog-02] (40 pages) - Self Describing Data Object Tags [draft-tao-netmod-yang-node-tags-06] (26 pages) - Sub-interface VLAN YANG Data Models [draft-wilton-netmod-intf-vlan-yang-04] (27 pages) - A YANG Data model for ECA Policy Management [draft-wwx-netmod-event-yang-10] (54 pages) Requests for Comments: RFC6020: YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) (173 pages) RFC6021: Common YANG Data Types (26 pages) * Obsoletes RFC6991 RFC6087: Guidelines for Authors and Reviewers of YANG Data Model Documents (26 pages) * Obsoletes RFC8407 RFC6110: Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content (100 pages) * Updates RFC7952 RFC6244: An Architecture for Network Management Using NETCONF and YANG (30 pages) RFC6643: Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules (36 pages) RFC6991: Common YANG Data Types (30 pages) RFC7223: A YANG Data Model for Interface Management (39 pages) * Obsoletes RFC8343 RFC7224: IANA Interface Type YANG Module (37 pages) RFC7277: A YANG Data Model for IP Management (30 pages) * Obsoletes RFC8344 RFC7317: A YANG Data Model for System Management (35 pages) RFC7407: A YANG Data Model for SNMP Configuration (88 pages) RFC7950: The YANG 1.1 Data Modeling Language (217 pages) * Updates RFC8342 * Updates RFC8526 RFC7951: JSON Encoding of Data Modeled with YANG (20 pages) RFC7952: Defining and Using Metadata with YANG (21 pages) RFC8022: A YANG Data Model for Routing Management (64 pages) * Obsoletes RFC8349 RFC8199: YANG Module Classification (11 pages) RFC8340: YANG Tree Diagrams (13 pages) * Updates RFC8791 RFC8342: Network Management Datastore Architecture (NMDA) (44 pages) RFC8343: A YANG Data Model for Interface Management (49 pages) RFC8344: A YANG Data Model for IP Management (34 pages) RFC8348: A YANG Data Model for Hardware Management (60 pages) RFC8349: A YANG Data Model for Routing Management (NMDA Version) (80 pages) RFC8407: Guidelines for Authors and Reviewers of Documents Containing YANG Data Models (63 pages) * Updates RFC8819 RFC8519: YANG Data Model for Network Access Control Lists (ACLs) (60 pages) RFC8528: YANG Schema Mount (28 pages) RFC8791: YANG Data Structure Extensions (16 pages) RFC8792: Handling Long Lines in Content of Internet-Drafts and RFCs (28 pages) RFC8808: A YANG Data Model for Factory Default Settings (10 pages) RFC8819: YANG Module Tags (19 pages) RFC9144: Comparison of Network Management Datastore Architecture (NMDA) Datastores (16 pages) RFC9179: A YANG Grouping for Geographic Locations (22 pages) RFC9195: A File Format for YANG Instance Data (24 pages) Network Management Operations (nmop) ------------------------------------ Charter Last Modified: 2024-07-25 Current Status: Active Chairs: Benoît Claise Mohamed Boucadair Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari Operations and Management Area Advisor: Mahesh Jethanandani Secretary: Thomas Graf Mailing Lists: General Discussion: nmop@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/nmop Archive: https://mailarchive.ietf.org/arch/browse/nmop/ Description of Working Group: The increased drive by operators for integration and deployment of network management protocols and YANG data models may expose issues and problems with the individual protocols and models, or with the wider integration of both the protocols and the models. Some of these problems may only be witnessed when trying to manage large-scale networks, e.g., due to the increased complexity and handling large volumes of data exported in frequent updates. At the same time, simplifying the network management and operations, with increased automation, is a high priority for network operators. The goals of the Network Management Operations working group are to solicit input from network operators to identify existing and anticipated operational issues arising from the near-term deployment of network management technologies, and to consider potential solutions or workarounds for those issues. Those operational issues may relate to deployments of existing network management technologies or the integration of related technologies for network management and telemetry. Solving those operational issues requires discussion, investigation, and potentially some experiments, which may take some time. However, the working group will focus on pragmatic items achievable in a short timeframe over long term architectural visions. Since the focus is on solving network management problems faced by operators, discussion and experiments are not solely limited to network management technologies standardized within the IETF but may cover the wider network management ecosystem as it relates to the management of IETF protocols, subject to the following two constraints: * The working group may discuss network management protocols and data models not standardized within the IETF only when they are being used to manage IETF protocols or to compare them to equivalent IETF solutions. * The working group will not work on specific issues or improvements to protocols or data models developed and maintained outside the IETF. They must be taken to the appropriate organization for discussion and resolution. The Network Management Operations working group is scoped, in rough order from highest to lowest priority, to: * Present and discuss operational issues faced by the deployment of existing network management technologies. * Discuss ideas for future short-term experiments (i.e., those focused on incremental improvements to network management operations that can be achieved in 1-2 years) and report on the progress of the relevant experimentation being done in the community. * Discuss network operator use cases and requirements for solving anticipated problems related to the deployment of network management technologies. * Standardize YANG data models to solve operational issues identified in the scope items above. YANG data models potentially within the scope of other WGs will only be progressed here with agreement from the relevant ADs. * Seek involvement with developers of open-source software to help drive adoption of IETF network management standards and to improve protocol maturity. * Document operational experience and best practice for network management and telemetry deployment as BCPs or Informational RFCs. This working group is not chartered to work on new protocols or protocol enhancements. Agenda time at NMOP sessions at IETF meetings should allow for presentations and discussions of operator issues and experience, and other work within scope for the working group, but with a default expectation that priority be given to operator presentations. The current topics of focus for the working group are: * NETCONF/YANG Push integration with Apache Kafka & time series databases * Anomaly detection and incident management * Issues related to deployment/usage of YANG topology modules (e.g., to model a Digital Map) * Consider/plan an approach for updating RFC 3535-bis (collecting updated operator requirements for IETF network management solutions) Like many of the “ops” working groups, this working group is expected to be long-lived, and is expected to remain open whilst there is sufficient interest and drive from the operators to work on topics within the scope described above. Goals and Milestones: Sep 2025 - Submit Architecture for YANG-Push to Message Broker Integration to the IESG Dec 2025 - Submit NMOP Terminology to the IESG Dec 2025 - Submit Network Incident Management to the IESG Dec 2025 - Submit Network Anomaly Management to the IESG Done - Adopt a document on network incident management Done - Adopt a document describing how to integrate YANG Push with Apache Kafka Done - Adopt a terminology document for anomaly and incident management Done - Adopt a document on network anomaly management Internet-Drafts: - Some Key Terms for Network Incident and Problem Management [draft-davis-nmop-incident-terminology-01] (13 pages) - A YANG Data Model for Network Incident Management [draft-feng-nmop-network-incident-yang-03] (34 pages) - Digital Map: Concept, Requirements, and Use Cases [draft-havel-nmop-digital-map-concept-00] (15 pages) - An Architecture for a Network Anomaly Detection Framework [draft-ietf-nmop-network-anomaly-architecture-00] (18 pages) - A YANG Data Model for Network Incident Management [draft-ietf-nmop-network-incident-yang-01] (42 pages) - Some Key Terms for Network Fault and Problem Management [draft-ietf-nmop-terminology-05] (13 pages) - An Architecture for YANG-Push to Message Broker Integration [draft-ietf-nmop-yang-message-broker-integration-04] (23 pages) - An Architecture for a Network Anomaly Detection Framework [draft-netana-nmop-network-anomaly-architecture-00] (18 pages) - An Architecture for YANG-Push to Message Broker Integration [draft-netana-nmop-yang-message-broker-integration-00] (21 pages) No Requests for Comments Operations and Management Area Working Group (opsawg) ----------------------------------------------------- Charter Last Modified: 2024-07-25 Current Status: Active Chairs: Benoît Claise Henk Birkholz Joe Clarke Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari Operations and Management Area Advisor: Mahesh Jethanandani Mailing Lists: General Discussion: opsawg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/opsawg Archive: https://mailarchive.ietf.org/arch/browse/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) Templates and tools for Operations and Management Area Documents (B) Maintenance and small scale extensions of documents that were developed in working groups that have concluded (e.g. MIB modules). (C) The RFC 5066 "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB" has transitioned to the IEEE 802.3. However, as agreed with the IEEE, the IF-CAP- STACK-MIB MIB module (from RFC5066) is generic by nature and should continue to be supported by the IETF. The WG will develop a document extracting the IF-CAP-STACK-MIB from RFC5066, emphasizing the generic nature of this module, and obsolete RFC5066. (D) Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011. Considering RFC 4663 "Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG" as an reference, the following pieces of information would the foundation for the document: a table mapping the old IETF MIB names with the corresponding new IEEE ones, clarifications/rules on the IETF-IEEE interactions (mailing lists, reviews), and clarifications on the intellectual property considerations. Goals and Milestones: Oct 2012 - Initial submission for the 'RFCs transitioned to the IEEE 802.3.1-2011' Internet-Draft Mar 2013 - Submit the 'RFCs transitioned to the IEEE 802.3.1-2011' Internet-Draft to the IESG for consideration as Informational Done - Initial submission for the 'SNMP Engine ID Discovery' Internet-Draft Done - WGLC for the 'SNMP Engine ID Discovery' Internet-Draft Done - Initial submission for the 'Guidelines for Considering Operations and Management of New Protocols' Internet-Draft Done - Initial submission for the 'Template for Generic Management Data Models' Internet-Draft Done - Initial submission for the 'Structured Data Elements (SDEs) for syslog' Internet-Draft Done - Submit the 'SNMP Engine ID Discovery' Internet-Draft to the IESG for consideration as Proposed Standard Done - WGLC for the 'Guidelines for Considering Operations and Management of New Protocols' Internet-Draft Done - Submit the 'Guidelines for Considering Operations and Management of New Protocols' Internet-Draft to the IESG for consideration as BCP Done - WGLC for the 'Structured Data Elements (SDEs) for syslog' Done - Submit the 'Structured Data Elements (SDEs) for syslog' to the IESG for consideration as Proposed Standard Done - Initial submission for the 'IF-CAP-STACK-MIB MIB module' Internet-Draft Done - Submit the 'IF-CAP-STACK-MIB MIB module' Internet-Draft to the IESG for consideration as Proposed Standard Internet-Drafts: - Layer 3 VPN Network Model [draft-aguado-opsawg-l3sm-l3nm-02] (96 pages) - On Firewalls in Internet Security [draft-baker-opsawg-firewalls-00] (12 pages) - Finding and Using Geofeed Data [draft-ietf-opsawg-9092-update-11] (26 pages) - A YANG Data Model for Augmenting VPN Service and Network Models with Attachment Circuits [draft-ietf-opsawg-ac-lxsm-lxnm-glue-10] (33 pages) - RADIUS Extensions for DHCP-Configured Services [draft-ietf-opsawg-add-encrypted-dns-12] (18 pages) - Survey of Possibilities for the Automated Configuration of Large IP Networks [draft-ietf-opsawg-automated-network-configuration-05] (23 pages) - Alternate Tunnel Encapsulation for Data Frames in Control and Provisioning of Wireless Access Points (CAPWAP) [draft-ietf-opsawg-capwap-alt-tunnel-12] (29 pages) - CAPWAP Extension for 802.11n and Power/channel Autoconfiguration [draft-ietf-opsawg-capwap-extension-06] (17 pages) - IEEE 802.11 Medium Access Control (MAC) Profile for Control and Provisioning of Wireless Access Points (CAPWAP) [draft-ietf-opsawg-capwap-hybridmac-08] (13 pages) - A Data Manifest for Contextualized Telemetry Data [draft-ietf-opsawg-collected-data-manifest-04] (46 pages) - Management of Networks with Constrained Devices: Problem Statement and Requirements [draft-ietf-opsawg-coman-probstate-reqs-05] (44 pages) - Management of Networks with Constrained Devices: Use Cases [draft-ietf-opsawg-coman-use-cases-05] (26 pages) - A Template for Internet Drafts Containing Data Models [draft-ietf-opsawg-data-model-doc-template-00] (24 pages) - An Information Model for Packet Discard Reporting [draft-ietf-opsawg-discardmodel-03] (30 pages) - Finding and Using Geofeed Data [draft-ietf-opsawg-finding-geofeeds-17] (21 pages) - On Firewalls in Internet Security [draft-ietf-opsawg-firewalls-01] (10 pages) - HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3 [draft-ietf-opsawg-hmac-sha-2-usm-snmp-06] (14 pages) - HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3 [draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-05] (14 pages) - IPFIX Alternate-Marking Information [draft-ietf-opsawg-ipfix-alt-mark-00] (9 pages) - Export of BGP Community Information in IP Flow Information Export (IPFIX) [draft-ietf-opsawg-ipfix-bgp-community-12] (18 pages) - Simple Fixes to the IP Flow Information Export (IPFIX) Entities IANA Registry [draft-ietf-opsawg-ipfix-fixes-12] (38 pages) - Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX) [draft-ietf-opsawg-ipfix-mpls-sr-label-type-11] (5 pages) - Export of Delay Performance Metrics in IP Flow Information eXport (IPFIX) [draft-ietf-opsawg-ipfix-on-path-telemetry-12] (32 pages) - Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX) [draft-ietf-opsawg-ipfix-srv6-srh-14] (23 pages) - Extended TCP Options and IPv6 Extension Headers IPFIX Information Elements [draft-ietf-opsawg-ipfix-tcpo-v6eh-18] (26 pages) - A YANG Network Data Model for Layer 2 VPNs [draft-ietf-opsawg-l2nm-19] (139 pages) - A YANG Network Data Model for Layer 3 VPNs [draft-ietf-opsawg-l3sm-l3nm-18] (129 pages) - Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks [draft-ietf-opsawg-large-flow-load-balancing-15] (29 pages) - Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs [draft-ietf-opsawg-lsn-deployment-06] (20 pages) - An Overview of the IETF Network Management Standards [draft-ietf-opsawg-management-stds-07] (85 pages) - Textual Conventions for the Representation of Floating-Point Numbers [draft-ietf-opsawg-mib-floats-02] (7 pages) - MIB Transfer from the IETF to the IEEE 802.3 WG [draft-ietf-opsawg-mibs-to-ieee80231-01] (7 pages) - A Framework for Automating Service and Network Management with YANG [draft-ietf-opsawg-model-automation-framework-10] (40 pages) - Guidelines for the Use of the "OAM" Acronym in the IETF [draft-ietf-opsawg-mpls-tp-oam-def-10] (9 pages) - Manufacturer Usage Description Specification [draft-ietf-opsawg-mud-25] (60 pages) - Authorized update to MUD URLs [draft-ietf-opsawg-mud-acceptable-urls-12] (15 pages) - Operational Considerations for Use of DNS in IoT Devices [draft-ietf-opsawg-mud-iot-dns-considerations-17] (21 pages) - Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices [draft-ietf-opsawg-mud-tls-18] (39 pages) - A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT) [draft-ietf-opsawg-nat-yang-17] (94 pages) - Network Telemetry Framework [draft-ietf-opsawg-ntf-13] (33 pages) - A Network YANG Data Model for Attachment Circuits [draft-ietf-opsawg-ntw-attachment-circuit-13] (106 pages) - Guidelines for Charactering "OAM" [draft-ietf-opsawg-oam-characterization-03] (10 pages) - An Overview of Operations, Administration, and Maintenance (OAM) Tools [draft-ietf-opsawg-oam-overview-16] (53 pages) - Ownership and licensing statements in YANG [draft-ietf-opsawg-ol-06] (9 pages) - Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions [draft-ietf-opsawg-operations-and-management-09] (35 pages) - PCAP Capture File Format [draft-ietf-opsawg-pcap-04] (10 pages) - Link-Layer Types for PCAP and PCAPNG Capture File Formats [draft-ietf-opsawg-pcaplinktype-05] (26 pages) - PCAP Next Generation (pcapng) Capture File Format [draft-ietf-opsawg-pcapng-02] (60 pages) - Ethernet in the First Mile Copper (EFMCu) Interfaces MIB [draft-ietf-opsawg-rfc5066bis-07] (6 pages) - An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element [draft-ietf-opsawg-rfc7125-update-07] (8 pages) - A YANG Network Data Model for Service Attachment Points (SAPs) [draft-ietf-opsawg-sap-15] (37 pages) - A YANG Data Model for Reporting Software Bills of Materials (SBOMs) and Vulnerability Information [draft-ietf-opsawg-sbom-access-18] (18 pages) - Secure Device Install [draft-ietf-opsawg-sdi-13] (16 pages) - Service Assurance for Intent-Based Networking Architecture [draft-ietf-opsawg-service-assurance-architecture-13] (23 pages) - A YANG Data Model for Service Assurance [draft-ietf-opsawg-service-assurance-yang-11] (38 pages) - Service Models Explained [draft-ietf-opsawg-service-model-explained-05] (23 pages) - Expressing SNMP SMI Datatypes in XML Schema Definition Language [draft-ietf-opsawg-smi-datatypes-in-xsd-06] (14 pages) - Simple Network Management Protocol (SNMP) Context EngineID Discovery [draft-ietf-opsawg-snmp-engineid-discovery-03] (9 pages) - Survey of IETF Network Management Standards [draft-ietf-opsawg-survey-management-00] (21 pages) - Alarms in Syslog [draft-ietf-opsawg-syslog-alarm-02] (7 pages) - Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications [draft-ietf-opsawg-syslog-msg-mib-06] (22 pages) - Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages [draft-ietf-opsawg-syslog-snmp-05] (15 pages) - The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol [draft-ietf-opsawg-tacacs-18] (41 pages) - Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3 [draft-ietf-opsawg-tacacs-tls13-11] (17 pages) - A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+) [draft-ietf-opsawg-tacacs-yang-12] (16 pages) - YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) [draft-ietf-opsawg-teas-attachment-circuit-16] (150 pages) - A Common YANG Data Model for Attachment Circuits [draft-ietf-opsawg-teas-common-ac-12] (59 pages) - Updates to the TLS Transport Model for SNMP [draft-ietf-opsawg-tlstm-update-15] (30 pages) - Export of UDP Options Information in IP Flow Information Export (IPFIX) [draft-ietf-opsawg-tsvwg-udp-ipfix-14] (13 pages) - A YANG Data Model and RADIUS Extension for Policy-based Network Access Control [draft-ietf-opsawg-ucl-acl-05] (38 pages) - Management Information Base for Virtual Machines Controlled by a Hypervisor [draft-ietf-opsawg-vmm-mib-04] (52 pages) - A Common YANG Data Model for Layer 2 and Layer 3 VPNs [draft-ietf-opsawg-vpn-common-12] (60 pages) - A YANG Data Model for Network and VPN Service Performance Monitoring [draft-ietf-opsawg-yang-vpn-service-pm-15] (39 pages) - CGN Deployment with MPLS/VPNs [draft-kuarsingh-lsn-deployment-06] (18 pages) - Export BGP community information in IP Flow Information Export (IPFIX) [draft-li-opsawg-ipfix-bgp-community-02] (10 pages) - Guidelines for Charactering "OAM" [draft-pignataro-opsawg-oam-whaaat-question-mark-05] (10 pages) - Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX) [draft-tgraf-ipfix-mpls-sr-label-type-07] (6 pages) - Export of On-Path Delay in IPFIX [draft-tgraf-opsawg-ipfix-on-path-telemetry-01] (23 pages) - Transport Layer Security Verion 1.3 (TLS 1.3) Transport Model for the Simple Network Management Protocol Version 3 (SNMPv3) [draft-vaughn-tlstm-update-01] (43 pages) Requests for Comments: RFC5343: Simple Network Management Protocol (SNMP) Context EngineID Discovery (9 pages) RFC5674: Alarms in Syslog (7 pages) RFC5675: Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages (15 pages) RFC5676: Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications (22 pages) RFC5706: Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions (35 pages) RFC5935: Expressing SNMP SMI Datatypes in XML Schema Definition Language (14 pages) RFC6291: Guidelines for the Use of the "OAM" Acronym in the IETF (9 pages) RFC6340: Textual Conventions for the Representation of Floating-Point Numbers (7 pages) RFC6632: An Overview of the IETF Network Management Standards (85 pages) RFC7124: Ethernet in the First Mile Copper (EFMCu) Interfaces MIB (6 pages) RFC7276: An Overview of Operations, Administration, and Maintenance (OAM) Tools (53 pages) RFC7289: Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs (20 pages) RFC7424: Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks (29 pages) RFC7448: MIB Transfer from the IETF to the IEEE 802.3 WG (7 pages) RFC7494: IEEE 802.11 Medium Access Control (MAC) Profile for Control and Provisioning of Wireless Access Points (CAPWAP) (13 pages) RFC7547: Management of Networks with Constrained Devices: Problem Statement and Requirements (44 pages) RFC7548: Management of Networks with Constrained Devices: Use Cases (26 pages) RFC7630: HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3 (14 pages) * Obsoletes RFC7860 RFC7666: Management Information Base for Virtual Machines Controlled by a Hypervisor (52 pages) RFC7860: HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3 (14 pages) RFC8309: Service Models Explained (23 pages) RFC8350: Alternate Tunnel Encapsulation for Data Frames in Control and Provisioning of Wireless Access Points (CAPWAP) (29 pages) RFC8512: A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT) (94 pages) RFC8520: Manufacturer Usage Description Specification (60 pages) RFC8549: Export of BGP Community Information in IP Flow Information Export (IPFIX) (18 pages) RFC8886: Secure Device Install (16 pages) RFC8907: The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol (41 pages) RFC8969: A Framework for Automating Service and Network Management with YANG (40 pages) RFC9092: Finding and Using Geofeed Data (21 pages) * Obsoletes RFC9632 RFC9105: A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+) (16 pages) RFC9160: Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX) (5 pages) RFC9181: A Common YANG Data Model for Layer 2 and Layer 3 VPNs (60 pages) RFC9182: A YANG Network Data Model for Layer 3 VPNs (129 pages) RFC9232: Network Telemetry Framework (33 pages) RFC9291: A YANG Network Data Model for Layer 2 VPNs (139 pages) RFC9375: A YANG Data Model for Network and VPN Service Performance Monitoring (39 pages) RFC9408: A YANG Network Data Model for Service Attachment Points (SAPs) (37 pages) RFC9417: Service Assurance for Intent-Based Networking Architecture (23 pages) RFC9418: A YANG Data Model for Service Assurance (38 pages) RFC9445: RADIUS Extensions for DHCP-Configured Services (18 pages) RFC9456: Updates to the TLS Transport Model for SNMP (30 pages) RFC9472: A YANG Data Model for Reporting Software Bills of Materials (SBOMs) and Vulnerability Information (18 pages) RFC9487: Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX) (23 pages) RFC9565: An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element (7 pages) RFC9632: Finding and Using Geofeed Data (23 pages) SIDR Operations (sidrops) ------------------------- Charter Last Modified: 2024-03-19 Current Status: Active Chairs: Chris Morrow Keyur Patel Russ Housley Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari Operations and Management Area Advisor: Warren Kumari Secretary: Krishnaswamy Ananthamurthy Mailing Lists: General Discussion: sidrops@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sidrops Archive: https://mailarchive.ietf.org/arch/browse/sidrops/ Description of Working Group: The global deployment of SIDR, consisting of RPKI, Origin Validation of BGP announcements, and BGPSEC, is underway, creating an Internet Routing System consisting of SIDR-aware and non-SIDR-aware networks. This deployment must be properly handled to avoid the division of the Internet into separate networks. Sidrops is responsible for encouraging deployment of theSIDR technologies while ensuring as secure of a global routing system, as possible, during the transition. The SIDR Operations Working Group (sidrops) develops guidelines for the operation of SIDR-aware networks, and provides operational guidance on how to deploy and operate SIDR technologies in existing and new networks. In the space of sidrops, the term operators will encompass a range of operational experience: CA Operators, Regional/National and Local Internet Registries, Relying Party software developers as well as the research/measurement community all have relevant operational experience or insight that this working group will consider in its work. The sidrops working group is focused on deployment and operational issues and experiences with SIDR technologies that are part of the global routing system, as well as the repositories and CA systems that form part of the SIDR architecture. The goals of the sidrops working group are to: 1. Solicit input from a range of operators to identify operational issues with a SIDR-aware Internet, and determine solutions or workarounds to those issues. 2. Solicit input from all operators to identify issues with interaction with the non-SIDR-aware Internet, and to determine solutions or workarounds to those issues. 3. Develop operational solutions for identified issues in sidrops and document them in informational or BCP documents. These documents should document SIDR operational experience, including interactions with non-SIDR-aware networks, the interfaces between SIDR- aware and non-SIDR-aware networks, and the continued operational/ security impacts from non-SIDR-aware networks. SIDR operational and deployment issues with Interdomain Routing Protocols as well as BGPSEC maintenance and extension are the primary responsibility of the IDR working group. The sidrops Working Group may provide input to that group, as needed, and cooperate with that group in reviewing solutions to SIDR operational and deployment problems. Future work items within this scope will be adopted by the Working Group if there is a substantial expression of interest from the community and if the work (for example protocol maintenance) clearly does not fit elsewhere in the IETF. There must be a continuous expression of interest for the Working Group to work on a particular work item. If there is no longer sufficient interest in the Working Group in a work item, the item may be removed from the list of Working Group items. Goals and Milestones: Jul 2017 - draft-ietf-sidr-bgpsec-rollover Jul 2017 - draft-ietf-sidr-rtr-keying Jul 2017 - draft-ietf-sidr-route-server-rpki-light Jul 2017 - draft-ietf-sidr-rpki-tree-validation Sep 2017 - BGPSEC Ops document finalized. Internet-Drafts: - BGPsec Router Certificate Rollover [draft-ietf-sidr-bgpsec-rollover-06] (10 pages) - Use Cases for Localized Versions of the RPKI [draft-ietf-sidr-lta-use-cases-07] (5 pages) - Manifests for the Resource Public Key Infrastructure (RPKI) [draft-ietf-sidrops-6486bis-11] (16 pages) - The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2 [draft-ietf-sidrops-8210bis-15] (38 pages) - Human Readable ASPA Notation [draft-ietf-sidrops-aspa-notation-00] (5 pages) - A Profile for Autonomous System Provider Authorization [draft-ietf-sidrops-aspa-profile-18] (15 pages) - Simplified Local Internet Number Resource Management (SLURM) with RPKI Autonomous System Provider Authorizations (ASPA) [draft-ietf-sidrops-aspa-slurm-01] (8 pages) - BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects [draft-ietf-sidrops-aspa-verification-18] (20 pages) - Guidance to Avoid Carrying RPKI Validation States in Transitive BGP Path Attributes [draft-ietf-sidrops-avoid-rpki-state-in-bgp-00] (13 pages) - BGPsec Algorithms, Key Formats, and Signature Formats [draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-05] (21 pages) - BGPsec Router Certificate Rollover [draft-ietf-sidrops-bgpsec-rollover-04] (11 pages) - On the use of the CMS signing-time attribute in RPKI Signed Objects [draft-ietf-sidrops-cms-signing-time-07] (11 pages) - Resource Public Key Infrastructure (RPKI) Repository Requirements [draft-ietf-sidrops-deprecate-rsync-00] (10 pages) - Resource Public Key Infrastructure (RPKI) Trust Anchor Locator [draft-ietf-sidrops-https-tal-08] (11 pages) - Use Cases for Localized Versions of the RPKI [draft-ietf-sidrops-lta-use-cases-06] (6 pages) - RPKI Manifest Number Handling [draft-ietf-sidrops-manifest-numbers-01] (12 pages) - Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI) [draft-ietf-sidrops-ov-clarify-05] (5 pages) - Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export [draft-ietf-sidrops-ov-egress-04] (5 pages) - Resource Public Key Infrastructure (RPKI) Repository Requirements [draft-ietf-sidrops-prefer-rrdp-02] (10 pages) - RPKI Publication Server Best Current Practices [draft-ietf-sidrops-publication-server-bcp-00] (12 pages) - A Profile for Route Origin Authorizations (ROAs) [draft-ietf-sidrops-rfc6482bis-09] (17 pages) - Avoiding Route Origin Authorizations (ROAs) Containing Multiple IP Prefixes [draft-ietf-sidrops-roa-considerations-08] (6 pages) - Signaling Prefix Origin Validation Results from a Route Server to Peers [draft-ietf-sidrops-route-server-rpki-light-02] (7 pages) - Policy Based on the Resource Public Key Infrastructure (RPKI) without Route Refresh [draft-ietf-sidrops-rov-no-rr-08] (7 pages) - Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties [draft-ietf-sidrops-rp-06] (11 pages) - Relying Party Handling of Resource Public Key Infrastructure (RPKI) Certificate Revocation List (CRL) Number Extensions [draft-ietf-sidrops-rpki-crl-numbers-00] (6 pages) - The 'I' in RPKI Does Not Stand for Identity [draft-ietf-sidrops-rpki-has-no-identity-07] (7 pages) - The Use of maxLength in the Resource Public Key Infrastructure (RPKI) [draft-ietf-sidrops-rpkimaxlen-15] (13 pages) - A profile for Signed Prefix Lists for Use in the Resource Public Key Infrastructure (RPKI) [draft-ietf-sidrops-rpki-prefixlist-03] (14 pages) - Timing Parameters in the RPKI based Route Origin Validation Supply Chain [draft-ietf-sidrops-rpki-rov-timing-06] (10 pages) - A Profile for RPKI Signed Checklists (RSCs) [draft-ietf-sidrops-rpki-rsc-11] (13 pages) - A profile for Resource Tagged Attestations (RTAs) [draft-ietf-sidrops-rpki-rta-00] (13 pages) - RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation [draft-ietf-sidrops-rpki-tree-validation-03] (17 pages) - RPKI Validation Re-reconsidered [draft-ietf-sidrops-rpki-validation-update-00] (10 pages) - Detecting RRDP Session Desynchronization [draft-ietf-sidrops-rrdp-desynchronization-03] (9 pages) - Same-Origin Policy for the RPKI Repository Delta Protocol (RRDP) [draft-ietf-sidrops-rrdp-same-origin-02] (6 pages) - Router Keying for BGPsec [draft-ietf-sidrops-rtr-keying-06] (21 pages) - RPKI Signed Object for Trust Anchor Key [draft-ietf-sidrops-signed-tal-16] (24 pages) - Signed Prefix List (SPL) Based Route Origin Verification and Operational Considerations [draft-ietf-sidrops-spl-verification-00] (10 pages) - Signaling Prefix Origin Validation Results from an RPKI Origin Validating BGP Speaker to BGP Peers [draft-ietf-sidrops-validating-bgp-speaker-03] (8 pages) - Human Readable Validate ROA Payload Notation [draft-ietf-sidrops-vrp-notation-00] (5 pages) - Signaling Prefix Origin Validation Results from a Route-Server to Peers [draft-ietf-sidr-route-server-rpki-light-01] (6 pages) - RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator [draft-ietf-sidr-rpki-tree-validation-03] (15 pages) - BGPsec Validation State Signaling [draft-sidrops-bgpsec-validation-signaling-05] (8 pages) - A profile for RPKI Signed Lists of Prefixes [draft-spaghetti-sidrops-rpki-prefixlist-01] (12 pages) - Same-Origin Policy for the RPKI Repository Delta Protocol (RRDP) [draft-spaghetti-sidrops-rrdp-same-origin-00] (7 pages) - Source Address Validation Using BGP UPDATEs, ASPA, and ROA (BAR-SAV) [draft-sriram-sidrops-bar-sav-02] (15 pages) - Signed Prefix List (SPL) Based Route Origin Verification and Operational Considerations [draft-sriram-sidrops-spl-verification-00] (10 pages) - Human Readable ASPA Notation [draft-timbru-sidrops-aspa-notation-01] (5 pages) - Human Readable Validate ROA Payload Notation [draft-timbru-sidrops-vrp-notation-00] (5 pages) Requests for Comments: RFC8481: Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI) (5 pages) * Updates RFC9324 RFC8488: RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation (17 pages) RFC8608: BGPsec Algorithms, Key Formats, and Signature Formats (21 pages) RFC8630: Resource Public Key Infrastructure (RPKI) Trust Anchor Locator (11 pages) RFC8634: BGPsec Router Certificate Rollover (11 pages) RFC8635: Router Keying for BGPsec (21 pages) RFC8893: Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export (5 pages) RFC8897: Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties (11 pages) RFC9255: The 'I' in RPKI Does Not Stand for Identity (7 pages) RFC9286: Manifests for the Resource Public Key Infrastructure (RPKI) (16 pages) RFC9319: The Use of maxLength in the Resource Public Key Infrastructure (RPKI) (13 pages) RFC9323: A Profile for RPKI Signed Checklists (RSCs) (13 pages) RFC9324: Policy Based on the Resource Public Key Infrastructure (RPKI) without Route Refresh (7 pages) RFC9455: Avoiding Route Origin Authorizations (ROAs) Containing Multiple IP Prefixes (6 pages) RFC9582: A Profile for Route Origin Authorizations (ROAs) (15 pages) RFC9589: On the Use of the Cryptographic Message Syntax (CMS) Signing-Time Attribute in Resource Public Key Infrastructure (RPKI) Signed Objects (9 pages) SRv6 Operations (srv6ops) ------------------------- Charter Last Modified: 2024-06-17 Current Status: Active Chairs: Daniel Voyer Dhruv Dhody Weiqiang Cheng Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari Operations and Management Area Advisor: Jim Guichard Mailing Lists: General Discussion: srv6ops@ietf.org To Subscribe: https://mailman3.ietf.org/mailman3/lists/srv6ops.ietf.org/ Archive: https://mailarchive.ietf.org/arch/browse/srv6ops/ Description of Working Group: # Charter for SRv6 Operations (SRv6OPS) The Segment Routing (SR) instantiation on the IPv6 data plane is known as SRv6. ## Objective: The SRv6OPS Working Group (WG) is dedicated to the operational aspects of deploying and managing SRv6 networks. Our mission includes: * Being a forum for network operators to discuss operational matters in SRv6 networks. * Identifying and addressing operational challenges encountered during SRv6 deployments. Additionally, developing operational guidelines to ensure secure, reliable, efficient, and scalable SRv6 network operations. ## Scope: The SRv6OPS WG is dedicated to creating informational documents that provide deployment guidance, address operational issues, and identify gaps. The development of protocols and protocol extensions is beyond the scope of the SRv6OPS WG. The chairs of the SRv6OPS WG will consult with the responsible Area Director (AD) before adopting documents that discuss operational considerations and guidance for SRv6-related technologies still under development in other WGs (such as SPRING and 6MAN). Presentations on relevant operational topics and discussions aimed at gathering feedback from the operator community deploying SRv6 are encouraged. The SRv6OPS WG scope includes: * Operational Issues and Requirements: Addressing IPv6 address planning for SRv6 Segment Identifiers (SIDs), protection, inter-domain, and interworking with other technologies. The WG may choose not to publish requirements as an RFC, but maintain them in a draft form or a collaborative WG space. * Deployment Scenarios: Discussing operational considerations for various network environments and use cases. * SRv6 Network Management Guidance: Providing insights on configuration, observability, service assurance, and performance optimization. ## Key Deliverables: The SRv6OPS WG will focus on the following items: * Documenting operational or management issues encountered during SRv6 deployment. * Documenting SRv6 deployment experiences, including different deployment scenarios (metro, core, and enterprise networks), scalability, and inter-domain implementations. * Providing recommendations and guidance for various aspects such as IPv6 address planning, block size allocation, and the division of global/local identifiers block (GIB/LIB) for SRv6 SIDs, both with and without SRv6 compression techniques. * Providing SRv6 network management guidance for configuration, automation, and performance optimization. * Developing SRv6 network observability guidance for service assurance and troubleshooting. ## Relationships with Other WGs: The SRv6OPS WG will cooperate with other WGs as necessary. Key interactions include (but are not limited to): * SPRING WG: Close cooperation on SRv6 protocol extensions, new requirements, and operational considerations. * V6OPS WG: Cooperation on operational guidance and addressing deployment challenges. * 6MAN WG: Cooperation on core IPv6 functionalities, requirements, and operational considerations. * BESS WG: Cooperation on SRv6-based protocol extensions for BGP-enabled services, new service transport requirements, and operational considerations. * IDR WG: Cooperation on SRv6-based BGP extensions, new SRv6-based attributes and encodings, and operational considerations. * PCE WG: Cooperation on SRv6-based PCEP extensions, new SRv6-based attributes and encodings, and operational considerations. * LSR WG: Cooperation on SRv6-based IGP protocol extensions, new SRv6-based attributes and encodings, and operational considerations. The chairs will ensure that Working Group Last Call (WGLC) and Adoption notices are cross-posted to the relevant WGs. Goals and Milestones: Dec 2024 - Adopt a document describing operational and management issues encountered during SRv6 network deployment. Mar 2025 - Adopt a document describing SRv6 network deployment scenarios and related operational considerations. Mar 2025 - Adopt a document that makes SRv6 operational recommendations. Internet-Drafts: No Requests for Comments IPv6 Operations (v6ops) ----------------------- Charter Last Modified: 2024-08-06 Current Status: Active Chairs: Nick Buraglio Ron Bonica XiPeng Xiao Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari Operations and Management Area Advisor: Warren Kumari Tech Advisor: Fred Baker Mailing Lists: General Discussion: v6ops@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/v6ops Archive: https://mailarchive.ietf.org/arch/browse/v6ops/ Description of Working Group: The global deployment of IPv6 is underway, creating an Internet consisting of IPv4-only, IPv6-only, IPv4-IPv6 dual-stack, and IPv6+translation networks and nodes. This deployment must be properly handled to avoid the division of the Internet into separate IPv4 and IPv6 networks, ensuring addressing and connectivity for all IPv4 and IPv6 nodes. IPv6 deployment has resulted in the shutdown of IPv4 in some networks. Removing IPv4 constraints has resulted in innovations in IPv6 network operations. The IPv6 Operations Working Group (v6ops) develops guidelines for the deployment and operation of new and existing IPv6 networks. The goals of the v6ops working group are: 1. Solicit input from network operators and users to identify operational issues with IPv6 networks, and determine solutions or workarounds to those issues. 2. Solicit input from network operators and users to identify operational interaction issues with the IPv4 networks, and determine solutions or workarounds to those issues. 3. Solicit discussion and documentation of the issues and opportunities in IPv6-only operation, and of the resulting innovations. 4. Operational solutions for identified issues should be developed in v6ops and documented in informational or BCP drafts. 5. Document operational requirements for IPv6 networks. These documents should document IPv6 operational experience, including interactions with IPv4, in dual stack networks, IPv6 networks with IPv4 delivered as an overlay or translation service, or IPv6-only networks. 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 Working Group 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 Working Group 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 Working Group to work on a particular work item. If there is no longer sufficient interest in the Working Group in a work item, the item may be removed from the list of Working Group items. Goals and Milestones: Dec 2024 - Publish dhcp-pd, hbh, nd-considerations, rfc3849-update as RFCs Jul 2025 - Publishing deployment and operations guidelines for IPv6-mostly Dec 2025 - Update IPv6 CPE requirements (rfc7084-update) Jul 2026 - Identify IPv6 issues that prevent H.E. from selecting IPv6 for Dual-Stack users, and publish operational solutions Jul 2026 - Solicit IPv6-only deployment cases and publish BCP for IPv6-only Dec 2026 - Publish BCP for enterprise IPv6 deployment Dec 2026 - Identify issues that prevent IPv6 traffic from becoming majority, and publish guidelines Done - File recommendation on how to build a commercial WiFi network Done - Prefix for use by IPv4/IPv6 translators in a network Done - Update RFC 7084 (IPv6 CE Requirements) Done - Update RFC 6555 with experience Done - Recommendations regarding the use of DNS64 Internet-Drafts: - SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments [draft-anderson-v6ops-siit-dc-01] (30 pages) - SIIT-DC: Dual Translation Mode [draft-anderson-v6ops-siit-dc-2xlat-00] (8 pages) - Use of the IPv6 Flow Label for WLCG Packet Marking [draft-cc-v6ops-wlcg-flow-label-marking-03] (16 pages) - Expanding the IPv6 Documentation Space [draft-ghnb-v6ops-rfc3849-update-00] (4 pages) - IPv6 Address Assignment to End Sites [draft-ietf-v6ops-3177bis-end-sites-01] (9 pages) - Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks [draft-ietf-v6ops-3gpp-analysis-11] (24 pages) - Transition Scenarios for 3GPP Networks [draft-ietf-v6ops-3gpp-cases-03] (12 pages) - IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS) [draft-ietf-v6ops-3gpp-eps-08] (36 pages) - 464XLAT: Combination of Stateful and Stateless Translation [draft-ietf-v6ops-464xlat-10] (14 pages) - 464XLAT/MAT-T Optimization [draft-ietf-v6ops-464xlat-optimization-04] (24 pages) - Basic Requirements for IPv6 Customer Edge Routers [draft-ietf-v6ops-6204bis-12] (21 pages) - Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link [draft-ietf-v6ops-64share-10] (10 pages) - Advisory Guidelines for 6to4 Deployment [draft-ietf-v6ops-6to4-advisory-02] (20 pages) - Security Considerations for 6to4 [draft-ietf-v6ops-6to4-security-04] (41 pages) - Deprecating the Anycast Prefix for 6to4 Relay Routers [draft-ietf-v6ops-6to4-to-historic-11] (10 pages) - IPv6 Deployment Scenarios in 802.16 Networks [draft-ietf-v6ops-802-16-deployment-scenarios-07] (16 pages) - IPv6 Unicast Address Assignment Considerations [draft-ietf-v6ops-addcon-10] (35 pages) - Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules [draft-ietf-v6ops-addr-select-ps-09] (17 pages) - Requirements for Address Selection Mechanisms [draft-ietf-v6ops-addr-select-req-07] (7 pages) - Application Aspects of IPv6 Transition [draft-ietf-v6ops-application-transition-03] (33 pages) - Goals for Registered Assisted Tunneling [draft-ietf-v6ops-assisted-tunneling-requirements-01] (14 pages) - Balanced Security for IPv6 Residential CPE [draft-ietf-v6ops-balanced-ipv6-security-01] (9 pages) - ISP IPv6 Deployment Scenarios in Broadband Access Networks [draft-ietf-v6ops-bb-deployment-scenarios-05] (81 pages) - IPv6 Campus Transition Scenario Description and Analysis [draft-ietf-v6ops-campus-transition-01] (28 pages) - IPv6 Prefix Length Recommendation for Forwarding [draft-ietf-v6ops-cidr-prefix-03] (6 pages) - IPv4 Service Continuity Prefix [draft-ietf-v6ops-clatip-04] (4 pages) - 464XLAT Customer-side Translator (CLAT): Node Recommendations [draft-ietf-v6ops-claton-00] (15 pages) - Using Conditional Router Advertisements for Enterprise Multihoming [draft-ietf-v6ops-conditional-ras-08] (21 pages) - IPv6 CE Routers LAN Prefix Delegation [draft-ietf-v6ops-cpe-lan-pd-04] (7 pages) - Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service [draft-ietf-v6ops-cpe-simple-security-16] (36 pages) - Improving the Reaction of Customer Edge Routers to IPv6 Renumbering Events [draft-ietf-v6ops-cpe-slaac-renum-08] (11 pages) - IPv6 Operational Guidelines for Datacenters [draft-ietf-v6ops-dc-ipv6-01] (22 pages) - Routing-Related Design Choices for IPv6 Networks [draft-ietf-v6ops-design-choices-12] (26 pages) - Using DHCPv6-PD to Allocate Unique IPv6 Prefix per Client in Large Broadcast Networks [draft-ietf-v6ops-dhcp-pd-per-device-08] (22 pages) - DHCPv6/SLAAC Interaction Problems on Address and DNS Configuration [draft-ietf-v6ops-dhcpv6-slaac-problem-07] (23 pages) - IPv6 Enterprise Network Analysis - IP Layer 3 Focus [draft-ietf-v6ops-ent-analysis-07] (32 pages) - Enterprise IPv6 Deployment Guidelines [draft-ietf-v6ops-enterprise-incremental-ipv6-06] (34 pages) - IPv6 Enterprise Networks Scenarios [draft-ietf-v6ops-entnet-scenarios-00] (17 pages) - IPv6 Enterprise Network Scenarios [draft-ietf-v6ops-ent-scenarios-05] (17 pages) - Framework of Multi-domain IPv6-only Underlay Network and IPv4-as-a-Service [draft-ietf-v6ops-framework-md-ipv6only-underlay-07] (22 pages) - Happy Eyeballs: Success with Dual-Stack Hosts [draft-ietf-v6ops-happy-eyeballs-07] (15 pages) - Operational Issues with Processing of the Hop-by-Hop Options Header [draft-ietf-v6ops-hbh-10] (13 pages) - Host Address Availability Recommendations [draft-ietf-v6ops-host-addr-availability-07] (15 pages) - Best Current Practice for Filtering ICMPv6 Messages in Firewalls [draft-ietf-v6ops-icmpv6-filtering-bcp-01] (34 pages) - Recommendations for Filtering ICMPv6 Messages in Firewalls [draft-ietf-v6ops-icmpv6-filtering-recs-03] (38 pages) - IPv6 Guidance for Internet Content Providers and Application Service Providers [draft-ietf-v6ops-icp-guidance-05] (24 pages) - An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition [draft-ietf-v6ops-incremental-cgn-03] (13 pages) - Using IPsec to Secure IPv6-in-IPv4 Tunnels [draft-ietf-v6ops-ipsec-tunnels-05] (23 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Standards [draft-ietf-v6ops-ipv4survey-00] (0 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-apps-04] (50 pages) - Survey of IPv4 Addresses in Currently Deployed IETF General Area Standards [draft-ietf-v6ops-ipv4survey-gen-00] (0 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-int-03] (49 pages) - Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-intro-06] (10 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-ops-05] (43 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-routing-03] (15 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-sec-04] (25 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-subip-04] (6 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-trans-05] (31 pages) - Basic Requirements for IPv6 Customer Edge Routers [draft-ietf-v6ops-ipv6-cpe-router-09] (17 pages) - Advanced Requirements for IPv6 Customer Edge Routers [draft-ietf-v6ops-ipv6-cpe-router-bis-01] (15 pages) - IPv6 Deployment Status [draft-ietf-v6ops-ipv6-deployment-10] (37 pages) - A Discard Prefix for IPv6 [draft-ietf-v6ops-ipv6-discard-prefix-05] (6 pages) - Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World [draft-ietf-v6ops-ipv6-ehs-in-real-world-02] (15 pages) - Operational Implications of IPv6 Packets with Extension Headers [draft-ietf-v6ops-ipv6-ehs-packet-drops-08] (17 pages) - IPv6 Multihoming without Network Address Translation [draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06] (22 pages) - IPv6-only Capable Resolvers Utilising NAT64 [draft-ietf-v6ops-ipv6-only-resolver-00] (9 pages) - Analysis of Failure Cases in IPv6 Roaming Scenarios [draft-ietf-v6ops-ipv6-roaming-analysis-07] (19 pages) - Requirements for IPv6 Routers [draft-ietf-v6ops-ipv6rtr-reqs-04] (32 pages) - Emerging Service Provider Scenarios for IPv6 Deployment [draft-ietf-v6ops-isp-scenarios-00] (23 pages) - Scenarios and Analysis for Introducing IPv6 into ISP Networks [draft-ietf-v6ops-isp-scenarios-analysis-03] (28 pages) - Stateless Source Address Mapping for ICMPv6 Packets [draft-ietf-v6ops-ivi-icmp-address-07] (6 pages) - Basic Transition Mechanisms for IPv6 Hosts and Routers [draft-ietf-v6ops-mech-v2-07] (27 pages) - Monitoring Dual Stack/IPv6-only Networks and Services [draft-ietf-v6ops-monitor-ds-ipv6-00] (10 pages) - IPv6 Multihoming without Network Address Translation [draft-ietf-v6ops-multihoming-without-nat66-00] (19 pages) - Local Network Protection for IPv6 [draft-ietf-v6ops-nap-06] (36 pages) - Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks [draft-ietf-v6ops-nat64-deployment-08] (38 pages) - NAT64 Deployment Options and Experience [draft-ietf-v6ops-nat64-experience-10] (22 pages) - IPv4/IPv6 Coexistence and Transition: Requirements for solutions [draft-ietf-v6ops-nat64-pb-statement-req-00] (17 pages) - NAT64/DNS64 detection via SRV Records [draft-ietf-v6ops-nat64-srv-00] (8 pages) - Reasons to Move NAT-PT to Experimental [draft-ietf-v6ops-natpt-to-exprmntl-03] (25 pages) - Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status [draft-ietf-v6ops-natpt-to-historic-00] (25 pages) - Neighbor Cache Entries on First-Hop Routers: Operational Considerations [draft-ietf-v6ops-nd-cache-init-05] (12 pages) - Neighbor Discovery Considerations in IPv6 Deployments [draft-ietf-v6ops-nd-considerations-05] (25 pages) - IPv6 Neighbor Discovery On-Link Assumption Considered Harmful [draft-ietf-v6ops-onlinkassumption-04] (8 pages) - Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB)) [draft-ietf-v6ops-pmtud-ecmp-problem-06] (9 pages) - IPv6 Router Advertisement Guard [draft-ietf-v6ops-ra-guard-08] (10 pages) - Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) [draft-ietf-v6ops-ra-guard-implementation-07] (13 pages) - Reducing Energy Consumption of Router Advertisements [draft-ietf-v6ops-reducing-ra-energy-consumption-03] (6 pages) - Procedures for Renumbering an IPv6 Network without a Flag Day [draft-ietf-v6ops-renumbering-procedure-05] (22 pages) - IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts [draft-ietf-v6ops-rfc3316bis-06] (20 pages) - Special-Use IPv6 Addresses [draft-ietf-v6ops-rfc3330-for-ipv6-04] (7 pages) - Expanding the IPv6 Documentation Space [draft-ietf-v6ops-rfc3849-update-05] (4 pages) - Happy Eyeballs Version 2: Better Connectivity Using Concurrency [draft-ietf-v6ops-rfc6555bis-07] (15 pages) - Basic Requirements for IPv6 Customer Edge Routers [draft-ietf-v6ops-rfc7084-bis-04] (31 pages) - Rogue IPv6 Router Advertisement Problem Statement [draft-ietf-v6ops-rogue-ra-02] (16 pages) - IPv6 Routing Policies Guidelines [draft-ietf-v6ops-routing-guidelines-01] (8 pages) - IPv6 Implications for Network Scanning [draft-ietf-v6ops-scanning-implications-04] (13 pages) - IPv6 Transition/Co-existence Security Considerations [draft-ietf-v6ops-security-overview-06] (41 pages) - SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments [draft-ietf-v6ops-siit-dc-03] (24 pages) - Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode [draft-ietf-v6ops-siit-dc-2xlat-02] (17 pages) - Explicit Address Mappings for Stateless IP/ICMP Translation [draft-ietf-v6ops-siit-eam-03] (19 pages) - Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events [draft-ietf-v6ops-slaac-renum-05] (11 pages) - Teredo Security Concerns [draft-ietf-v6ops-teredo-security-concerns-02] (20 pages) - Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service (IPv4aaS) [draft-ietf-v6ops-transition-comparison-04] (27 pages) - Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service [draft-ietf-v6ops-transition-ipv4aas-15] (21 pages) - Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations [draft-ietf-v6ops-tunnel-loops-07] (19 pages) - Security Concerns with IP Tunneling [draft-ietf-v6ops-tunnel-security-concerns-04] (20 pages) - Unintended Operational Issues With ULA [draft-ietf-v6ops-ula-02] (8 pages) - Considerations For Using Unique Local Addresses [draft-ietf-v6ops-ula-usage-considerations-04] (13 pages) - Considerations For Using Unique Local Addresses [draft-ietf-v6ops-ula-usage-recommendations-05] (16 pages) - Unique IPv6 Prefix per Host [draft-ietf-v6ops-unique-ipv6-prefix-per-host-13] (10 pages) - Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks [draft-ietf-v6ops-unmaneval-03] (19 pages) - Unmanaged Networks IPv6 Transition Scenarios [draft-ietf-v6ops-unman-scenarios-03] (20 pages) - Framework for IP Version Transition Scenarios [draft-ietf-v6ops-v4v6tran-framework-02] (7 pages) - Local-Use IPv4/IPv6 Translation Prefix [draft-ietf-v6ops-v4v6-xlat-prefix-02] (7 pages) - Considerations for Transitioning Content to IPv6 [draft-ietf-v6ops-v6-aaaa-whitelisting-implications-11] (27 pages) - IPv6 Deployment in Internet Exchange Points (IXPs) [draft-ietf-v6ops-v6inixp-09] (10 pages) - Mobile Networks Considerations for IPv6 Deployment [draft-ietf-v6ops-v6-in-mobile-networks-05] (17 pages) - Operational Neighbor Discovery Problems [draft-ietf-v6ops-v6nd-problems-05] (12 pages) - Issues with Dual Stack IPv6 on by Default [draft-ietf-v6ops-v6onbydefault-03] (14 pages) - Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks [draft-ietf-v6ops-vlan-usage-01] (11 pages) - Wireline Incremental IPv6 [draft-ietf-v6ops-wireline-incremental-ipv6-06] (29 pages) - Neighbor Cache Entries on First-Hop Routers: Operational Considerations [draft-linkova-v6ops-nd-cache-init-01] (13 pages) - IPv6-Mostly Networks: Deployment and Operations Considerations [draft-link-v6ops-6mops-01] (19 pages) - 464 Customer-side Translator (CLAT): Node Recommendations [draft-link-v6ops-claton-03] (14 pages) - Pros and Cons of IPv6 Transition Technologies for IPv4aaS [draft-lmhp-v6ops-transition-comparison-06] (28 pages) - IPv6-only Capable Resolvers Utilising NAT64 [draft-momoka-v6ops-ipv6-only-resolver-02] (9 pages) - 464XLAT Optimization [draft-palet-v6ops-464xlat-opt-cdn-caches-04] (17 pages) - IPv6 Deployment Status [draft-vf-v6ops-ipv6-deployment-02] (30 pages) - IPv6 CE Routers LAN Prefix Delegation [draft-winters-v6ops-cpe-lan-pd-05] (7 pages) - Basic Requirements for IPv6 Customer Edge Routers [draft-winters-v6ops-rfc7084bis-03] (20 pages) Requests for Comments: RFC3574: Transition Scenarios for 3GPP Networks (12 pages) RFC3750: Unmanaged Networks IPv6 Transition Scenarios (20 pages) RFC3789: Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents (10 pages) RFC3790: Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents (49 pages) RFC3791: Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents (15 pages) RFC3792: Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents (25 pages) RFC3793: Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Track and Experimental Documents (6 pages) RFC3794: Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents (31 pages) RFC3795: Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents (50 pages) RFC3796: Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Track and Experimental Documents (43 pages) RFC3904: Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks (19 pages) RFC3964: Security Considerations for 6to4 (41 pages) RFC4029: Scenarios and Analysis for Introducing IPv6 into ISP Networks (28 pages) RFC4038: Application Aspects of IPv6 Transition (33 pages) RFC4057: IPv6 Enterprise Network Scenarios (17 pages) RFC4192: Procedures for Renumbering an IPv6 Network without a Flag Day (22 pages) RFC4213: Basic Transition Mechanisms for IPv6 Hosts and Routers (27 pages) RFC4215: Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks (24 pages) RFC4554: Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks (11 pages) RFC4779: ISP IPv6 Deployment Scenarios in Broadband Access Networks (81 pages) RFC4852: IPv6 Enterprise Network Analysis - IP Layer 3 Focus (32 pages) RFC4864: Local Network Protection for IPv6 (36 pages) RFC4890: Recommendations for Filtering ICMPv6 Messages in Firewalls (38 pages) RFC4891: Using IPsec to Secure IPv6-in-IPv4 Tunnels (23 pages) RFC4942: IPv6 Transition/Co-existence Security Considerations (41 pages) RFC4943: IPv6 Neighbor Discovery On-Link Assumption Considered Harmful (8 pages) RFC4966: Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status (25 pages) RFC5156: Special-Use IPv6 Addresses (7 pages) * Obsoletes RFC6890 RFC5157: IPv6 Implications for Network Scanning (13 pages) * Obsoletes RFC7707 RFC5181: IPv6 Deployment Scenarios in 802.16 Networks (16 pages) RFC5220: Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules (17 pages) RFC5221: Requirements for Address Selection Mechanisms (7 pages) RFC5375: IPv6 Unicast Address Assignment Considerations (35 pages) RFC5963: IPv6 Deployment in Internet Exchange Points (IXPs) (10 pages) RFC6036: Emerging Service Provider Scenarios for IPv6 Deployment (23 pages) * Obsoletes RFC9386 RFC6092: Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service (36 pages) RFC6104: Rogue IPv6 Router Advertisement Problem Statement (16 pages) RFC6105: IPv6 Router Advertisement Guard (10 pages) * Updates RFC7113 RFC6169: Security Concerns with IP Tunneling (20 pages) RFC6177: IPv6 Address Assignment to End Sites (9 pages) RFC6204: Basic Requirements for IPv6 Customer Edge Routers (17 pages) * Obsoletes RFC7084 RFC6264: An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition (13 pages) RFC6312: Mobile Networks Considerations for IPv6 Deployment (17 pages) * Obsoletes RFC6342 RFC6324: Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations (19 pages) RFC6342: Mobile Networks Considerations for IPv6 Deployment (17 pages) RFC6343: Advisory Guidelines for 6to4 Deployment (20 pages) RFC6459: IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS) (36 pages) RFC6555: Happy Eyeballs: Success with Dual-Stack Hosts (15 pages) * Obsoletes RFC8305 RFC6583: Operational Neighbor Discovery Problems (12 pages) RFC6589: Considerations for Transitioning Content to IPv6 (27 pages) RFC6666: A Discard Prefix for IPv6 (6 pages) RFC6782: Wireline Incremental IPv6 (29 pages) RFC6791: Stateless Source Address Mapping for ICMPv6 Packets (6 pages) RFC6877: 464XLAT: Combination of Stateful and Stateless Translation (14 pages) RFC6883: IPv6 Guidance for Internet Content Providers and Application Service Providers (24 pages) RFC7066: IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts (20 pages) RFC7084: Basic Requirements for IPv6 Customer Edge Routers (21 pages) * Updates RFC9096 RFC7113: Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) (13 pages) RFC7157: IPv6 Multihoming without Network Address Translation (22 pages) RFC7269: NAT64 Deployment Options and Experience (22 pages) RFC7278: Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link (10 pages) RFC7335: IPv4 Service Continuity Prefix (4 pages) RFC7381: Enterprise IPv6 Deployment Guidelines (34 pages) RFC7445: Analysis of Failure Cases in IPv6 Roaming Scenarios (19 pages) RFC7526: Deprecating the Anycast Prefix for 6to4 Relay Routers (10 pages) RFC7608: IPv6 Prefix Length Recommendation for Forwarding (6 pages) RFC7690: Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB)) (9 pages) RFC7755: SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments (24 pages) RFC7756: Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode (17 pages) RFC7757: Explicit Address Mappings for Stateless IP/ICMP Translation (19 pages) RFC7772: Reducing Energy Consumption of Router Advertisements (6 pages) RFC7872: Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World (15 pages) RFC7934: Host Address Availability Recommendations (15 pages) RFC8215: Local-Use IPv4/IPv6 Translation Prefix (7 pages) RFC8273: Unique IPv6 Prefix per Host (10 pages) RFC8305: Happy Eyeballs Version 2: Better Connectivity Using Concurrency (15 pages) RFC8475: Using Conditional Router Advertisements for Enterprise Multihoming (21 pages) RFC8585: Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service (21 pages) RFC8683: Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks (38 pages) RFC8978: Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events (11 pages) RFC9096: Improving the Reaction of Customer Edge Routers to IPv6 Renumbering Events (11 pages) RFC9098: Operational Implications of IPv6 Packets with Extension Headers (17 pages) RFC9313: Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service (IPv4aaS) (27 pages) RFC9386: IPv6 Deployment Status (37 pages) RFC9637: Expanding the IPv6 Documentation Space (5 pages) Babel routing protocol (babel) ------------------------------ Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Donald E. Eastlake 3rd Russ White Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Gunter Van de Velde Mailing Lists: General Discussion: babel@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/babel Archive: https://mailarchive.ietf.org/arch/browse/babel/ Description of Working Group: Babel is a loop-avoiding, distance vector routing protocol with good provisions for dynamically computed link metrics. The core of the Babel protocol and security extensions are described in Experimental Independent Stream RFCs 6126, 7557, and 7298. These RFCs are the basis of three independent, open source implementations. There is some production deployment of these implementations, notably in hybrid networks (networks that include classical, wired parts with meshy radio bits) and in global overlay networks (networks built out of large numbers of tunnels spanning continents). The Working Group will focus on moving the Babel protocol to IETF Proposed Standard with IETF review. This includes clarifying RFC 6126 and integrating RFC 7557 and feedback provided by independent implementations, and resolving comments. It is not a requirement that the Babel protocol produced is backwards compatible with RFC 6126. It is a requirement that Babel support at least one profile that is auto-configuring. Other documents that are relevant to the above work can also be produced. Particular emphasis will be placed on work needed for a Proposed Standard routing protocol, such as ensuring manageability and strong security. Link metric measurement or link metric calculation procedures significantly more complex that those currently in Babel are out of scope. The Babel WG should coordinate with other Working Groups, such as the HOMENET WG for likely applicability, the RTGWG and V6OPS WG about Source-Specific Routing to support IPv6 multihoming, the PIM WG for discussion around multicast, and the MANET WG for considerations around wireless. The Babel WG should liaise as necessary with the Broadband Forum to facilitate use of the Babel Information Model for TR-069. Work Items: - Produce a revision of RFC 6126 suitable for publication as a Proposed Standard -- incorporate in the revision developments since RFC 6126 -- resolve technical issues found -- include in the base specification the extensibility work in RFC 7557 -- support auto-configuration -- consider any important changes based on experience with Babel to date. - Address security needs for BABEL. This may include using the techniques in RFC 7298, or other alternatives. Security may be included in the base spec or the base spec may normatively reference a separate Proposed Standard specification. This is required as part of moving Babel to Proposed Standard. - Address manageability of Babel by producing a Babel informational model to help provide guidance and derive the data models. This information model is useful as a common source of information for the case where the Customer-Premise Equipment (CPE) is managed by the Service Provider (SP) with the Broadband Forum TR-069 protocol and its associated data model. To be consistent with the ongoing effort to use YANG data models in the Routing Area, a Babel YANG data model should be specified to support management of Babel routers. - As the Proposed Standard version of Babel is completed, an Applicability Statement should be finalized to guide those potentially interested in deploying Babel. This Applicability Statement may include deployment advice and will be published as an RFC. - The Working Group should document its ongoing implementation experience with Babel, so that new WG participants can understand the state that is driving this work and the experience driving changes. This documentation may be on the Working Group's wiki, in an internet-draft that isn't expected to be published as an RFC, or a combination. - As a non-primary focus, the Working Group may work on multicast aspects of Babel. This may include discussion of any potential issues for supporting Babel running with PIM-SM in an auto-configuration profile. It may include exploring Babel carrying separate metrics for multicast. It may include discussion and consultation with the PIM WG about Babel providing the ability to build multicast routing tables. With AD and WG agreement, once an approach is understood, then a milestone may be added for an associated document targeted as Proposed Standard. - As a non-primary focus, the Working Group may work on documents defining source specific routing extensions for Babel as a way of handling IPv6 multihoming. Goals and Milestones: Done - WG adoption of RFC6126bis Done - WG adoption of Babel Applicability draft Done - WG adoption of Babel Management (Info Model & YANG Model) draft Done - IESG Submission of Babel Applicability draft (Informational) Done - IESG Submission of Babel Information Model draft (Proposed Standard) Done - IESG Submission of RFC6126bis and potentially companion security mechanisms draft (Proposed Standard) Done - IESG Submission of source specific Babel draft (Proposed Standard) Done - IESG Submission of Babel Management draft (Proposed Standard) Done - IESG submission of IPv4 via IPv6 Internet-Drafts: - Source-Specific Routing in Babel [draft-boutier-babel-source-specific-03] (11 pages) - Applicability of the Babel Routing Protocol [draft-ietf-babel-applicability-10] (10 pages) - Babel Routing Protocol over Datagram Transport Layer Security [draft-ietf-babel-dtls-10] (9 pages) - MAC Authentication for the Babel Routing Protocol [draft-ietf-babel-hmac-12] (17 pages) - Babel Information Model [draft-ietf-babel-information-model-14] (20 pages) - Relaxed Packet Counter Verification for Babel MAC Authentication [draft-ietf-babel-mac-relaxed-05] (8 pages) - The Babel Routing Protocol [draft-ietf-babel-rfc6126bis-20] (54 pages) - Delay-based Metric Extension for the Babel Routing Protocol [draft-ietf-babel-rtt-extension-07] (14 pages) - Source-Specific Routing in the Babel Routing Protocol [draft-ietf-babel-source-specific-08] (13 pages) - IPv4 Routes with an IPv6 Next Hop in the Babel Routing Protocol [draft-ietf-babel-v4viav6-08] (9 pages) - YANG Data Model for Babel [draft-ietf-babel-yang-model-13] (44 pages) - Babel HMAC Cryptographic Authentication [draft-ovsienko-babel-rfc7298bis-00] (55 pages) Requests for Comments: RFC8965: Applicability of the Babel Routing Protocol (10 pages) RFC8966: The Babel Routing Protocol (54 pages) RFC8967: MAC Authentication for the Babel Routing Protocol (17 pages) * Updates RFC9467 RFC8968: Babel Routing Protocol over Datagram Transport Layer Security (9 pages) RFC9046: Babel Information Model (20 pages) RFC9079: Source-Specific Routing in the Babel Routing Protocol (13 pages) RFC9229: IPv4 Routes with an IPv6 Next Hop in the Babel Routing Protocol (9 pages) RFC9467: Relaxed Packet Counter Verification for Babel MAC Authentication (8 pages) RFC9616: Delay-Based Metric Extension for the Babel Routing Protocol (13 pages) BGP Enabled ServiceS (bess) --------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Matthew Bocci Stephane Litkowski Zhaohui (Jeffrey) Zhang Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Gunter Van de Velde Secretary: Mankamana Mishra Mailing Lists: General Discussion: bess@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/bess Archive: https://mailarchive.ietf.org/arch/browse/bess/ Description of Working Group: BGP is established as a protocol for provisioning and operating Layer-3 (routed) Virtual Private Networks (L3VPNs). It is also used in certain Layer-2 Virtual Private Networks (L2VPNs). The BGP Enabled Services (BESS) working group is responsible for defining, specifying, and extending network services based on BGP. In particular, the working group will work on the following services: - BGP/MPLS IP VPN solutions (based on RFC4364 and RFC4659) for supporting provider-provisioned L3VPNs including methods for enabling multicast over BGP/MPLS VPNs. - BGP-enabled L2VPNs (as described in RFC 4664) that operate over IP or MPLS packet switched network tunnels. All types of L2VPN are in scope provided they utilize BGP for discovery, signaling, or for some other purposes related to the VPN. But L2VPN solutions that operate over pseudowires or use LDP and that do not utilize BGP will be addressed by the PALS working group. Any contention in placement of the work between these working groups will be resolved by the chairs. - BGP-enabled VPN solutions for use in the data center networking. This work includes consideration of VPN scaling issues and mechanisms applicable to such environments. - Extensions to BGP-enabled VPN solutions for the construction of virtual topologies in support of services such as Service Function Chaining. The working group may also suggest new services to be supported by BGP and these may be added to the working group charter subject to rechartering. The working group may work on: - Mechanisms to support BGP-enabled services in the presence of multi- homing of Customer Edge (CE) devices to multiple Provider Edge (PE) devices to provide load-balancing and resilience. - Auto-discovery of sites that participate in the BGP-enabled service. - Data models for modeling, managing, and operating BGP-based services using SMI or YANG. - OAM or resiliency mechanisms operating over BGP-enabled services. But native data plane OAM mechanisms may be worked on only in conjunction with the working groups responsible for the relevant data planes. - Extensions to BGP and extensions to YANG models for BGP. All such work must be reviewed by the IDR WG, but the decision to request publication of such work remains with the BESS WG. The working group will also coordinate with other working groups where appropriate. For example, with the MPLS working group for issues related to the MPLS architecture, and the NVO3 working group for coordination of protocols to support data center VPNs. The BESS working group will not define new data plane or forwarding plane encapsulations. Goals and Milestones: Dec 2015 - Submit E-VPN OAM to IESG as PS Dec 2020 - Submit a Yang or SMI datamodel for E-VPN to IESG as PS Dec 2020 - Submit a YANG datamodel for mVPN to IESG as PS Dec 2020 - Submit a YANG datamodel for L2VPN to IESG as PS Dec 2020 - Submit a Yang or SMI datamodel for RFC4364 to IESG as PS Done - Submit specification of the BGP ACCEPT_OWN Community Attribute to IESG as PS Done - Submit specification for multicast VPN bidir P-tunnels to IESG as PS Done - Submit specifications for E-VPN to IESG as PS Done - Submit specification for extranet support in multicast VPNs to IESG as PS Done - Submit specification for the use of E-VPN for datacenter overlays to IESG as PS Done - Submit specification of a multicast VPN MIB to IESG as PS Done - Submit specifications for PBB/E-VPN interoperability to IESG as PS Done - Submit specifications for SPB-M/E-VPN interoperability to IESG as PS Done - Submit specifications for VPLS multi-homing to IESG as PS Done - Submit specification for BGP NSH controlplane to IESG as PS Internet-Drafts: - VXLAN DCI Using EVPN [draft-boutros-bess-vxlan-evpn-02] (15 pages) - VPWS support in EVPN [draft-boutros-l2vpn-evpn-vpws-06] (11 pages) - Yang Data Model for EVPN [draft-brissette-bess-evpn-yang-01] (12 pages) - Yang Data Model for BGP/MPLS L3 VPNs [draft-dhjain-bess-bgp-l3vpn-yang-02] (29 pages) - Explicit Tracking with Wild Card Routes in Multicast VPN [draft-dolganow-bess-mvpn-expl-track-02] (15 pages) - Gateway Auto-Discovery and Route Advertisement for Segment Routing Enabled Domain Interconnection [draft-drake-bess-datacenter-gateway-05] (11 pages) - BGP Usage for SDWAN Overlay Networks [draft-dunbar-bess-bgp-sdwan-usage-08] (28 pages) - Service Chaining using Virtual Networks with BGP VPNs [draft-fm-bess-service-chaining-02] (42 pages) - Inter-AS Option C between NVO3 and BGP/MPLS IP VPN network [draft-hao-bess-inter-nvo3-vpn-optionc-03] (14 pages) - BGP Based Multicast [draft-ietf-bess-bgp-multicast-08] (31 pages) - Controller Based BGP Multicast Signaling [draft-ietf-bess-bgp-multicast-controller-13] (30 pages) - BGP Usage for SD-WAN Overlay Networks [draft-ietf-bess-bgp-sdwan-usage-23] (30 pages) - SRv6 Argument Signaling for BGP Services [draft-ietf-bess-bgp-srv6-args-01] (13 pages) - Updated Processing of Control Flags for BGP Virtual Private LAN Service (VPLS) [draft-ietf-bess-bgp-vpls-control-flags-08] (9 pages) - Gateway Auto-Discovery and Route Advertisement for Site Interconnection Using Segment Routing [draft-ietf-bess-datacenter-gateway-13] (12 pages) - Interconnect Solution for Ethernet VPN (EVPN) Overlay Networks [draft-ietf-bess-dci-evpn-overlay-10] (24 pages) - Deployment Guidelines for Edge Peering IPv4-NLRI with IPv6-NH [draft-ietf-bess-deployment-guide-ipv4nlri-ipv6nh-02] (23 pages) - Cumulative DMZ Link Bandwidth and load-balancing [draft-ietf-bess-ebgp-dmz-05] (13 pages) - Requirements for Extending BGP/MPLS VPNs to End-Systems [draft-ietf-bess-end-system-requirements-00] (16 pages) - AC-Aware Bundling Service Interface in EVPN [draft-ietf-bess-evpn-ac-aware-bundling-04] (14 pages) - AC-Influenced Designated Forwarder Election for EVPN [draft-ietf-bess-evpn-ac-df-03] (10 pages) - EVPN Network Layer Fault Management [draft-ietf-bess-evpn-bfd-07] (17 pages) - Updates on EVPN BUM Procedures [draft-ietf-bess-evpn-bum-procedure-updates-14] (21 pages) - A new Designated Forwarder Election for the EVPN [draft-ietf-bess-evpn-df-election-03] (15 pages) - Framework for Ethernet VPN Designated Forwarder Election Extensibility [draft-ietf-bess-evpn-df-election-framework-09] (32 pages) - Domain Path (D-PATH) for Ethernet VPN (EVPN) Interconnect Networks [draft-ietf-bess-evpn-dpath-01] (16 pages) - Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) [draft-ietf-bess-evpn-etree-14] (23 pages) - Fast Recovery for EVPN Designated Forwarder Election [draft-ietf-bess-evpn-fast-df-recovery-10] (16 pages) - EVPN control plane for Geneve [draft-ietf-bess-evpn-geneve-08] (11 pages) - Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN) [draft-ietf-bess-evpn-igmp-mld-proxy-21] (30 pages) - Integrated Routing and Bridging in Ethernet VPN (EVPN) [draft-ietf-bess-evpn-inter-subnet-forwarding-15] (30 pages) - EVPN Support for L3 Fast Convergence and Aliasing/Backup Path [draft-ietf-bess-evpn-ip-aliasing-01] (22 pages) - EVPN Interworking with IPVPN [draft-ietf-bess-evpn-ipvpn-interworking-11] (33 pages) - Extended Mobility Procedures for EVPN-IRB [draft-ietf-bess-evpn-irb-extended-mobility-17] (26 pages) - EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding [draft-ietf-bess-evpn-irb-mcast-11] (80 pages) - EVPN Multi-Homing Mechanism for Layer-2 Gateway Protocols [draft-ietf-bess-evpn-l2gw-proto-04] (13 pages) - Label Switched Path (LSP) Ping Mechanisms for EVPN and Provider Backbone Bridging EVPN (PBB-EVPN) [draft-ietf-bess-evpn-lsp-ping-11] (17 pages) - EVPN Port-Active Redundancy Mode [draft-ietf-bess-evpn-mh-pa-10] (13 pages) - BGP EVPN Multi-Homing Extensions for Split Horizon Filtering [draft-ietf-bess-evpn-mh-split-horizon-11] (20 pages) - EVPN Interoperability Modes [draft-ietf-bess-evpn-modes-interop-02] (20 pages) - Seamless Multicast Interoperability between EVPN and MVPN PEs [draft-ietf-bess-evpn-mvpn-seamless-interop-07] (38 pages) - Propagation of ARP/ND Flags in an Ethernet Virtual Private Network (EVPN) [draft-ietf-bess-evpn-na-flags-09] (10 pages) - Framework and Requirements for Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM) [draft-ietf-bess-evpn-oam-req-frmwk-10] (16 pages) - Optimized Ingress Replication Solution for Ethernet VPN (EVPN) [draft-ietf-bess-evpn-optimized-ir-12] (34 pages) - A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN) [draft-ietf-bess-evpn-overlay-12] (33 pages) - Per multicast flow Designated Forwarder Election for EVPN [draft-ietf-bess-evpn-per-mcast-flow-df-election-10] (11 pages) - Preference-based EVPN DF Election [draft-ietf-bess-evpn-pref-df-13] (20 pages) - IP Prefix Advertisement in Ethernet VPN (EVPN) [draft-ietf-bess-evpn-prefix-advertisement-11] (31 pages) - Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private Networks [draft-ietf-bess-evpn-proxy-arp-nd-16] (22 pages) - Multicast Source Redundancy in EVPN Networks [draft-ietf-bess-evpn-redundant-mcast-source-10] (33 pages) - Weighted Multi-Path Procedures for EVPN Multi-Homing [draft-ietf-bess-evpn-unequal-lb-22] (22 pages) - Usage and Applicability of BGP MPLS-Based Ethernet VPN [draft-ietf-bess-evpn-usage-09] (31 pages) - EVPN Virtual Ethernet Segment [draft-ietf-bess-evpn-virtual-eth-segment-15] (24 pages) - Virtual Hub-and-Spoke in BGP EVPNs [draft-ietf-bess-evpn-virtual-hub-00] (16 pages) - Seamless Integration of Ethernet VPN (EVPN) with Virtual Private LAN Service (VPLS) and Their Provider Backbone Bridge (PBB) Equivalents [draft-ietf-bess-evpn-vpls-seamless-integ-07] (16 pages) - Virtual Private Wire Service Support in Ethernet VPN [draft-ietf-bess-evpn-vpws-14] (17 pages) - EVPN VPWS Flexible Cross-Connect Service [draft-ietf-bess-evpn-vpws-fxc-08] (17 pages) - EVPN-VPWS Seamless Integration with L2VPN VPWS [draft-ietf-bess-evpn-vpws-seamless-00] (18 pages) - Yang Data Model for EVPN [draft-ietf-bess-evpn-yang-07] (28 pages) - Extended Procedures for EVPN Optimized Ingress Replication [draft-ietf-bess-extended-evpn-optimized-ir-06] (15 pages) - Extensions to BGP-Signaled Pseudowires to Support Flow-Aware Transport Labels [draft-ietf-bess-fat-pw-bgp-04] (9 pages) - IPv6-Only PE Design for IPv4-NLRI with IPv6-NH [draft-ietf-bess-ipv6-only-pe-design-04] (28 pages) - Ingress Replication Tunnels in Multicast VPN [draft-ietf-bess-ir-05] (23 pages) - L2L3 VPN Multicast MIB [draft-ietf-bess-l2l3-vpn-mcast-mib-16] (20 pages) - YANG Data Model for MPLS-based L2VPN [draft-ietf-bess-l2vpn-yang-10] (49 pages) - Yang Data Model for BGP/MPLS L3 VPNs [draft-ietf-bess-l3vpn-yang-05] (22 pages) - Multicast VPN State Damping [draft-ietf-bess-multicast-damping-06] (18 pages) - Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels [draft-ietf-bess-mvpn-bidir-04] (34 pages) - Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication [draft-ietf-bess-mvpn-bidir-ingress-replication-04] (8 pages) - MVPN/EVPN Tunnel Aggregation with Common Labels [draft-ietf-bess-mvpn-evpn-aggregation-label-14] (17 pages) - Multicast and Ethernet VPN with Segment Routing P2MP and Ingress Replication [draft-ietf-bess-mvpn-evpn-sr-p2mp-09] (20 pages) - Explicit Tracking with Wildcard Routes in Multicast VPN [draft-ietf-bess-mvpn-expl-track-13] (21 pages) - Extranet Multicast in BGP/IP MPLS VPNs [draft-ietf-bess-mvpn-extranet-07] (65 pages) - Multicast VPN Fast Upstream Failover [draft-ietf-bess-mvpn-fast-failover-15] (22 pages) - Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures [draft-ietf-bess-mvpn-global-table-mcast-03] (22 pages) - BGP/MPLS Layer 3 VPN Multicast Management Information Base [draft-ietf-bess-mvpn-mib-12] (57 pages) - Interoperation between Multicast Virtual Private Network (MVPN) and Multicast Source Directory Protocol (MSDP) Source-Active Routes [draft-ietf-bess-mvpn-msdp-sa-interoperation-08] (6 pages) - BGP as an MVPN PE-CE Protocol [draft-ietf-bess-mvpn-pe-ce-01] (12 pages) - Yang Data Model for Multicast in MPLS/BGP IP VPNs [draft-ietf-bess-mvpn-yang-05] (41 pages) - BGP Control Plane for the Network Service Header in Service Function Chaining [draft-ietf-bess-nsh-bgp-control-plane-18] (59 pages) - Covering Prefixes Outbound Route Filter for BGP-4 [draft-ietf-bess-orf-covering-prefixes-06] (21 pages) - PBB-EVPN ISID-based C-MAC-Flush [draft-ietf-bess-pbb-evpn-isid-cmacflush-09] (13 pages) - Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags [draft-ietf-bess-pta-flags-03] (7 pages) - Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop [draft-ietf-bess-rfc5549revision-06] (12 pages) - BGP MPLS-Based Ethernet VPN [draft-ietf-bess-rfc7432bis-10] (72 pages) - Secure EVPN [draft-ietf-bess-secure-evpn-00] (37 pages) - Service Function Chaining using Virtual Networks with BGP VPNs [draft-ietf-bess-service-chaining-06] (41 pages) - Support for Shortest Path Bridging MAC Mode over Ethernet VPN (EVPN) [draft-ietf-bess-spbm-evpn-02] (11 pages) - BGP Overlay Services Based on Segment Routing over IPv6 (SRv6) [draft-ietf-bess-srv6-services-15] (29 pages) - IPv4-Only and IPv6-Only PE Design DESIGN ALL SAFI [draft-ietf-bess-v4-v6-pe-all-safi-01] (54 pages) - BGP/MPLS VPN Virtual PE [draft-ietf-bess-virtual-pe-00] (25 pages) - Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension Solution [draft-ietf-bess-virtual-subnet-07] (15 pages) - FIB Reduction in Virtual Subnet [draft-ietf-bess-virtual-subnet-fib-reduction-04] (7 pages) - BGP based Multi-homing in Virtual Private LAN Service [draft-ietf-bess-vpls-multihoming-05] (21 pages) - Weighted HRW and its applications [draft-ietf-bess-weighted-hrw-00] (11 pages) - Shortest Path Bridging, MAC mode Support over EVPN [draft-ietf-l2vpn-spbm-evpn-02] (10 pages) - TRILL-EVPN [draft-ietf-l2vpn-trill-evpn-02] (14 pages) - BGP ACCEPT_OWN Community Attribute [draft-ietf-l3vpn-acceptown-community-10] (8 pages) - BGP-Signaled End-System IP/VPNs [draft-ietf-l3vpn-end-system-06] (31 pages) - Requirements for Extending BGP/MPLS VPNs to End-Systems [draft-ietf-l3vpn-end-system-requirements-00] (16 pages) - MVPN: Using Bidirectional P-Tunnels [draft-ietf-l3vpn-mvpn-bidir-08] (32 pages) - Simulating "Partial Mesh of MP2MP P-Tunnels" with Ingress Replication [draft-ietf-l3vpn-mvpn-bidir-ingress-replication-01] (13 pages) - Extranet Multicast in BGP/IP MPLS VPNs [draft-ietf-l3vpn-mvpn-extranet-05] (61 pages) - Global Table Multicast with BGP-MVPN Procedures [draft-ietf-l3vpn-mvpn-global-table-mcast-00] (23 pages) - Encoding Multipoint LDP (mLDP) Forwarding Equivalence Classes (FECs) in the NLRI of BGP MCAST-VPN Routes [draft-ietf-l3vpn-mvpn-mldp-nlri-10] (10 pages) - BGP as an MVPN PE-CE Protocol [draft-ietf-l3vpn-mvpn-pe-ce-02] (13 pages) - Covering Prefixes Outbound Route Filter for BGP-4 [draft-ietf-l3vpn-orf-covering-prefixes-02] (19 pages) - Virtual Subnet: A L3VPN-based Subnet Extension Solution [draft-ietf-l3vpn-virtual-subnet-03] (14 pages) - Virtual Hub-and-Spoke in BGP EVPNs [draft-keyupate-bess-evpn-virtual-hub-02] (16 pages) - Extensions to BGP Signaled Pseudowires to support Flow-Aware Transport Labels [draft-keyupate-l2vpn-fat-pw-bgp-04] (8 pages) - EVPN Interoperability Modes [draft-krattiger-evpn-modes-interop-03] (21 pages) - EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding [draft-lin-bess-evpn-irb-mcast-04] (70 pages) - BGP Control Plane for NSH SFC [draft-mackie-bess-nsh-bgp-control-plane-04] (52 pages) - Weighted Multi-Path Procedures for EVPN All-Active Multi-Homing [draft-malhotra-bess-evpn-unequal-lb-04] (18 pages) - Inter-AS Option D for BGP/MPLS IP VPN [draft-mapathak-interas-ab-02] (15 pages) - A new Designated Forwarder Election for the EVPN [draft-mohanty-bess-evpn-df-election-02] (15 pages) - Multicast VPN state damping [draft-morin-bess-multicast-damping-01] (15 pages) - Multicast VPN fast upstream failover [draft-morin-bess-mvpn-fast-failover-02] (17 pages) - Multicast and Ethernet VPN with Segment Routing Point-to-Multipoint Trees [draft-parekh-bess-mvpn-evpn-sr-p2mp-02] (15 pages) - Interconnect Solution for EVPN Overlay networks [draft-rabadan-bess-dci-evpn-overlay-00] (22 pages) - AC-Influenced Designated Forwarder Election for EVPN [draft-rabadan-bess-evpn-ac-df-05] (10 pages) - Optimized Ingress Replication solution for EVPN [draft-rabadan-bess-evpn-optimized-ir-02] (24 pages) - Preference-based EVPN DF Election [draft-rabadan-bess-evpn-pref-df-02] (12 pages) - EVPN Vendor-Specific Route Type [draft-rabadan-bess-vendor-evpn-route-07] (5 pages) - IP Prefix Advertisement in EVPN [draft-rabadan-l2vpn-evpn-prefix-advertisement-03] (23 pages) - IANA Registry for P-Multicast Service Interface Tunnel Attribute Flags [draft-rosen-bess-pta-flags-00] (3 pages) - Ingress Replication Tunnels in Multicast VPN [draft-rosen-l3vpn-ir-02] (19 pages) - E-TREE Support in EVPN & PBB-EVPN [draft-sajassi-bess-evpn-etree-00] (11 pages) - IGMP and MLD Proxy for EVPN [draft-sajassi-bess-evpn-igmp-mld-proxy-01] (25 pages) - EVPN Support for L3 Fast Convergence and Aliasing/Backup Path [draft-sajassi-bess-evpn-ip-aliasing-09] (20 pages) - Per multicast flow Designated Forwarder Election for EVPN [draft-sajassi-bess-evpn-per-mcast-flow-df-election-01] (12 pages) - EVPN Virtual Ethernet Segment [draft-sajassi-bess-evpn-virtual-eth-segment-03] (22 pages) - (PBB-)EVPN Seamless Integration with (PBB-)VPLS [draft-sajassi-bess-evpn-vpls-seamless-integ-00] (10 pages) - YANG Data Model for MPLS-based L2VPN [draft-shah-bess-l2vpn-yang-01] (51 pages) - Updated processing of control flags for BGP VPLS [draft-singh-bess-bgp-vpls-control-flags-01] (8 pages) - PIM Proxy in EVPN Networks [draft-skr-bess-evpn-pim-proxy-02] (25 pages) - Multicast Source Redundancy in EVPN Networks [draft-skr-bess-evpn-redundant-mcast-source-02] (29 pages) - Loop Protection in EVPN networks [draft-snr-bess-evpn-loop-protect-04] (13 pages) - Propagation of IPv6 Neighbor Advertisement Flags in EVPN [draft-snr-bess-evpn-na-flags-07] (6 pages) - Operational Aspects of Proxy-ARP/ND in EVPN Networks [draft-snr-bess-evpn-proxy-arp-nd-02] (22 pages) - PBB-EVPN ISID-based CMAC-Flush [draft-snr-bess-pbb-evpn-isid-cmacflush-06] (10 pages) - Extended Procedures for EVPN Optimized Ingress Replication [draft-wsv-bess-extended-evpn-optimized-ir-02] (13 pages) - FIB Reduction in Virtual Subnet [draft-xu-l3vpn-virtual-subnet-fib-reduction-02] (6 pages) - Updates on EVPN BUM Procedures [draft-zzhang-bess-evpn-bum-procedure-updates-03] (16 pages) - MVPN and MSDP SA Interoperation [draft-zzhang-bess-mvpn-msdp-sa-interoperation-01] (6 pages) Requests for Comments: RFC7441: Encoding Multipoint LDP (mLDP) Forwarding Equivalence Classes (FECs) in the NLRI of BGP MCAST-VPN Routes (10 pages) RFC7543: Covering Prefixes Outbound Route Filter for BGP-4 (21 pages) RFC7582: Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels (34 pages) * Updates RFC8534 * Updates RFC9573 RFC7611: BGP ACCEPT_OWN Community Attribute (8 pages) RFC7716: Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures (22 pages) RFC7734: Support for Shortest Path Bridging MAC Mode over Ethernet VPN (EVPN) (11 pages) RFC7740: Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication (8 pages) RFC7814: Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension Solution (15 pages) RFC7899: Multicast VPN State Damping (18 pages) RFC7900: Extranet Multicast in BGP/IP MPLS VPNs (65 pages) * Updates RFC8534 RFC7902: Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags (7 pages) RFC7988: Ingress Replication Tunnels in Multicast VPN (23 pages) RFC8214: Virtual Private Wire Service Support in Ethernet VPN (17 pages) RFC8317: Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) (23 pages) RFC8365: A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN) (33 pages) RFC8388: Usage and Applicability of BGP MPLS-Based Ethernet VPN (31 pages) RFC8395: Extensions to BGP-Signaled Pseudowires to Support Flow-Aware Transport Labels (9 pages) RFC8502: L2L3 VPN Multicast MIB (20 pages) RFC8503: BGP/MPLS Layer 3 VPN Multicast Management Information Base (57 pages) RFC8534: Explicit Tracking with Wildcard Routes in Multicast VPN (21 pages) RFC8560: Seamless Integration of Ethernet VPN (EVPN) with Virtual Private LAN Service (VPLS) and Their Provider Backbone Bridge (PBB) Equivalents (16 pages) RFC8584: Framework for Ethernet VPN Designated Forwarder Election Extensibility (32 pages) RFC8614: Updated Processing of Control Flags for BGP Virtual Private LAN Service (VPLS) (9 pages) RFC8950: Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop (12 pages) RFC9014: Interconnect Solution for Ethernet VPN (EVPN) Overlay Networks (24 pages) RFC9015: BGP Control Plane for the Network Service Header in Service Function Chaining (59 pages) RFC9026: Multicast VPN Fast Upstream Failover (22 pages) RFC9047: Propagation of ARP/ND Flags in an Ethernet Virtual Private Network (EVPN) (10 pages) RFC9062: Framework and Requirements for Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM) (16 pages) RFC9081: Interoperation between Multicast Virtual Private Network (MVPN) and Multicast Source Directory Protocol (MSDP) Source-Active Routes (6 pages) RFC9125: Gateway Auto-Discovery and Route Advertisement for Site Interconnection Using Segment Routing (12 pages) RFC9135: Integrated Routing and Bridging in Ethernet VPN (EVPN) (30 pages) RFC9136: IP Prefix Advertisement in Ethernet VPN (EVPN) (31 pages) RFC9161: Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private Networks (22 pages) RFC9251: Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN) (30 pages) RFC9252: BGP Overlay Services Based on Segment Routing over IPv6 (SRv6) (29 pages) RFC9489: Label Switched Path (LSP) Ping Mechanisms for EVPN and Provider Backbone Bridging EVPN (PBB-EVPN) (17 pages) RFC9541: Flush Mechanism for Customer MAC Addresses Based on Service Instance Identifier (I-SID) in Provider Backbone Bridging EVPN (PBB-EVPN) (11 pages) RFC9572: Updates to EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Procedures (19 pages) RFC9573: MVPN/EVPN Tunnel Aggregation with Common Labels (14 pages) RFC9574: Optimized Ingress Replication Solution for Ethernet VPNs (EVPNs) (28 pages) RFC9625: EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding (63 pages) Bidirectional Forwarding Detection (bfd) ---------------------------------------- Charter Last Modified: 2022-07-23 Current Status: Active Chairs: Jeffrey Haas Reshad Rahman Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: John Scudder Tech Advisors: Dave Katz David Ward Mailing Lists: General Discussion: rtg-bfd@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/rtg-bfd Archive: https://mailarchive.ietf.org/arch/browse/rtg-bfd/ Description of Working Group: The BFD Working Group is chartered to standardize and support the bidirectional forwarding detection protocol (BFD) and its extensions. A core goal of the working group is to standardize BFD in the context of IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations. The Working Group will also provide advice and guidance on BFD to other working groups or standards bodies as requested. BFD is a protocol intended to detect faults in the bidirectional path between two forwarding engines, including physical interfaces, subinterfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of detection times and overhead, to avoid a proliferation of different methods. Important characteristics of BFD include: - Simple, fixed-field encoding to facilitate implementations in hardware. - Independence of the data protocol being forwarded between two systems. BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network. - Path independence: BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS LSPs, multihop routed paths, and unidirectional links (so long as there is some return path, of course). - Ability to be bootstrapped by any other protocol that automatically forms peer, neighbor or adjacency relationships to seed BFD endpoint discovery. The working group is currently chartered to complete the following work items: 1. Develop further MIB modules for BFD and submit them to the IESG for publication as Proposed Standards. 2a. Provide a generic keying-based cryptographic authentication mechanism for the BFD protocol developing the work of the KARP working group. This mechanism will support authentication through a key identifier for the BFD session's Security Association rather than specifying new authentication extensions. 2b. Provide extensions to the BFD MIB in support of the generic keying- based cryptographic authentication mechanism. 2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check value but not beyond commonly accepted lengths to ensure security) using the generic keying-based cryptographic authentication mechanism. 3. Provide an extension to the BFD core protocol in support of point-to- multipoint links and networks. 4. Provide an informational document to recommend standardized timers and timer operations for BFD when used in different applications. 5. Define a mechanism to perform single-ended path (i.e. continuity) verification based on the BFD specification. Allow such a mechanism to work both proactively and on-demand, without prominent initial delay. Allow the mechanism to maintain multiple sessions to a target entity and between the same pair of network entities. In doing this work, the WG will work closely with at least the following other WGs: ISIS, OSPF, SPRING. The working group will maintain a relationship with the MPLS working group. Goals and Milestones: Jan 2015 - Submit the cryptographic authentication procedures for BFD to the IESG to be considered as a Proposed Standard Jan 2015 - Submit the generic keying based cryptographic authentication mechanism to the IESG to be considered as a Proposed Standard Done - Submit the base protocol specification to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for MPLS LSPs to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for single-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for multi-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Done - Submit the BFD MIB to the IESG to be considered as a Proposed Standard Done - Submit the BFD over LAG mechanism to the IESG to be considered as a Proposed Standard Done - Submit the BFD Seamless Use Case document to the IESG to be considered as a Proposed Standard Done - Submit the BFD Common Intervals document to the IESG to be considered as an Informational RFC Done - Submit the BFD Seamless Base draft to the IESG to be considered as a Proposed Standard Done - Submit the BFD Seamless IP draft to the IESG to be considered as a Proposed Standard Done - Submit the the document on BFD point-to-multipoint support to the IESG to be considered as a Proposed Standard Done - Submit a BFD Yang module to the IESG to be considered as a Proposed Standard Done - Submit BFD for VxLAN to the IESG to be considered as a Proposed Standard Internet-Drafts: - BFD Stability [draft-ashesh-bfd-stability-05] (6 pages) - Unsolicited BFD for Sessionless Applications [draft-chen-bfd-unsolicited-03] (6 pages) - Unaffiliated BFD Echo Function [draft-cw-bfd-unaffiliated-echo-01] (6 pages) - BFD Encapsulated in Large Packets [draft-haas-bfd-large-packets-01] (5 pages) - Bidirectional Forwarding Detection (BFD) [draft-ietf-bfd-base-11] (49 pages) - Generic Application of Bidirectional Forwarding Detection (BFD) [draft-ietf-bfd-generic-05] (17 pages) - BFD Generic Cryptographic Authentication [draft-ietf-bfd-generic-crypto-auth-06] (13 pages) - Authenticating BFD using HMAC-SHA-2 procedures [draft-ietf-bfd-hmac-sha-05] (8 pages) - Common Interval Support in Bidirectional Forwarding Detection [draft-ietf-bfd-intervals-05] (8 pages) - BFD Encapsulated in Large Packets [draft-ietf-bfd-large-packets-11] (14 pages) - Bidirectional Forwarding Detection (BFD) Management Information Base [draft-ietf-bfd-mib-22] (39 pages) - Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs) [draft-ietf-bfd-mpls-07] (12 pages) - BFD Management Information Base (MIB) extensions for MPLS and MPLS-TP Networks [draft-ietf-bfd-mpls-mib-07] (23 pages) - Bidirectional Forwarding Detection (BFD) for Multihop Paths [draft-ietf-bfd-multihop-09] (6 pages) - Bidirectional Forwarding Detection (BFD) for Multipoint Networks [draft-ietf-bfd-multipoint-19] (23 pages) - Bidirectional Forwarding Detection (BFD) Multipoint Active Tails [draft-ietf-bfd-multipoint-active-tail-10] (20 pages) - Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces [draft-ietf-bfd-on-lags-04] (11 pages) - Optimizing BFD Authentication [draft-ietf-bfd-optimizing-authentication-18] (24 pages) - Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs) [draft-ietf-bfd-rfc5884-clarifications-04] (7 pages) - YANG Data Model for Bidirectional Forwarding Detection (BFD) [draft-ietf-bfd-rfc9127-bis-04] (58 pages) - Seamless Bidirectional Forwarding Detection (S-BFD) [draft-ietf-bfd-seamless-base-11] (24 pages) - Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS [draft-ietf-bfd-seamless-ip-06] (8 pages) - Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases [draft-ietf-bfd-seamless-use-case-08] (15 pages) - Meticulous Keyed ISAAC for BFD Authentication [draft-ietf-bfd-secure-sequence-numbers-16] (20 pages) - BFD Stability [draft-ietf-bfd-stability-15] (21 pages) - Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management [draft-ietf-bfd-tc-mib-08] (11 pages) - Unaffiliated BFD Echo [draft-ietf-bfd-unaffiliated-echo-10] (12 pages) - Unsolicited Bidirectional Forwarding Detection (BFD) for Sessionless Applications [draft-ietf-bfd-unsolicited-16] (16 pages) - Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) [draft-ietf-bfd-v4v6-1hop-11] (7 pages) - Bidirectional Forwarding Detection (BFD) for Virtual eXtensible Local Area Network (VXLAN) [draft-ietf-bfd-vxlan-16] (9 pages) - YANG Data Model for Bidirectional Forwarding Detection (BFD) [draft-ietf-bfd-yang-17] (64 pages) - BFD for Multipoint Networks [draft-katz-ward-bfd-multipoint-02] (29 pages) - Optimizing BFD Authentication [draft-mahesh-bfd-authentication-01] (7 pages) - BFD in Demand Mode over a Point-to-Point MPLS LSP [draft-mirsky-bfd-mpls-demand-15] (5 pages) - Secure BFD Sequence Numbers [draft-sonal-bfd-secure-sequence-numbers-00] (5 pages) - BFD Multipoint Active Tails. [draft-spallagatti-bfd-multipoint-active-tail-00] (16 pages) - BFD for VXLAN [draft-spallagatti-bfd-vxlan-06] (10 pages) - Bidirectional Forwarding Detection (BFD) on Multi-chassis Ling Aggregation Group (MC-LAG) Interfaces in IP Networks [draft-tanmir-rtgwg-bfd-mc-lag-ip-01] (4 pages) - Bidirectional Forwarding Detection (BFD) on Multi-chassis Ling Aggregation Group (MC-LAG) Interfaces in IP/MPLS Networks [draft-tanmir-rtgwg-bfd-mc-lag-mpls-01] (5 pages) - Yang Data Model for Bidirectional Forwarding Detection (BFD) [draft-zheng-bfd-yang-04] (37 pages) Requests for Comments: RFC5880: Bidirectional Forwarding Detection (BFD) (49 pages) * Updates RFC7419 * Updates RFC7880 * Updates RFC8562 RFC5881: Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) (7 pages) RFC5882: Generic Application of Bidirectional Forwarding Detection (BFD) (17 pages) RFC5883: Bidirectional Forwarding Detection (BFD) for Multihop Paths (6 pages) RFC5884: Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs) (12 pages) * Updates RFC7726 RFC7130: Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces (11 pages) RFC7330: Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management (11 pages) RFC7331: Bidirectional Forwarding Detection (BFD) Management Information Base (39 pages) RFC7419: Common Interval Support in Bidirectional Forwarding Detection (8 pages) RFC7726: Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs) (7 pages) RFC7880: Seamless Bidirectional Forwarding Detection (S-BFD) (24 pages) RFC7881: Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS (8 pages) RFC7882: Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases (15 pages) RFC8562: Bidirectional Forwarding Detection (BFD) for Multipoint Networks (23 pages) RFC8563: Bidirectional Forwarding Detection (BFD) Multipoint Active Tails (20 pages) RFC8971: Bidirectional Forwarding Detection (BFD) for Virtual eXtensible Local Area Network (VXLAN) (9 pages) RFC9127: YANG Data Model for Bidirectional Forwarding Detection (BFD) (64 pages) * Updates RFC9314 RFC9314: YANG Data Model for Bidirectional Forwarding Detection (BFD) (58 pages) RFC9468: Unsolicited Bidirectional Forwarding Detection (BFD) for Sessionless Applications (16 pages) Bit Indexed Explicit Replication (bier) --------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Greg Shepherd Tony Przygienda Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Gunter Van de Velde Secretary: Zheng Zhang Mailing Lists: General Discussion: bier@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/bier Archive: https://mailarchive.ietf.org/arch/browse/bier/ Description of Working Group: The BIER (Bit Index Explicit Replication) Working Group has defined an architecture [RFC 8279] for multicast forwarding that uses an encapsulation [RFC 8296] that can be used on MPLS or Ethernet transport. The BIER-WG is now chartered to produce Standards Track RFCs, including the status update for RFCs 8279 and 8296. The BIER working group's original charter required the publication of an Informational RFC describing the benefits, problems, and trade-offs for using BIER instead of traditional multicast forwarding mechanisms as well as an analysis of the impact and benefit of the BIER data-plane to the overall Internet architecture. The WG did not produce this RFC, but the goals of that milestone have nevertheless been reached; i.e., the industry has demonstrated interest in deploying BIER and the trade-offs are now well understood. Therefore, BIER is proceeding with work on the Standards Track. The focus of the BIER-WG is on deployment: transition, partial deployments, applicability and management. First and primarily, the BIER-WG will complete its work on: 1) Transition Mechanisms and Partial Deployments: The WG will describe how BIER can be introduced in existing multicast networks to shift multicast delivery, either end-to-end or in part of a network, from mechanisms such as PIM, ng-MVPN, etc. BIER operation in networks where not all routers are BIER capable or have other BIER support constraints should be addressed. How to handle routers supporting BIER with different BitStringLengths and encapsulations should be addressed. Each new mechanism should include an applicability statement that clearly describes its utility and distinctions from already standardized mechanisms. 2) Applicability Statements: The WG will continue to work on documents describing how BIER can be applied, as has been done for MVPN in draft-ietf-bier-mvpn. A document describing applicability to EVPN should be published. 3) Use Case: The WG will produce one use-case document that clearly articulates the potential benefits of BIER for different use-cases. 4) Manageability and OAM: The WG will describe how OAM will work in a BIER domain and what simplifications BIER offers for managing the multicast traffic. A strong preference will be given to extensions to existing protocols. 5) Management models: The WG will work on YANG models to manage BIER. 6) Link-State Routing and BGP extensions: The BIER-WG has already defined the basic information needed to set up the BIER forwarding tables via advertisements in OSPFv2 and ISIS; the extensions to OSPFv3 will be specified. Additional extensions may be needed - for example, to support constraining the topology on which a particular BIER sub-domain operates. Any necessary extensions to the IGP will be specified by the WG as Standards Track, in cooperation with the LSR WG. The BIER-WG shall also specify the extensions to support BIER for BGP when used as an IGP (see RFC 7938) and to provide BIER-specific information in BGP-LS, in cooperation with IDR. The BIER-WG is additionally chartered to start Standards Track work on: 7) BIER in IPv6 : A mechanism to use BIER natively in IPv6 may be standardized if coordinated with the 6MAN WG and with understood applicability. 8) Forwarding Plane Mechanisms for BIER Traffic Engineering: definition of how the new BIER forwarding plane structures (e.g. BIFT) can be used to support engineered multicast trees. No control-plane work will be done in BIER-WG. The BIER-WG will serve as a forum to discuss how BIER can be applied. The BIER-WG will coordinate and collaborate with other WGs as needed. Specific expected interactions include: * mpls on the associated MPLS-based OAM mechanisms, * lsr on OSPF and ISIS extensions to flood BIER-related information, * babel on Babel extensions to support BIER, * bess and idr on BGP extensions to flood BIER-related information and the applicability of existing BGP-based mechanisms for providing multicast group membership information, * pim and mboned on the applicability of and extensions to PIM, IGMP, and MLD to support BIER operations and transition, * pce on extensions to program BIER forwarding on the BFIRs,and * teas on architecture and control-plane mechanisms to use BIER-TE forwarding mechanisms. Goals and Milestones: Mar 2018 - Published as proposed standard: draft-ietf-bier-mvpn Mar 2018 - Published as proposed standard: draft-ietf-bier-ospf-bier-extensions Mar 2018 - Published as proposed standard: draft-ietf-bier-isis-extensions Mar 2018 - Shepherd/IESG queue: draft-ietf-bier-oam-requirements Mar 2018 - Shepherd/IESG queue: draft-ietf-bier-path-mtu-discovery Mar 2018 - Shepherd/IESG queue: draft-ietf-bier-pmmm-oam Mar 2018 - Shepherd/IESG queue: draft-ietf-bier-ping Mar 2018 - Shepherd/IESG queue: draft-ietf-bier-use-cases Mar 2018 - WGLC: draft-ietf-bier-idr-extensions Mar 2018 - WGLC: draft-ietf-bier-bgp-ls-bier-ext Mar 2018 - WG call for adoption: draft-hfa-bier-pim-signaling Mar 2018 - IETF 101 discuss BIER-TE documents adoption Jul 2018 - Publish as proposed standard: draft-ietf-bier-oam-requirements Jul 2018 - Publish as proposed standard: draft-ietf-bier-path-mtu-discovery Jul 2018 - Publish as proposed standard: draft-ietf-bier-pmmm-oam Jul 2018 - Publish as proposed standard:draft-ietf-bier-ping Jul 2018 - Publish as proposed standard: draft-ietf-bier-use-cases Jul 2018 - WGLC: draft-ietf-bier-evpn Nov 2018 - Target feasibility and solution selection for IPv6 encap Nov 2018 - Progress YANG BIER drafts to WGLC Nov 2018 - Publish document(s) solidifying BAR/IPA complexity Mar 2019 - WGLC BIER-TE drafts Internet-Drafts: - YANG Data Model for BIER Protocol [draft-chh-bier-bier-yang-04] (19 pages) - BIER BFD [draft-hu-bier-bfd-07] (11 pages) - Multicast Using Bit Index Explicit Replication (BIER) [draft-ietf-bier-architecture-08] (43 pages) - Underlay Path Calculation Algorithm and Constraints for Bit Index Explicit Replication (BIER) [draft-ietf-bier-bar-ipa-13] (6 pages) - BIER BFD [draft-ietf-bier-bfd-07] (9 pages) - BGP Link-State extensions for BIER [draft-ietf-bier-bgp-ls-bier-ext-17] (11 pages) - Supporting BIER in IPv6 Networks (BIERin6) [draft-ietf-bier-bierin6-10] (10 pages) - YANG Data Model for BIER Protocol [draft-ietf-bier-bier-yang-09] (19 pages) - Use of BIER Entropy for Data Center Clos Networks [draft-ietf-bier-entropy-staged-dc-clos-04] (9 pages) - EVPN BUM Using BIER [draft-ietf-bier-evpn-14] (15 pages) - BIER Fast ReRoute [draft-ietf-bier-frr-04] (31 pages) - BGP Extensions for BIER [draft-ietf-bier-idr-extensions-11] (13 pages) - BIER IPv6 Requirements [draft-ietf-bier-ipv6-requirements-09] (7 pages) - Bit Index Explicit Replication (BIER) Support via IS-IS [draft-ietf-bier-isis-extensions-11] (12 pages) - LSR Extensions for BIER over Ethernet [draft-ietf-bier-lsr-ethernet-extensions-04] (13 pages) - LSR Extensions for BIER non-MPLS Encapsulation [draft-ietf-bier-lsr-non-mpls-extensions-03] (13 pages) - BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery Protocols [draft-ietf-bier-mld-08] (17 pages) - M-LDP Signaling Through BIER Core [draft-ietf-bier-mldp-signaling-over-bier-03] (10 pages) - Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks [draft-ietf-bier-mpls-encapsulation-12] (24 pages) - BIER MTU Discovery [draft-ietf-bier-mtud-00] (7 pages) - Multicast/BIER As A Service [draft-ietf-bier-multicast-as-a-service-03] (15 pages) - Applicability of BIER Multicast Overlay for Adaptive Streaming Services [draft-ietf-bier-multicast-http-response-06] (17 pages) - Multicast VPN Using Bit Index Explicit Replication (BIER) [draft-ietf-bier-mvpn-11] (17 pages) - An Optional Encoding of the BIFT-id Field in the non-MPLS BIER Encapsulation [draft-ietf-bier-non-mpls-bift-encoding-04] (6 pages) - Operations, Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer [draft-ietf-bier-oam-requirements-15] (7 pages) - OSPFv2 Extensions for Bit Index Explicit Replication (BIER) [draft-ietf-bier-ospf-bier-extensions-18] (12 pages) - OSPFv3 Extensions for BIER [draft-ietf-bier-ospfv3-extensions-07] (10 pages) - Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Replication (BIER) Layer [draft-ietf-bier-path-mtu-discovery-17] (9 pages) - BIER Penultimate Hop Popping [draft-ietf-bier-php-11] (8 pages) - PIM Signaling Through BIER Core [draft-ietf-bier-pim-signaling-12] (13 pages) - BIER Ping and Trace [draft-ietf-bier-ping-14] (30 pages) - Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer [draft-ietf-bier-pmmm-oam-15] (9 pages) - BIER Prefix Redistribute [draft-ietf-bier-prefix-redistribute-07] (14 pages) - Bit Indexed Explicit Replication (BIER) Problem Statement [draft-ietf-bier-problem-statement-00] (13 pages) - BIER (Bit Index Explicit Replication) Redundant Ingress Router Failover [draft-ietf-bier-source-protection-06] (11 pages) - Tree Engineering for Bit Index Explicit Replication (BIER-TE) [draft-ietf-bier-te-arch-13] (43 pages) - IS-IS Extensions for BIER-TE [draft-ietf-bier-te-isis-10] (8 pages) - OSPF Extensions for BIER-TE [draft-ietf-bier-te-ospf-10] (14 pages) - OSPFv3 Extensions for BIER-TE [draft-ietf-bier-te-ospfv3-08] (6 pages) - Tethering A BIER Router To A BIER incapable Router [draft-ietf-bier-tether-05] (9 pages) - A YANG data model for Tree Engineering for Bit Index Explicit Replication (BIER-TE) [draft-ietf-bier-te-yang-07] (19 pages) - BIER Use Cases [draft-ietf-bier-use-cases-12] (17 pages) - BIER Use Cases [draft-kumar-bier-use-cases-02] (12 pages) - BIER Ping and Trace [draft-kumarzheng-bier-ping-03] (26 pages) - Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Replication (BIER) Layer [draft-mirsky-bier-path-mtu-discovery-01] (8 pages) - Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer [draft-mirsky-bier-pmmm-oam-01] (7 pages) - BIER support via ISIS [draft-przygienda-bier-isis-ranges-02] (13 pages) - OSPF Extensions For BIER [draft-psenak-ospf-bier-extensions-02] (8 pages) - Multicast VPN Using BIER [draft-rosen-l3vpn-mvpn-bier-02] (10 pages) - Bit Indexed Explicit Replication (BIER) Problem Statement [draft-shepherd-bier-problem-statement-02] (13 pages) - Multicast using Bit Index Explicit Replication [draft-wijnands-bier-architecture-05] (30 pages) - Encapsulation for Bit Index Explicit Replication in MPLS Networks [draft-wijnands-mpls-bier-encapsulation-02] (13 pages) - Supporting BIER in IPv6 Networks (BIERin6) [draft-zhang-bier-bierin6-09] (11 pages) Requests for Comments: RFC8279: Multicast Using Bit Index Explicit Replication (BIER) (43 pages) RFC8296: Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks (24 pages) RFC8401: Bit Index Explicit Replication (BIER) Support via IS-IS (12 pages) * Updates RFC9272 RFC8444: OSPFv2 Extensions for Bit Index Explicit Replication (BIER) (12 pages) * Updates RFC9272 RFC8556: Multicast VPN Using Bit Index Explicit Replication (BIER) (17 pages) RFC9262: Tree Engineering for Bit Index Explicit Replication (BIER-TE) (43 pages) RFC9272: Underlay Path Calculation Algorithm and Constraints for Bit Index Explicit Replication (BIER) (6 pages) RFC9624: EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Using Bit Index Explicit Replication (BIER) (13 pages) Computing-Aware Traffic Steering (cats) --------------------------------------- Charter Last Modified: 2024-07-24 Current Status: Active Chairs: Adrian Farrel Mohamed Boucadair Peng Liu Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Jim Guichard Secretary: Cheng Li Mailing Lists: General Discussion: cats@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cats/ Archive: https://mailarchive.ietf.org/arch/browse/cats/ Description of Working Group: Computing-Aware Traffic Steering (cats) Many service architectures create multiple service instances. These instances are often geographically distributed to multiple sites, and a single site may support multiple instances of a service. The services are provided on computing platforms and are generically referred to as "compute services". The CATS (Computing-Aware Traffic Steering) working group (WG) is chartered to consider the problem of how the network edge can steer traffic between clients of a service and sites offering the service. Since, for some services (for example, the evolution of networked AR/VR, and deployment of autonomous and networked vehicles), the performance experienced by clients will depend on both network metrics such as bandwidth and latency, and compute metrics such as processing, storage capabilities, and capacity, there is a need for a solution that can optimize how a network edge node steers traffic based on these metrics, as appropriate to the service. Although the specific optimization function will likely differ between services, implementations, and deployments, there is a need for a general framework for the distribution of compute and network metrics and transport of traffic from network edge to service instance. It also is likely that some set of common metrics can be identified. The CATS WG will concern itself with these issues. The IETF is working on exposing network conditions to endpoints (notably ALTO) and load balancing/service selection at layers 4 and 7 (for example, related to the selection of SIP servers). Specific characteristics that may distinguish CATS from other work include the desire to integrate both network and compute conditions in the optimization function that informs the steering applied by the network edge nodes, and the desire to operate that function on nodes within the service provider's network, logically separated from service operation. Exposure of network and compute conditions to applications is not in the scope of CATS. Because of their experience and prior work in collecting and exposing network conditions for use in selecting paths and servers, the CATS WG will seek advice and expertise from the ART and TSV areas. The assumed model for the CATS WG is an overlay network, where a network edge node makes a decision based on the metrics of interest, and then steers the traffic to a node that serves a service instance, for example using a tunnel. The CATS WG will focus on single domain models. Architectures that require the underlay network to be service-aware are out of scope. The CATS WG will analyze the problem in further detail and produce an architecture for a solution. Ideally, that architecture will be one that can be instantiated using existing technologies. The CATS WG is chartered to work on the following items: o Groundwork may be documented via a set of informational Internet- Drafts, not necessarily for publication as RFCs: * Problem statement for the need to consider both network and computing resource status. * Use cases for steering traffic from applications that have critical SLAs that would benefit from the integrated consideration of network and computing resource status. * Requirements for commonly agreed computing metrics and their distribution across the overlay network, as well as the appropriate frequency and scope of distribution. o Overall CATS framework & architecture: * This work encompasses the various building blocks and their interactions, realizing a CATS control and data plane that addresses the identified problems and requirements in the groundwork, including methods for distributing necessary information to utilize the identified metrics in CATS use cases. This will also cover OAM, scalability, and security aspects. o Additional groundwork to include: * Analyze the suitability and usefulness of computing and networking metrics for traffic steering decisions in CATS with a CATS metrics ontology as a possible outcome. * Analyze methods for distributing the necessary information to utilize the identified metrics in CATS use cases. o Applicability of existing tools and mechanisms: * Analysis of implementing the CATS control and data plane using existing mechanisms, including identifying the limitations of existing tools in fulfilling requirements. * Study potential new approaches for the CATS control and data plane solution that can fill the identified gaps in existing tools and solutions. * Study FCAPS (fault, configuration, accounting, performance, security) requirements, mechanisms, and suitability of existing messaging protocols (NETCONF) and data models (YANG). Goals and Milestones: Mar 2025 - Adopt document describing CATS metrics Nov 2025 - Submit the CATS Framework and Architecture document to the IESG for publication as Informational Mar 2026 - Submit document describing CATS metrics to the IESG for publication as Informational Done - Adopt the CATS Problem Statement, Use Cases, Gap Analysis, and Requirements documents Done - Adopt the CATS Framework and Architecture document Internet-Drafts: - A Framework for Computing-Aware Traffic Steering (CATS) [draft-ietf-cats-framework-02] (25 pages) - Computing-Aware Traffic Steering (CATS) Problem Statement, Use Cases, and Requirements [draft-ietf-cats-usecases-requirements-03] (34 pages) - A Framework for Computing-Aware Traffic Steering (CATS) [draft-ldbc-cats-framework-06] (25 pages) - Computing-Aware Traffic Steering (CATS) Problem Statement, Use Cases, and Requirements [draft-yao-cats-ps-usecases-03] (24 pages) No Requests for Comments Common Control and Measurement Plane (ccamp) -------------------------------------------- Charter Last Modified: 2023-03-30 Current Status: Active Chairs: Daniele Ceccarelli Fatai Zhang Luis M. Contreras Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: John Scudder Secretary: Haomian Zheng Mailing Lists: General Discussion: ccamp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ccamp Archive: https://mailarchive.ietf.org/arch/browse/ccamp/ Description of Working Group: The CCAMP working group is responsible for standardizing a common control plane and a separate common measurement plane for non-packet technologies found in the Internet and in the networks of telecom service providers (ISPs and SPs). Examples of the devices in such networks include photonic cross-connects, OEO switches, ROADMs, TDM switches, microwave links, and Ethernet switches. In this context, measurement refers to the acquisition and distribution of attributes relevant to the setting up of tunnels and paths. The working group develops extensions to core Traffic Engineering protocols that are under the care of other working groups. The CCAMP working group will coordinate with the TEAS working group to ensure that extensions that can be generalized for use with more than one technology are made appropriately, and with the working groups that have responsibility for the specific protocols. CCAMP WG work scope includes: - Definition of protocol-independent metrics and parameters (measurement attributes) for describing links and paths that are required for routing and signaling in technology-specific networks. These will be developed in conjunction with requests and requirements from other WGs to ensure overall usefulness. - Maintenance and extension of the Link Management Protocol (LMP). - Functional specification of extensions for GMPLS-related routing (OSPF, ISIS) and signaling (RSVP-TE) protocols required for path establishment and maintenance in non-packet, technology-specific networks. Protocol formats and procedures that embody these extensions will be done jointly with the WGs supervising those protocols and the TEAS working group has the responsibility to determine whether such protocol extensions should be generalized for Traffic Engineering in any network. This may include protocol work to support data planes that have already been approved by another Standards Development Organization. Note that the specification or modification of data planes is out of scope of this working group - Definition of management objects (e.g., as part of MIB modules or YANG models) and control of OAM techniques relevant to the protocols and extensions specified within the WG. The OAM work will be synchronized with the LIME WG - Describe non-packet-specific aspects of traffic engineering including for multi-areas/multi-AS/multi-layer scenarios and define protocol extensions in cooperation with the TEAS and PCE working groups. - Define how the properties of network resources gathered by a measurement protocol (or by other means such as configuration) can be distributed in existing routing protocols, such as OSPF, IS-IS, and BGP-LS. CCAMP will work with the WGs that supervise these The CCAMP WG currently works on the following tasks: - Protocol extensions in support of WSON. - Protocol extensions in support of flexible grid lambda networks. - Maintenance of existing protocol extensions for non-packet technology-specific networks (Ethernet, TDM, OTN) already specified by CCAMP. - Maintenance of LMP. Goals and Milestones: May 2022 - Submit YANG modelling for flexi grid draft to IESG for review Jun 2022 - Submit T-NBI model applicability to IESG for review Jul 2022 - First version of YANG model of Ethernet Tunnel Working Group drafts Jul 2022 - Submit WSON tunnel YANG model to IESG for review Jul 2022 - Submit YANG model of OTN topology & Flexi-grid topology to IESG for review Jul 2022 - Submit YANG model of Layer 1 Types to IESG for review Aug 2022 - Submit L1CSM YANG model to IESG for review Aug 2022 - First version of client tunnel YANG model working group draft Sep 2022 - Submit DWDM Interface YANG model to IESG for review Oct 2022 - First version of client signal performance monitoring YANG model working group draft Nov 2022 - Submit OTN tunnel model to IESG for review Nov 2022 - Submit Microwave topology model to IESG for review Dec 2022 - Submit Info Model for WSON with impairments validation to IESG for review Dec 2022 - Submit YANG model of WSON Impairment Topology YANG model to IESG for review; Feb 2023 - Submit WSON IV info to IESG for review Feb 2023 - Submit OTN slicing YANG model to IESG for review Mar 2023 - Submit DWDM interface LMP and YANG to IESG for review Aug 2023 - Submit client signal YANG model to IESG for review Done - Identify and document a limited set of candidate solutions for signalling and for measurement. Among candidate control solutions to be considered are the existing GMPLS drafts. Done - Post strawman WG goals and charter Done - Build appropriate design teams Done - Submit WG document defining path setup portions of common control plane protocol Done - Submit WG document defining common measurement plane protocol Done - Submit LMP MIB to IESG Done - Submit ASON signaling requirements doc to IESG Done - Submit protection & restoration documents to IESG Done - Submit GMPLS MIBs to IESG Done - Submit ASON routing requirements doc to IESG Done - Produce CCAMP WG document for multi-area/AS signaling and routing Done - Produce CCAMP WG document for generic tunnel tracing protocol Done - Submit revised charter and milestones to IESG for IESG consideration of more detailed deliverables and determination of usefulness of continuation of WG Done - First version WG I-D for Advertising TE Node Capabilities in ISIS and OSPF Done - First version WG I-D for Automatic discovery of MPLS-TE mesh membership Done - Submit ASON Routing evaluation I-D for IESG review Done - First version WG I-D MPLS to GMPLS migration strategies Done - Cross-WG review of I-D for Advertising TE Node Capabilities in ISIS and OSPF Done - First version WG I-D for Evaluation of existing protocols for MLN/MRN Done - First version of WG I-D for ASON Routing solutions Done - First version WG I-D Requirements for Multi-Layer and Multi-Region Networks Done - Submit Per-domain path computation signaling I-D for IESG review Done - Submit RSVP-TE extensions for inter-domain signaling I-D for IESG review Done - First version WG Informational I-D for Analysis of inter-domain issues for disjoint and protected paths Done - Submit GMPLS signaling in support of Call Management I-D for IESG review Done - Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF for IESG review Done - First version WG I-D for Protocol solutions for MLN/MRN Done - First version of WG I-D for OSPF-TE/GMPLS MIB module Done - First version WG I-D MPLS-GMPLS interworking requirements and solutions Done - Submit GMPLS/ASON lexicography I-D for IESG review Done - Submit LSP Stitching I-D for IESG review Done - First version WG I-D GMPLS OAM Requirements Done - Submit I-D for Automatic discovery of MPLS-TE mesh membership for IESG review Done - Submit GMPLS routing and signaling interoperability advice I-D for IESG review Done - Submit MPLS to GMPLS migration strategies I-D for IESG review Done - Submit Requirements for Multi-Layer and Multi-Region Networks I-D for IESG review Done - Submit MPLS-GMPLS interworking requirements and solutions I-D for IESG review Done - Submit Evaluation of existing protocols for MLN/MRN for IESG review Done - Submit Informational I-D for Analysis of inter-domain issues for disjoint and protected paths for IESG review Done - First version WG I-Ds for GMPLS source-controlled and explicitly-routed Ethernet networks Done - Submit Protocol solutions for MLN/MRN I-D for IESG review Done - First version of WSON routing related Working Group drafts Done - Submit Ethernet related drafts for IESG review Done - Submit hierarchy bis for IESG review Done - Submit VCAT/LCAS with GMPLS for IESG review Done - Submit TE MIB module IESG review Done - First version of LMP Negotiation Working Group draft Done - First version of G.709 enhancements framework Working Group drafts Done - First version of Working Group draft providing Control Plane Framework for MPLS-TP Done - First version of OAM configuration solutions Working Group draft Done - Submit Lambda labels draft for IESG review Done - Submit WSON framework draft for IESG review Done - Submit WSON impairment framework draft for IESG review Done - First version of G.709 enhancements solutions Working Group drafts Done - First version of Working Group draft defining RSVP-TE extensions for MPLS-TP Done - Submit Control Plane Framework for MPLS-TP for IESG review Done - Submit RSVP-TE extensions for MPLS-TP for IESG review Done - Submit LMP Negotiation for IESG review Done - Submit OAM configuration framework for IESG review Done - Submit G.709 enhancements solutions for IESG review Done - Submit G.709 enhancements framework for IESG review Done - First version flexigrid requirements/framework Working Group draft Done - Submit last OAM configuration solutions for IESG review Done - Submit first set of OAM configuration solutions for IESG review Done - Submit WSON signaling related draft for IESG review Done - Submit WSON routing related drafts for IESG review Done - Submit OTN signal types update and sub registry drafts to IESG for review Done - Submit flexi grid framework to IESG for review Done - First draft of technology specific version of signaling and routing bandwidth availability working group draft. Done - First version of YANG modelling for flexi grid Working Group draft Done - Submit flexi grid label, signaling and routing extensions to IESG for review Done - Submit technology specific version of signaling and routing bandwidth availability draft to IESG for review Done - Recharter or close Working Group Done - First version of YANG model of Ethernet Topology Working Group drafts Done - First version of OTN network slicing working group draft Done - Submit applicability of gmpls to OTN beyond 100G to IETF for review Internet-Drafts: - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extension for Additional Signal Types in G.709 OTN [draft-ali-ccamp-additional-signal-type-g709v3-05] (4 pages) - IANA Allocation Procedures for OTN Signal Type Subregistry to the GMPLS Signaling Parameters Registry [draft-ali-ccamp-otn-signal-type-subregistry-02] (4 pages) - Network Assigned Upstream-Label [draft-beeram-ccamp-network-assigned-upstream-label-03] (9 pages) - Revised Definition of The GMPLS Switching Capability and Type Fields [draft-berger-ccamp-swcaps-update-02] (9 pages) - Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks [draft-ceccarelli-ccamp-gmpls-ospf-g709-07] (29 pages) - Domain Subobjects for Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) [draft-dhody-ccamp-rsvp-te-domain-subobjects-02] (17 pages) - A YANG Data Model for Layer 0 Types - Revision 2 [draft-esdih-ccamp-layer0-types-ext-01] (28 pages) - Problem Statement and Architecture for Information Exchange Between Interconnected Traffic Engineered Networks [draft-farrel-interconnected-te-info-exchange-07] (56 pages) - A Yang Data Model for L1 Connectivity Service Model (L1CSM) [draft-fioccola-ccamp-l1csm-yang-01] (22 pages) - YANG Data Models for requesting Path Computation in Optical Networks [draft-gbb-ccamp-optical-path-computation-yang-02] (35 pages) - A YANG Data Model for requesting Path Computation in an Optical Transport Network (OTN) [draft-gbb-ccamp-otn-path-computation-yang-02] (19 pages) - RSVP-TE Extension for Additional Signal Types in G.709 Optical Transport Networks (OTNs) [draft-ietf-ccamp-additional-signal-type-g709v3-04] (5 pages) - A YANG Data Model for Alarm Management [draft-ietf-ccamp-alarm-module-09] (82 pages) - RSVP ASSOCIATION Object Extensions [draft-ietf-ccamp-assoc-ext-06] (17 pages) - Usage of the RSVP ASSOCIATION Object [draft-ietf-ccamp-assoc-info-03] (11 pages) - GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) [draft-ietf-ccamp-asymm-bw-bidir-lsps-02] (14 pages) - GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) [draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-03] (11 pages) - Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects [draft-ietf-ccamp-attribute-bnf-02] (8 pages) - Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership [draft-ietf-ccamp-automesh-04] (15 pages) - A YANG Data Model for Bandwidth Availability Topology [draft-ietf-ccamp-bwa-topo-yang-01] (12 pages) - A YANG Data Model for Transport Network Client Signals [draft-ietf-ccamp-client-signal-yang-13] (68 pages) - Data Channel Status Confirmation Extensions for the Link Management Protocol [draft-ietf-ccamp-confirm-data-channel-status-09] (15 pages) - Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE [draft-ietf-ccamp-crankback-06] (38 pages) - Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS and MPLS Traffic Engineering (MPLS-TE) Networks [draft-ietf-ccamp-dpm-08] (29 pages) - Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage the application code of optical interface parameters in DWDM application [draft-ietf-ccamp-dwdm-if-lmp-09] (15 pages) - A framework for Management and Control of DWDM optical interface parameters [draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13] (31 pages) - A YANG model to manage the optical interface parameters for an external transponder in a WDM network [draft-ietf-ccamp-dwdm-if-param-yang-11] (25 pages) - A YANG Data Model for Ethernet TE Topology [draft-ietf-ccamp-eth-client-te-topo-yang-06] (72 pages) - Service Provider Requirements for Ethernet control with GMPLS [draft-ietf-ccamp-ethernet-gmpls-provider-reqs-02] (20 pages) - Ethernet Traffic Parameters [draft-ietf-ccamp-ethernet-traffic-parameters-10] (14 pages) - YANG Data Model for FlexE Management [draft-ietf-ccamp-flexe-yang-cm-04] (20 pages) - GMPLS OSPF-TE Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks [draft-ietf-ccamp-flexible-grid-ospf-ext-09] (17 pages) - RSVP-TE Signaling Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks [draft-ietf-ccamp-flexible-grid-rsvp-te-ext-05] (12 pages) - Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks [draft-ietf-ccamp-flexi-grid-fwk-07] (42 pages) - Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers [draft-ietf-ccamp-flexigrid-lambda-label-05] (14 pages) - A YANG Data Model for Flexi-Grid Media Channels [draft-ietf-ccamp-flexigrid-media-channel-yang-04] (62 pages) - A YANG Data Model for Flexi-Grid Tunnels [draft-ietf-ccamp-flexigrid-tunnel-yang-03] (41 pages) - A YANG Data Model for Flexi-Grid Optical Networks [draft-ietf-ccamp-flexigrid-yang-17] (70 pages) - General Network Element Constraint Encoding for GMPLS-Controlled Networks [draft-ietf-ccamp-general-constraint-encode-20] (28 pages) - Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks [draft-ietf-ccamp-gmpls-addressing-08] (23 pages) - GMPLS - Communication of Alarm Information [draft-ietf-ccamp-gmpls-alarm-spec-06] (19 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Architecture [draft-ietf-ccamp-gmpls-architecture-07] (69 pages) - A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture [draft-ietf-ccamp-gmpls-ason-lexicography-06] (19 pages) - Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON) [draft-ietf-ccamp-gmpls-ason-reqts-07] (16 pages) - Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements [draft-ietf-ccamp-gmpls-ason-routing-eval-03] (22 pages) - OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing [draft-ietf-ccamp-gmpls-ason-routing-ospf-09] (29 pages) - Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON) [draft-ietf-ccamp-gmpls-ason-routing-reqts-05] (22 pages) - Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions [draft-ietf-ccamp-gmpls-dcsc-channel-ext-04] (10 pages) - GMPLS Signaling Procedure for Egress Control [draft-ietf-ccamp-gmpls-egress-control-03] (5 pages) - Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework [draft-ietf-ccamp-gmpls-ethernet-arch-09] (20 pages) - Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE) [draft-ietf-ccamp-gmpls-ethernet-pbb-te-06] (20 pages) - Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching [draft-ietf-ccamp-gmpls-ether-svcs-04] (15 pages) - Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers [draft-ietf-ccamp-gmpls-g-694-lambda-labels-11] (15 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control [draft-ietf-ccamp-gmpls-g709-09] (23 pages) - Framework for GMPLS and PCE Control of G.709 Optical Transport Networks [draft-ietf-ccamp-gmpls-g709-framework-15] (26 pages) - OSPF-TE Extensions for General Network Element Constraints [draft-ietf-ccamp-gmpls-general-constraints-ospf-te-10] (12 pages) - Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base [draft-ietf-ccamp-gmpls-lsr-mib-15] (42 pages) - Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI) [draft-ietf-ccamp-gmpls-mef-uni-03] (10 pages) - Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN) [draft-ietf-ccamp-gmpls-mln-eval-06] (25 pages) - Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) [draft-ietf-ccamp-gmpls-mln-extensions-12] (24 pages) - Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) [draft-ietf-ccamp-gmpls-mln-reqs-11] (28 pages) - OAM Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Networks [draft-ietf-ccamp-gmpls-oam-requirements-00] (13 pages) - Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks [draft-ietf-ccamp-gmpls-ospf-g709v3-13] (36 pages) - Traffic Engineering Database Management Information Base in support of GMPLS [draft-ietf-ccamp-gmpls-ospf-mib-01] (22 pages) - Applicability of GMPLS for beyond 100 Gbit/s Optical Transport Network [draft-ietf-ccamp-gmpls-otn-b100g-applicability-15] (14 pages) - Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model [draft-ietf-ccamp-gmpls-overlay-05] (13 pages) - Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) [draft-ietf-ccamp-gmpls-recovery-analysis-05] (47 pages) - RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery [draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04] (47 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification [draft-ietf-ccamp-gmpls-recovery-functional-04] (23 pages) - Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) [draft-ietf-ccamp-gmpls-recovery-terminology-06] (22 pages) - Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) [draft-ietf-ccamp-gmpls-routing-09] (27 pages) - Generalized MPLS (GMPLS) RSVP-TE Signalling in support of Automatically Switched Optical Network (ASON) [draft-ietf-ccamp-gmpls-rsvp-te-ason-04] (40 pages) - Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls [draft-ietf-ccamp-gmpls-rsvp-te-call-04] (31 pages) - GMPLS Segment Recovery [draft-ietf-ccamp-gmpls-segment-recovery-03] (25 pages) - GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks [draft-ietf-ccamp-gmpls-signaling-g709v3-12] (27 pages) - Generalized MPLS Signaling - Implementation Survey [draft-ietf-ccamp-gmpls-signaling-survey-03] (101 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control [draft-ietf-ccamp-gmpls-sonet-sdh-08] (26 pages) - Generalized Multiprotocol Label Switching Extensions to Control Non-Standard SONET and SDH Features [draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03] (14 pages) - Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management [draft-ietf-ccamp-gmpls-tc-mib-11] (9 pages) - Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS [draft-ietf-ccamp-gmpls-ted-mib-15] (40 pages) - Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base [draft-ietf-ccamp-gmpls-te-mib-16] (60 pages) - Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) [draft-ietf-ccamp-gmpls-vcat-lcas-13] (21 pages) - Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures [draft-ietf-ccamp-gr-description-04] (18 pages) - Link Management Protocol Extensions for Grid Property Negotiation [draft-ietf-ccamp-grid-property-lmp-04] (12 pages) - A YANG Data Model for Interface Reference Topology [draft-ietf-ccamp-if-ref-topo-yang-01] (12 pages) - A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering [draft-ietf-ccamp-inter-domain-framework-06] (22 pages) - A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs) [draft-ietf-ccamp-inter-domain-pd-path-comp-06] (21 pages) - Analysis of Inter-Domain Label Switched Path (LSP) Recovery [draft-ietf-ccamp-inter-domain-recovery-analysis-05] (26 pages) - Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions [draft-ietf-ccamp-inter-domain-rsvp-te-07] (25 pages) - ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering [draft-ietf-ccamp-isis-interas-te-extension-04] (19 pages) - A YANG Data Model for L1 Connectivity Service Model (L1CSM) [draft-ietf-ccamp-l1csm-yang-26] (19 pages) - A YANG Data Model for Layer 0 Types [draft-ietf-ccamp-layer0-types-09] (20 pages) - A YANG Data Model for Layer 0 Types - Revision 2 [draft-ietf-ccamp-layer0-types-ext-01] (27 pages) - Common YANG Data Types for Layer 1 Networks [draft-ietf-ccamp-layer1-types-18] (55 pages) - Link Management Protocol (LMP) [draft-ietf-ccamp-lmp-10] (86 pages) - Link Management Protocol Behavior Negotiation and Configuration Modifications [draft-ietf-ccamp-lmp-behavior-negotiation-11] (11 pages) - Link Management Protocol (LMP) Management Information Base (MIB) [draft-ietf-ccamp-lmp-mib-10] (82 pages) - Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages [draft-ietf-ccamp-lmp-test-sonet-sdh-04] (15 pages) - Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems [draft-ietf-ccamp-lmp-wdm-03] (16 pages) - Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP) [draft-ietf-ccamp-loose-path-reopt-02] (14 pages) - Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks [draft-ietf-ccamp-lsp-dppm-11] (44 pages) - Procedures for Dynamically Signaled Hierarchical Label Switched Paths [draft-ietf-ccamp-lsp-hierarchy-bis-08] (30 pages) - Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE) [draft-ietf-ccamp-lsp-stitching-06] (19 pages) - A Framework for Management and Control of Microwave and Millimeter Wave Interface Parameters [draft-ietf-ccamp-microwave-framework-07] (20 pages) - Framework for MPLS-TE to GMPLS Migration [draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05] (19 pages) - Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks [draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04] (15 pages) - Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks [draft-ietf-ccamp-mpls-graceful-shutdown-13] (11 pages) - MPLS Transport Profile (MPLS-TP) Control Plane Framework [draft-ietf-ccamp-mpls-tp-cp-framework-06] (57 pages) - A YANG Data Model for Microwave Topology [draft-ietf-ccamp-mw-topo-yang-12] (45 pages) - A YANG Data Model for Microwave Radio Link [draft-ietf-ccamp-mw-yang-13] (53 pages) - A YANG Data Model for Network Hardware Inventory [draft-ietf-ccamp-network-inventory-yang-02] (43 pages) - GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration [draft-ietf-ccamp-oam-configuration-fwk-13] (24 pages) - TITLE: Optical Link Interface Requirements [draft-ietf-ccamp-oli-reqts-00] (13 pages) - A YANG Data Model for Optical Impairment-aware Topology [draft-ietf-ccamp-optical-impairment-topology-yang-16] (148 pages) - YANG Data Models for requesting Path Computation in WDM Optical Networks [draft-ietf-ccamp-optical-path-computation-yang-04] (31 pages) - OSPF Traffic Engineering (OSPF-TE) Link Availability Extension for Links with Variable Discrete Bandwidth [draft-ietf-ccamp-ospf-availability-extension-13] (10 pages) - OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) [draft-ietf-ccamp-ospf-gmpls-extensions-12] (11 pages) - OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering [draft-ietf-ccamp-ospf-interas-te-extension-06] (17 pages) - Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs) [draft-ietf-ccamp-otn-g709-info-model-13] (23 pages) - A YANG Data Model for requesting Path Computation in an Optical Transport Network (OTN) [draft-ietf-ccamp-otn-path-computation-yang-03] (20 pages) - IANA Allocation Procedures for the GMPLS OTN Signal Type Registry [draft-ietf-ccamp-otn-signal-type-subregistry-05] (4 pages) - A YANG Data Model for Optical Transport Network Topology [draft-ietf-ccamp-otn-topo-yang-19] (87 pages) - OTN Tunnel YANG Model [draft-ietf-ccamp-otn-tunnel-model-21] (49 pages) - Resource Reservation Protocol (RSVP) Extensions for Path Key Support [draft-ietf-ccamp-path-key-ero-04] (14 pages) - Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network [draft-ietf-ccamp-pc-and-sc-reqs-06] (11 pages) - RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network [draft-ietf-ccamp-pc-spc-rsvpte-ext-07] (23 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control [draft-ietf-ccamp-rfc3946bis-01] (25 pages) - Link Management Protocol (LMP) Management Information Base (MIB) [draft-ietf-ccamp-rfc4327bis-01] (83 pages) - Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) [draft-ietf-ccamp-rfc4420bis-03] (22 pages) - Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols [draft-ietf-ccamp-rfc5787bis-06] (30 pages) - Common YANG Data Types for Layer 0 Networks [draft-ietf-ccamp-rfc9093-bis-11] (73 pages) - Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement [draft-ietf-ccamp-rsvp-node-id-based-hello-03] (7 pages) - RSVP Resource Sharing Remote Identification Association [draft-ietf-ccamp-rsvp-resource-sharing-02] (11 pages) - Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart [draft-ietf-ccamp-rsvp-restart-ext-09] (24 pages) - Ethernet Traffic Parameters with Availability Information [draft-ietf-ccamp-rsvp-te-bandwidth-availability-16] (13 pages) - GMPLS RSVP-TE Extensions for Ethernet Operations, Administration, and Maintenance (OAM) Configuration [draft-ietf-ccamp-rsvp-te-eth-oam-ext-13] (18 pages) - Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) [draft-ietf-ccamp-rsvp-te-exclude-route-06] (27 pages) - Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using RSVP-TE [draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-16] (32 pages) - GMPLS RSVP-TE Extensions for SONET/SDH and OTN OAM Configuration [draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-06] (16 pages) - Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks [draft-ietf-ccamp-rwa-info-24] (23 pages) - Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks [draft-ietf-ccamp-rwa-wson-encode-28] (37 pages) - Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs) [draft-ietf-ccamp-rwa-wson-framework-12] (51 pages) - Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks [draft-ietf-ccamp-sdhsonet-control-05] (35 pages) - Revised Definition of the GMPLS Switching Capability and Type Fields [draft-ietf-ccamp-swcaps-update-03] (9 pages) - IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities [draft-ietf-ccamp-te-node-cap-05] (13 pages) - Tracing Requirements for Generic Tunnels [draft-ietf-ccamp-tracereq-05] (9 pages) - A Transport Network View of the Link Management Protocol (LMP) [draft-ietf-ccamp-transport-lmp-02] (18 pages) - Transport Northbound Interface Applicability Statement [draft-ietf-ccamp-transport-nbi-app-statement-17] (92 pages) - Transport Northbound Interface Applicability Statement and Use Cases [draft-ietf-ccamp-transport-nbi-use-cases-01] (28 pages) - Conveying Transceiver-Related Information within RSVP-TE Signaling [draft-ietf-ccamp-tsvmode-signaling-00] (14 pages) - Generic Tunnel Tracing Protocol (GTTP) Specification [draft-ietf-ccamp-tunproto-01] (36 pages) - Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) [draft-ietf-ccamp-wavelength-switched-framework-01] (37 pages) - A YANG Data Model for WDM Tunnels [draft-ietf-ccamp-wdm-tunnel-yang-02] (75 pages) - A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments [draft-ietf-ccamp-wson-impairments-10] (31 pages) - Information Encoding for WSON with Impairments Validation [draft-ietf-ccamp-wson-iv-encode-02] (11 pages) - Information Model for Wavelength Switched Optical Networks (WSONs) with Impairments Validation [draft-ietf-ccamp-wson-iv-info-12] (19 pages) - GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks [draft-ietf-ccamp-wson-signal-compatibility-ospf-17] (12 pages) - Signaling Extensions for Wavelength Switched Optical Networks [draft-ietf-ccamp-wson-signaling-12] (16 pages) - A Yang Data Model for WSON Tunnel [draft-ietf-ccamp-wson-tunnel-model-09] (43 pages) - A YANG Data Model for Wavelength Switched Optical Networks (WSONs) [draft-ietf-ccamp-wson-yang-28] (56 pages) - Framework and Data Model for OTN Network Slicing [draft-ietf-ccamp-yang-otn-slicing-07] (33 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions [draft-ietf-mpls-generalized-cr-ldp-07] (23 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions [draft-ietf-mpls-generalized-rsvp-te-09] (42 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description [draft-ietf-mpls-generalized-signaling-09] (34 pages) - A framework for Management and Control of DWDM optical interface parameters [draft-kdkgall-ccamp-dwdm-if-mng-ctrl-fwk-01] (29 pages) - A Yang Data Model for WSON Optical Networks [draft-lee-ccamp-wson-yang-04] (17 pages) - Link Management Protocol Extensions for Grid Property Negotiation [draft-li-ccamp-grid-property-lmp-03] (12 pages) - OSPF Routing Extension for Links with Variable Discrete Bandwidth [draft-long-ccamp-ospf-availability-extension-04] (8 pages) - RSVP-TE Signaling Extension for Links with Variable Discrete Bandwidth [draft-long-ccamp-rsvp-te-bandwidth-availability-05] (11 pages) - Information Encoding for WSON with Impairments Validation [draft-martinelli-ccamp-wson-iv-encode-09] (12 pages) - Information Model for Wavelength Switched Optical Networks (WSONs) with Impairments Validation [draft-martinelli-ccamp-wson-iv-info-05] (19 pages) - A YANG Data Model for Microwave Radio Link [draft-mwdt-ccamp-mw-yang-01] (37 pages) - Framework and Requirements for GMPLS based control of Flexi-grid DWDM networks [draft-ogrcetal-ccamp-flexi-grid-fwk-03] (30 pages) - OTN Tunnel YANG Model [draft-sharma-ccamp-otn-tunnel-model-02] (21 pages) - Transport Northbound Interface Applicability Statement and Use Cases [draft-tnbidt-ccamp-transport-nbi-use-cases-03] (28 pages) - YANG Alarm Module [draft-vallin-ccamp-alarm-module-01] (58 pages) - YANG Data Model for FlexE Management [draft-wang-ccamp-flexe-yang-cm-04] (20 pages) - A YANG Data Model for Network Hardware Inventory [draft-yg3bp-ccamp-network-inventory-yang-02] (38 pages) - GMPLS OSPF-TE Extensions in support of Flexible Grid [draft-zhang-ccamp-flexible-grid-ospf-ext-04] (14 pages) - RSVP-TE Signaling Extensions in support of Flexible Grid [draft-zhang-ccamp-flexible-grid-rsvp-te-ext-04] (12 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control [draft-zhang-ccamp-gmpls-evolving-g709-09] (24 pages) - RSVP-TE Signaling Procedure for GMPLS Restoration and Resource Sharing- based LSP Setup and Teardown [draft-zhang-ccamp-gmpls-resource-sharing-proc-03] (19 pages) - RSVP-TE Identification of MPLS-TP Co-Routed Bidirectional LSP [draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-05] (8 pages) - RSVP-TE Extensions for Collecting SRLG Information [draft-zhang-ccamp-srlg-fa-configuration-05] (9 pages) - A YANG Data Model for Transport Network Client Signals [draft-zheng-ccamp-client-signal-yang-07] (50 pages) - A YANG Data Model for Ethernet TE Topology [draft-zheng-ccamp-client-topo-yang-10] (66 pages) Requests for Comments: RFC3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description (34 pages) * Updates RFC4201 * Updates RFC4328 * Updates RFC4872 * Updates RFC6002 * Updates RFC6003 * Updates RFC6205 * Updates RFC7074 * Updates RFC7699 * Updates RFC8359 RFC3472: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions (23 pages) * Updates RFC3468 * Updates RFC4201 RFC3473: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions (42 pages) * Updates RFC4003 * Updates RFC4201 * Updates RFC4420 * Updates RFC4783 * Updates RFC4874 * Updates RFC4873 * Updates RFC4974 * Updates RFC5063 * Updates RFC5151 * Updates RFC5420 * Updates RFC6002 * Updates RFC6003 * Updates RFC6780 * Updates RFC8359 RFC3609: Tracing Requirements for Generic Tunnels (9 pages) RFC3945: Generalized Multi-Protocol Label Switching (GMPLS) Architecture (69 pages) * Updates RFC6002 RFC3946: Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control (26 pages) * Obsoletes RFC4606 RFC4003: GMPLS Signaling Procedure for Egress Control (5 pages) RFC4139: Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON) (16 pages) RFC4202: Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) (27 pages) * Updates RFC6001 * Updates RFC6002 * Updates RFC7074 RFC4203: OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) (11 pages) * Updates RFC6001 * Updates RFC6002 * Updates RFC7074 RFC4204: Link Management Protocol (LMP) (86 pages) * Updates RFC6898 RFC4207: Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages (15 pages) * Updates RFC6898 RFC4208: Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model (13 pages) RFC4209: Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems (16 pages) * Updates RFC6898 RFC4257: Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks (35 pages) RFC4258: Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON) (22 pages) RFC4327: Link Management Protocol (LMP) Management Information Base (MIB) (82 pages) * Obsoletes RFC4631 RFC4328: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control (23 pages) * Updates RFC7139 RFC4394: A Transport Network View of the Link Management Protocol (LMP) (18 pages) RFC4397: A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture (19 pages) RFC4426: Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification (23 pages) RFC4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) (22 pages) RFC4428: Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) (47 pages) RFC4558: Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement (7 pages) RFC4606: Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control (25 pages) * Updates RFC6344 RFC4631: Link Management Protocol (LMP) Management Information Base (MIB) (83 pages) RFC4652: Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements (22 pages) RFC4726: A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering (22 pages) RFC4736: Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP) (14 pages) RFC4783: GMPLS - Communication of Alarm Information (19 pages) RFC4801: Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management (9 pages) RFC4802: Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base (60 pages) RFC4803: Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base (42 pages) RFC4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery (47 pages) * Updates RFC4873 * Updates RFC6780 * Updates RFC9270 RFC4873: GMPLS Segment Recovery (25 pages) * Updates RFC9270 RFC4874: Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) (27 pages) * Updates RFC6001 * Updates RFC8390 RFC4920: Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE (38 pages) RFC4972: Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership (15 pages) RFC4974: Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls (31 pages) * Updates RFC6001 RFC4990: Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks (23 pages) RFC5063: Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart (24 pages) RFC5073: IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities (13 pages) RFC5145: Framework for MPLS-TE to GMPLS Migration (19 pages) RFC5146: Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks (15 pages) RFC5150: Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE) (19 pages) RFC5151: Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions (25 pages) RFC5152: A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs) (21 pages) RFC5212: Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) (28 pages) RFC5298: Analysis of Inter-Domain Label Switched Path (LSP) Recovery (26 pages) RFC5316: ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering (19 pages) * Obsoletes RFC9346 RFC5339: Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN) (25 pages) RFC5392: OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering (17 pages) RFC5420: Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) (22 pages) * Updates RFC6510 RFC5467: GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) (14 pages) * Obsoletes RFC6387 RFC5493: Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network (11 pages) RFC5495: Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures (18 pages) RFC5553: Resource Reservation Protocol (RSVP) Extensions for Path Key Support (14 pages) RFC5787: OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing (29 pages) * Obsoletes RFC6827 RFC5814: Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks (44 pages) RFC5817: Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks (11 pages) RFC5818: Data Channel Status Confirmation Extensions for the Link Management Protocol (15 pages) * Updates RFC6898 RFC5828: Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework (20 pages) RFC5852: RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network (23 pages) RFC6001: Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) (24 pages) RFC6002: Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions (10 pages) RFC6003: Ethernet Traffic Parameters (14 pages) RFC6004: Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching (15 pages) RFC6005: Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI) (10 pages) RFC6060: Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE) (20 pages) RFC6107: Procedures for Dynamically Signaled Hierarchical Label Switched Paths (30 pages) RFC6163: Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs) (51 pages) RFC6205: Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers (15 pages) * Updates RFC7699 * Updates RFC8359 RFC6344: Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) (21 pages) RFC6373: MPLS Transport Profile (MPLS-TP) Control Plane Framework (57 pages) RFC6387: GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) (11 pages) RFC6510: Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects (8 pages) RFC6566: A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments (31 pages) RFC6689: Usage of the RSVP ASSOCIATION Object (11 pages) RFC6777: Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS and MPLS Traffic Engineering (MPLS-TE) Networks (29 pages) RFC6780: RSVP ASSOCIATION Object Extensions (17 pages) RFC6825: Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS (40 pages) RFC6827: Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols (30 pages) RFC6898: Link Management Protocol Behavior Negotiation and Configuration Modifications (11 pages) RFC7062: Framework for GMPLS and PCE Control of G.709 Optical Transport Networks (26 pages) RFC7074: Revised Definition of the GMPLS Switching Capability and Type Fields (9 pages) RFC7096: Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs) (23 pages) RFC7138: Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks (36 pages) RFC7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks (27 pages) * Updates RFC7892 RFC7260: GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration (24 pages) RFC7369: GMPLS RSVP-TE Extensions for Ethernet Operations, Administration, and Maintenance (OAM) Configuration (18 pages) RFC7446: Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks (23 pages) RFC7487: Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using RSVP-TE (32 pages) RFC7579: General Network Element Constraint Encoding for GMPLS-Controlled Networks (28 pages) RFC7580: OSPF-TE Extensions for General Network Element Constraints (12 pages) RFC7581: Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks (37 pages) RFC7688: GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks (12 pages) RFC7689: Signaling Extensions for Wavelength Switched Optical Networks (16 pages) RFC7698: Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks (42 pages) RFC7699: Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers (14 pages) RFC7792: RSVP-TE Signaling Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks (12 pages) RFC7892: IANA Allocation Procedures for the GMPLS OTN Signal Type Registry (4 pages) RFC7963: RSVP-TE Extension for Additional Signal Types in G.709 Optical Transport Networks (OTNs) (5 pages) RFC8330: OSPF Traffic Engineering (OSPF-TE) Link Availability Extension for Links with Variable Discrete Bandwidth (10 pages) RFC8363: GMPLS OSPF-TE Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks (17 pages) RFC8432: A Framework for Management and Control of Microwave and Millimeter Wave Interface Parameters (20 pages) RFC8561: A YANG Data Model for Microwave Radio Link (53 pages) RFC8625: Ethernet Traffic Parameters with Availability Information (13 pages) RFC8632: A YANG Data Model for Alarm Management (82 pages) RFC9093: A YANG Data Model for Layer 0 Types (20 pages) RFC9094: A YANG Data Model for Wavelength Switched Optical Networks (WSONs) (56 pages) RFC9376: Applicability of GMPLS for beyond 100 Gbit/s Optical Transport Network (14 pages) Deterministic Networking (detnet) --------------------------------- Charter Last Modified: 2024-04-26 Current Status: Active Chairs: János Farkas Lou Berger Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: John Scudder Tech Advisor: David Black Secretary: Eve Schooler Mailing Lists: General Discussion: detnet@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/detnet Archive: https://mailarchive.ietf.org/arch/browse/detnet/ Description of Working Group: The Deterministic Networking (DetNet) Working Group focuses on deterministic data paths that operate over Layer 2 bridged and Layer 3 routed segments, where such paths can provide bounds on reordering, latency, loss, and packet delay variation (jitter), and high reliability. DetNet solutions apply to both wireless and wired networks. The Working Group addresses Layer 3 aspects in support of applications requiring deterministic networking. The Working Group collaborates with IEEE802.1 Time-Sensitive Networking (TSN), which is responsible for Layer 2 operations, to define a common architecture for both Layer 2 and Layer 3. Example applications for deterministic networks include professional and home audio/video, multimedia in transportation, engine control systems, and other general industrial and vehicular applications being considered by the IEEE 802.1 TSN Task Group. The Working Group will initially focus on solutions for networks that are under a single administrative control or within a closed group of administrative control; these include not only campus-wide networks but also private WANs. The DetNet WG will not spend energy on solutions for large groups of domains such as the Internet. The Working Group is responsible for the overall DetNet architecture and DetNet-specific specifications that encompass the data plane, OAM (Operations, Administration, and Maintenance), time synchronization, management, control, and security aspects which are required to enable a multi-hop path, and forwarding along the path, with the deterministic properties of controlled latency, low packet loss, low packet delay variation, and high reliability. The work applies to point-to-point (unicast) and point-to-multipoint (multicast) flows which can be characterized in a manner that allows the network to 1) reserve the appropriate resources for the flows in advance, and 2) release/reuse the resources when they are no longer required. The work covers the characterization of flows, the encapsulation of frames, the required forwarding behaviors, as well as the state that may need to be established in intermediate nodes. Layer 3 data plane technologies that can be used include: IP and MPLS, and Layer 2 encapsulations that run over IP and/or MPLS, such as pseudowires and GRE. The Working Group will document which deployment environments and types of topologies are within (or outside) the scope of the DetNet architecture. This work focuses on the data plane aspects and is independent of any path setup protocol or mechanism. The Working Group will also document DetNet Controller Plane approaches that reuse existing IETF solutions, such as Path Computation Element (PCE), and identify the Working Group responsible for any extensions needed to support DetNet. Documents produced by the Working Group will be compatible with the work done in IEEE802.1 TSN and other IETF Working Groups. The Working Group's scope generally excludes modifications of transport protocols, OAM, Layer 3 forwarding, and encapsulations, but it may discuss requirements for such modifications and the work will be coordinated with the Working Group responsible for the technology. DetNet is chartered to work in the following areas: Overall architecture: This work encompasses the data plane, OAM, time synchronization, management, control, and security aspects. Data plane: This work will specify how to use IP and/or MPLS, and related OAM, to support a data plane method of flow identification and packet treatment over Layer 3. Other IETF-defined data plane technologies may also be used. Controller Plane: The DetNet Controller Plane is defined in RFC 8655 as "the aggregation of the Control and Management Planes". This work will document how to use IETF control plane solutions to support DetNet, including the identification of any gaps in existing solutions. Any modification to Controller Plane protocols to address identified gaps should be carried out in their associated Working Groups, but may be done in DetNet if agreed to by the relevant Working Group chairs and responsible Area Directors. Data flow information model: This work will identify the information needed for flow establishment and control and be used by reservation protocols and YANG data models. The work will be independent of the protocol(s) used to control the flows (e.g. YANG+NETCONF/RESTCONF, PCEP, or GMPLS). YANG models: This work will document device and link capabilities (feature support) and resources (e.g. buffers, bandwidth) for use in device configuration and status reporting. Such information may also be used when advertising the deterministic network elements to a control plane. Control plane-related information will be independent of the protocol(s) that may be used to advertise this information (e.g. IS-IS or GMPLS extensions). Any new YANG models will be coordinated with the Working Groups that define any base models that are to be augmented. DetNets including Wireless: This work will define how DetNet solutions operate over networks that include wired and wireless network technologies. The work may include providing DetNet reliability and availability for scheduled wireless segments and other wireless media, e.g., frequency/time-sharing physical media resources with stochastic traffic: IEEE Std. 802.15.4 timeslotted channel hopping (TSCH), 3GPP 5G ultra-reliable low latency communications (URLLC), IEEE 802.11ax/be, and L-band Digital Aeronautical Communications System (LDACS), etc. This work will stay abstract to the radio layers underneath, addressing the Layer 3 aspects in support of applications requiring high reliability and availability. As needed, vertical requirements: This effort will detail the requirements for deterministic networks in various industries that have previously not been documented and cannot be supported using defined DetNet solutions. To investigate whether existing data plane encryption mechanisms can be applied, possibly opportunistically, to improve security and privacy. The Working Group coordinates with other relevant IETF Working Groups, including CCAMP, IPPM, LSR, PCE, PALS, TEAS, TSVWG, RAW, and 6TiSCH. As the work progresses, requirements may be provided to the responsible Working Group, e.g. PCE, TEAS, and CCAMP, with DetNet acting as a focal point to maintain the consistency of the overall architecture and related solutions. The WG will liaise with appropriate groups in IEEE and other Standards Development Organizations (SDOs). Goals and Milestones: Mar 2024 - Adopt first Enhanced DetNet Data Plane solution document Mar 2024 - Submit RAW OAM document for publication as Informational Mar 2024 - Submit RAW architecture document for publication as Informational Jul 2024 - Submit controller plane framework for publication as Informational Jul 2024 - Submit Requirements for Scaling Deterministic Networks for publication as Informational Sep 2024 - Submit RAW framework document for publication as informational Dec 2024 - Submit first Enhanced DetNet Data Plane solution document for publication as Standards Track Internet-Drafts: - DetNet Data Plane Protocol and Solution Alternatives [draft-dt-detnet-dp-alt-04] (51 pages) - Deterministic Networking Architecture [draft-finn-detnet-architecture-08] (32 pages) - DetNet Bounded Latency [draft-finn-detnet-bounded-latency-04] (27 pages) - DetNet Configuration YANG Model [draft-geng-detnet-conf-yang-06] (51 pages) - Deterministic Networking Use Cases [draft-grossman-detnet-use-cases-01] (81 pages) - Deterministic Networking Architecture [draft-ietf-detnet-architecture-13] (38 pages) - Deterministic Networking (DetNet) Bounded Latency [draft-ietf-detnet-bounded-latency-10] (26 pages) - Deterministic Networking (DetNet) Controller Plane Framework [draft-ietf-detnet-controller-plane-framework-07] (19 pages) - Deterministic Networking (DetNet) Data Plane Framework [draft-ietf-detnet-data-plane-framework-06] (22 pages) - Dataplane Enhancement Taxonomy [draft-ietf-detnet-dataplane-taxonomy-01] (19 pages) - DetNet Data Plane Protocol and Solution Alternatives [draft-ietf-detnet-dp-alt-00] (51 pages) - DetNet Data Plane Encapsulation [draft-ietf-detnet-dp-sol-04] (39 pages) - DetNet IP Data Plane Encapsulation [draft-ietf-detnet-dp-sol-ip-02] (44 pages) - DetNet MPLS Data Plane Encapsulation [draft-ietf-detnet-dp-sol-mpls-02] (53 pages) - Flow and Service Information Model for Deterministic Networking (DetNet) [draft-ietf-detnet-flow-information-model-14] (20 pages) - Deterministic Networking (DetNet) Data Plane: IP [draft-ietf-detnet-ip-07] (21 pages) - Operations, Administration, and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane [draft-ietf-detnet-ip-oam-13] (9 pages) - Deterministic Networking (DetNet) Data Plane: IP over MPLS [draft-ietf-detnet-ip-over-mpls-09] (11 pages) - Deterministic Networking (DetNet) Data Plane: IP over IEEE 802.1 Time-Sensitive Networking (TSN) [draft-ietf-detnet-ip-over-tsn-07] (10 pages) - Deterministic Networking (DetNet) Data Plane: MPLS [draft-ietf-detnet-mpls-13] (27 pages) - Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with MPLS Data Plane [draft-ietf-detnet-mpls-oam-15] (14 pages) - Deterministic Networking (DetNet): DetNet PREOF via MPLS over UDP/IP [draft-ietf-detnet-mpls-over-ip-preof-11] (12 pages) - Deterministic Networking (DetNet) Data Plane: MPLS over IEEE 802.1 Time-Sensitive Networking (TSN) [draft-ietf-detnet-mpls-over-tsn-07] (11 pages) - Deterministic Networking (DetNet) Data Plane: MPLS over UDP/IP [draft-ietf-detnet-mpls-over-udp-ip-08] (8 pages) - Framework of Operations, Administration and Maintenance (OAM) for Deterministic Networking (DetNet) [draft-ietf-detnet-oam-framework-11] (16 pages) - Deterministic Networking (DetNet): Packet Ordering Function [draft-ietf-detnet-pof-11] (12 pages) - Deterministic Networking Problem Statement [draft-ietf-detnet-problem-statement-09] (11 pages) - Requirements for Reliable Wireless Industrial Services [draft-ietf-detnet-raw-industrial-req-01] (24 pages) - Requirements for Scaling Deterministic Networks [draft-ietf-detnet-scaling-requirements-06] (22 pages) - Deterministic Networking (DetNet) Security Considerations [draft-ietf-detnet-security-16] (50 pages) - Deterministic Networking (DetNet) Topology YANG Model [draft-ietf-detnet-topology-yang-01] (18 pages) - Deterministic Networking (DetNet) Data Plane: IEEE 802.1 Time-Sensitive Networking over MPLS [draft-ietf-detnet-tsn-vpn-over-mpls-07] (12 pages) - Deterministic Networking Use Cases [draft-ietf-detnet-use-cases-20] (97 pages) - Deterministic Networking (DetNet) YANG Model [draft-ietf-detnet-yang-20] (136 pages) - Reliable and Available Wireless Architecture [draft-ietf-raw-architecture-20] (43 pages) - Reliable and Available Wireless Framework [draft-ietf-raw-framework-02] (18 pages) - Reliable and Available Wireless Technologies [draft-ietf-raw-technologies-10] (66 pages) - Dataplane Enhancement Taxonomy [draft-joung-detnet-taxonomy-dataplane-01] (14 pages) - Requirements for Large-Scale Deterministic Networks [draft-liu-detnet-large-scale-requirements-05] (20 pages) - Deterministic Networking (DetNet) Security Considerations [draft-sdt-detnet-security-01] (35 pages) - Deterministic Networking (DetNet): DetNet PREOF via MPLS over UDP/IP [draft-varga-detnet-ip-preof-02] (12 pages) - Deterministic Networking (DetNet): Packet Ordering Function [draft-varga-detnet-pof-03] (12 pages) Requests for Comments: RFC8557: Deterministic Networking Problem Statement (11 pages) RFC8578: Deterministic Networking Use Cases (97 pages) RFC8655: Deterministic Networking Architecture (38 pages) RFC8938: Deterministic Networking (DetNet) Data Plane Framework (22 pages) RFC8939: Deterministic Networking (DetNet) Data Plane: IP (21 pages) RFC8964: Deterministic Networking (DetNet) Data Plane: MPLS (27 pages) RFC9016: Flow and Service Information Model for Deterministic Networking (DetNet) (20 pages) RFC9023: Deterministic Networking (DetNet) Data Plane: IP over IEEE 802.1 Time-Sensitive Networking (TSN) (10 pages) RFC9024: Deterministic Networking (DetNet) Data Plane: IEEE 802.1 Time-Sensitive Networking over MPLS (12 pages) RFC9025: Deterministic Networking (DetNet) Data Plane: MPLS over UDP/IP (8 pages) RFC9037: Deterministic Networking (DetNet) Data Plane: MPLS over IEEE 802.1 Time-Sensitive Networking (TSN) (11 pages) RFC9055: Deterministic Networking (DetNet) Security Considerations (50 pages) RFC9056: Deterministic Networking (DetNet) Data Plane: IP over MPLS (11 pages) RFC9320: Deterministic Networking (DetNet) Bounded Latency (26 pages) RFC9546: Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet) with the MPLS Data Plane (12 pages) RFC9550: Deterministic Networking (DetNet): Packet Ordering Function (11 pages) RFC9551: Framework of Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet) (14 pages) RFC9566: Deterministic Networking (DetNet) Packet Replication, Elimination, and Ordering Functions (PREOF) via MPLS over UDP/IP (10 pages) Inter-Domain Routing (idr) -------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Jeffrey Haas Keyur Patel Susan Hares Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: John Scudder Secretary: Jie Dong Mailing Lists: General Discussion: idr@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/idr Archive: https://mailarchive.ietf.org/arch/browse/idr/ Description of Working Group: The Inter-Domain Routing Working Group is chartered to standardize, develop, and support the Border Gateway Protocol Version 4 (BGP-4) [RFC 4271] capable of supporting policy based routing for TCP/IP internets. The main objective of the working group is to support the use of BGP-4 by IP version 4 and IP version 6 networks. The working group will also continue to work on improving the robustness and scalability of BGP. IDR will review extensions made to BGP in other working groups at least at WG document adoption and during working group last calls. The IDR working group will also provide advice and guidance on BGP to other working groups as requested. Work Items: The IDR working group will work on correctness, robustness and scalability of the BGP protocol, as well as clarity and accuracy of the BGP document set. The group will also work on extensions beyond these areas when specifically added to the charter. The current additional work items are: - Relax the definition of BGP identifiers to only require AS-wide uniqueness. This change must be made in a backward compatible way. - Specify a means to non-disruptively introduce new BGP Capabilities to an existing BGP session. - Upgrade of the base BGP specification to Full Standard - Define AS_PATH based Outbound Route Filtering. - MIB v2 for BGP-4 - Augment the BGP multiprotocol extensions to support the use of multiple concurrent sessions between a given pair of BGP speakers. Each session is used to transport routes related by some session- based attribute such as AFI/SAFI. This will provide an alternative to the MP-BGP approach of multiplexing all routes onto a single connection. - Support for four-octet AS Numbers in BGP. - Revisions to the BGP 'Minimum Route Advertisement Interval' deprecating the previously recommended values and allowing for withdrawals to be exempted from the MRAI. - Advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. Each path is identified by a path identifier in addition to the address prefix. - Revised error handling rules for optional transitive BGP attributes so that a BGP speaker is no longer required to reset the session over which a malformed attribute is received. Provide guidelines for authors of documents that define new optional transitive attributes, and re-assess procedures for existing optional transitive attributes - Specify Link Bandwidth Extended Community for use in unequal cost load balancing. - The definition of an "Accumulated IGP Metric" attribute for BGP to report the sum of the metric of each link along the path. This attribute is for use in a restricted environment where: - all ASes are subject to the administrative control - some form of tunneling is used to deliver a packet to its next BGP hop - where the path for a route leads outside the AS to which the BGP speaker adding the attribute belongs. - Advertisement of the best external route in BGP to assist with resolution of the next hop in the chosen data plane. Goals and Milestones: Mar 2015 - Submit ASpath ORF to IESG as a Proposed Standard Jun 2015 - Submit BGP Link Bandwidth Extended Community to IESG as a Proposed Standard Jun 2015 - Submit Advertisement of Multiple Paths in BGP to IESG as a Proposed Standard Nov 2015 - Submit Multisession BGP to IESG as a Proposed Standard Nov 2015 - Submit MIB v2 for BGP-4 to IESG as a Proposed Standard Dec 2015 - Submit Dynamic Capability for BGP-4 to IESG as a Proposed Standard Jan 2016 - Revise WG charter Feb 2016 - Submit Yang BGP Modules to IESG as Proposed Standard Feb 2016 - Submit ASpath ORF draft to IESG as a Proposed Standard Apr 2016 - Progress base BGP specification (RFC 4271) as Full Standard Apr 2016 - Solicit work items for scalability improvements Done - Submit to BGP Capability Advertisement to the IESG Done - Submit BGP4 MIB to IESG as a Proposed Standard Done - Submit BGP Security Vulnerabilities Analysis to IESG as an Informational Done - Submit BGP4 document to IESG as a Draft Standard Done - Submit revised text on Multi-Protocol BGP (rfc2858bis) to IESG as a Draft Standard Done - Submit Extended Communities draft to IESG as a Proposed Standard Done - Submit BGP Graceful Restart to IESG as a Proposed Standard Done - Submit Subcodes for BGP Cease Notification Message to IESG as a Proposed Standard Done - Submit 4-byte AS ID to IESG as a Proposed Standard Done - Submit Outbound Route Filter, Prefix and ASpath ORF draft to IESG as a Proposed Standard Done - Prefix and ASpath ORF draft to IESG as a Proposed Standard Done - Submit AS-wide Unique BGP Identifier for BGP-4 to IESG as a Proposed Standard Done - Submit BGP Support for Four-octet AS Number Space (revised version) to IESG as a Proposed Standard Done - Submit Revisions to the BGP 'Minimum Route Advertisement Interval' to IESG as a Proposed Standard Done - Submit The Accumulated IGP Metric Attribute for BGP to IESG as a Proposed Standard Done - Submit Error Handling for Optional Transitive BGP Attributes to IESG as a Proposed Standard Internet-Drafts: - BGP Logical Link Discovery Protocol (LLDP) Peer Discovery [draft-acee-idr-lldp-peer-discovery-18] (18 pages) - Deterministic Route Redistribution into BGP [draft-chen-bgp-redist-05] (9 pages) - SR Policies Extensions for Network Resource Partition in BGP-LS [draft-chen-idr-bgp-ls-sr-policy-nrp-09] (8 pages) - BGP for BIER-TE Path [draft-chen-idr-bier-te-path-05] (16 pages) - BGP for Mirror Binding [draft-chen-idr-mbinding-04] (7 pages) - Applying TCP User Timeout Parameter to BGP Sessions [draft-chen-idr-tcp-user-timeout-01] (6 pages) - BGP Extended Community Registries Update [draft-cl-idr-bgp-ext-com-registry-update-01] (5 pages) - BGP-LS Advertisement of Segment Routing Service Segments [draft-dawra-idr-bgp-ls-sr-service-segments-06] (12 pages) - BGP Link State Extensions for SRv6 [draft-dawra-idr-bgpls-srv6-ext-06] (24 pages) - BGP Flowspec for IETF Network Slice Traffic Steering [draft-dong-idr-flowspec-network-slice-ts-01] (10 pages) - BGP Extended Community for Identifying the Target Nodes [draft-dong-idr-node-target-ext-comm-05] (7 pages) - Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios [draft-dong-idr-rtc-hierarchical-rr-02] (6 pages) - BGP SR Policy Extensions for Network Resource Partition [draft-dong-idr-sr-policy-nrp-04] (8 pages) - BGP Color-Aware Routing (CAR) [draft-dskc-bess-bgp-car-05] (54 pages) - BGP Extension for 5G Edge Service Metadata [draft-dunbar-idr-5g-edge-compute-app-meta-data-14] (16 pages) - BGP UPDATE for SDWAN Edge Discovery [draft-dunbar-idr-sdwan-edge-discovery-04] (29 pages) - Experimental BGP Flow Specification Extensions [draft-eddy-idr-flowspec-exp-00] (20 pages) - BGP Flow Specification Packet-Rate Action [draft-eddy-idr-flowspec-packet-rate-00] (4 pages) - BGP Link-State extensions for Segment Routing [draft-gredler-idr-bgp-ls-segment-routing-ext-04] (35 pages) - BGP Cease Notification Subcode For BFD [draft-haas-idr-bfd-subcode-00] (5 pages) - Interoperability Procedures for BGP Routes with Color [draft-haas-idr-bgp-diffract-00] (19 pages) - Dissemination of Flow Specification Rules for L2 VPN [draft-hao-idr-flowspec-evpn-02] (10 pages) - Dissemination of Flow Specification Rules for NVO3 [draft-hao-idr-flowspec-nvo3-03] (9 pages) - BGP Flow-Spec Redirect to Tunnel Action [draft-hao-idr-flowspec-redirect-tunnel-01] (9 pages) - Distribution of TRILL Link-State using BGP [draft-hao-idr-ls-trill-02] (12 pages) - An Information Model for Basic Network Policy and Filter Rules [draft-hares-idr-flowspec-combo-01] (45 pages) - BGP Flow Specification Version 2 [draft-hares-idr-flowspec-v2-05] (68 pages) - A BGP/IDRP Route Server alternative to a full mesh routing [draft-haskin-bgp-idrp-mesh-routing-00] (16 pages) - Advertising p2mp policies in BGP [draft-hb-idr-sr-p2mp-policy-05] (19 pages) - BGP-LS Extensions for IS-IS Flood Reflectors [draft-head-idr-bgp-ls-isis-fr-01] (5 pages) - IANA Registrations for the BGP Finite State Machine (FSM) [draft-hhp-idr-bgp-fsm-iana-01] (8 pages) - Dissemination of Flow Specification Rules [draft-hr-idr-rfc5575bis-03] (30 pages) - BGP Provisioned IPsec Tunnel Configuration [draft-hujun-idr-bgp-ipsec-02] (15 pages) - BGP Provisioned IPsec Transport Mode Protected Tunnel Configuration [draft-hujun-idr-bgp-ipsec-transport-mode-00] (7 pages) - BGP Protocol Analysis [draft-ietf-bgp-analysis-00] (8 pages) - Application of the Border Gateway Protocol in the Internet [draft-ietf-bgp-application-03] (19 pages) - Border Gateway Protocol 3 (BGP-3) [draft-ietf-bgp-bgp3-00] (35 pages) - A Border Gateway Protocol 4 (BGP-4) [draft-ietf-bgp-bgp4-09] (56 pages) - BGP-4 Protocol Document Roadmap and Implementation Experience [draft-ietf-bgp-bgp4-implement-01] (4 pages) - Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol [draft-ietf-bgp-defaultroute-01] (2 pages) - Experience with the BGP Protocol [draft-ietf-bgp-experience-00] (9 pages) - Application of the Border Gateway Protocol and IDRP for IP in the Internet [draft-ietf-bgp-idrp-usage-00] (21 pages) - Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2 [draft-ietf-bgp-mibv4-05] (21 pages) - IP Multicast Communications Using BGP [draft-ietf-bgp-multicast-02] (10 pages) - Border Gateway Protocol NEXT-HOP-SNPA Attribute [draft-ietf-bgp-nexthop-01] (3 pages) - BGP OSPF Interaction [draft-ietf-bgp-ospfinteract-06] (14 pages) - Application of the Border Gateway Protocol in the Internet [draft-ietf-bgp-usage-01] (13 pages) - BGP Extension for 5G Edge Service Metadata [draft-ietf-idr-5g-edge-service-metadata-23] (34 pages) - Advertisement of Multiple Paths in BGP [draft-ietf-idr-add-paths-15] (8 pages) - Best Practices for Advertisement of Multiple Paths in IBGP [draft-ietf-idr-add-paths-guidelines-08] (25 pages) - Advertisement of Multiple Paths in BGP: Implementation Report [draft-ietf-idr-add-paths-implementation-00] (16 pages) - BGP Advisory Message [draft-ietf-idr-advisory-00] (7 pages) - A Framework for Inter-Domain Route Aggregation [draft-ietf-idr-aggregation-framework-04] (13 pages) - Route Aggregation Tutorial [draft-ietf-idr-aggregation-tutorial-01] (8 pages) - The Accumulated IGP Metric Attribute for BGP [draft-ietf-idr-aigp-18] (15 pages) - Codification of AS 0 Processing [draft-ietf-idr-as0-06] (5 pages) - BGP Support for Four-octet AS Number Space [draft-ietf-idr-as4bytes-13] (10 pages) - Generic Subtype for BGP Four-octet AS specific extended community [draft-ietf-idr-as4octet-extcomm-generic-subtype-10] (6 pages) - Using a Dedicated AS for Sites Homed to a Single Provider [draft-ietf-idr-as-dedicated-00] (6 pages) - Autonomous System (AS) Number Reservation for Documentation Use [draft-ietf-idr-as-documentation-reservation-00] (4 pages) - The AS_HOPCOUNT Path Attribute [draft-ietf-idr-as-hopcount-00] (16 pages) - Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute [draft-ietf-idr-as-migration-06] (16 pages) - The AS_PATHLIMIT Path Attribute [draft-ietf-idr-as-pathlimit-03] (16 pages) - AS Path Based Outbound Route Filter for BGP-4 [draft-ietf-idr-aspath-orf-13] (7 pages) - Autonomous System (AS) Reservation for Private Use [draft-ietf-idr-as-private-reservation-05] (4 pages) - Textual Representation of Autonomous System (AS) Numbers [draft-ietf-idr-as-representation-01] (3 pages) - Guidelines for creation, selection, and registration of an Autonomous System (AS) [draft-ietf-idr-autosys-guide-03] (10 pages) - Avoid BGP Best Path Transitions from One External to Another [draft-ietf-idr-avoid-transition-05] (6 pages) - Advertisement of the best external route in BGP [draft-ietf-idr-best-external-05] (21 pages) - A BGP Cease NOTIFICATION Subcode for Bidirectional Forwarding Detection (BFD) [draft-ietf-idr-bfd-subcode-05] (5 pages) - A Border Gateway Protocol 4 (BGP-4) [draft-ietf-idr-bgp4-26] (104 pages) - BGP-4 Protocol Analysis [draft-ietf-idr-bgp4-analysis-00] (10 pages) - Capabilities Advertisement with BGP-4 [draft-ietf-idr-bgp4-cap-neg-05] (5 pages) - Experience with the BGP-4 protocol [draft-ietf-idr-bgp4-experience-00] (9 pages) - Experience with the BGP-4 Protocol [draft-ietf-idr-bgp4-experience-protocol-05] (19 pages) - Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing [draft-ietf-idr-bgp4-ipv6-01] (5 pages) - Definitions of Managed Objects for BGP-4 [draft-ietf-idr-bgp4-mib-15] (32 pages) - Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), Second Version [draft-ietf-idr-bgp4-mibv2-15] (45 pages) - Definitions of Textual Conventions for the Management of the Fourth Version of Border Gateway Protocol (BGP-4) [draft-ietf-idr-bgp4-mibv2-tc-mib-05] (6 pages) - Multiprotocol Extensions for BGP-4 [draft-ietf-idr-bgp4-multiprotocol-01] (9 pages) - Multiprotocol Extensions for BGP-4 [draft-ietf-idr-bgp4-multiprotocol-v2-04] (11 pages) - Operational Experience with the BGP-4 protocol [draft-ietf-idr-bgp4-op-experience-02] (9 pages) - BGP4/IDRP for IP---OSPF Interaction [draft-ietf-idr-bgp4ospf-interact-07] (19 pages) - BGP-4 Requirement Satisfaction Report [draft-ietf-idr-bgp4-stdreport1-02] (3 pages) - BGP-4 Protocol Analysis [draft-ietf-idr-bgp-analysis-07] (16 pages) - Constrain Attribute announcement within BGP [draft-ietf-idr-bgp-attribute-announcement-03] (9 pages) - Requirements and Considerations in BGP Peer Auto-Configuration [draft-ietf-idr-bgp-autoconf-considerations-02] (19 pages) - BGP Bestpath Selection Criteria Enhancement [draft-ietf-idr-bgp-bestpath-selection-criteria-12] (9 pages) - BGP BFD Strict-Mode [draft-ietf-idr-bgp-bfd-strict-mode-13] (23 pages) - BGP Color-Aware Routing (CAR) [draft-ietf-idr-bgp-car-10] (92 pages) - BGP Classful Transport Planes [draft-ietf-idr-bgp-classful-transport-planes-01] (37 pages) - Autonomous System Confederations for BGP [draft-ietf-idr-bgp-confed-00] (7 pages) - Autonomous System Confederations for BGP [draft-ietf-idr-bgp-confed-rfc1965bis-01] (11 pages) - BGP Classful Transport Planes [draft-ietf-idr-bgp-ct-33] (75 pages) - BGP CT - Adaptation to SRv6 dataplane [draft-ietf-idr-bgp-ct-srv6-05] (20 pages) - Destination Preference Attribute for BGP [draft-ietf-idr-bgp-dpa-05] (4 pages) - Enhanced Route Refresh Capability for BGP-4 [draft-ietf-idr-bgp-enhanced-route-refresh-10] (8 pages) - BGP Extended Communities Attribute [draft-ietf-idr-bgp-ext-communities-09] (12 pages) - BGP Extended Community Registries Update [draft-ietf-idr-bgp-ext-com-registry-05] (5 pages) - Extended Message Support for BGP [draft-ietf-idr-bgp-extended-messages-36] (7 pages) - Carrying Label Information for BGP FlowSpec [draft-ietf-idr-bgp-flowspec-label-02] (10 pages) - Revised Validation Procedure for BGP Flow Specifications [draft-ietf-idr-bgp-flowspec-oid-15] (12 pages) - IANA Registrations for the BGP Finite State Machine (FSM) [draft-ietf-idr-bgp-fsm-iana-00] (8 pages) - BGP Route Reflector with Next Hop Self [draft-ietf-idr-bgp-fwd-rr-02] (9 pages) - Accumulated Metric in NHC attribute [draft-ietf-idr-bgp-generic-metric-00] (22 pages) - Notification Message Support for BGP Graceful Restart [draft-ietf-idr-bgp-gr-notification-16] (10 pages) - BGP Graceful Restart - Implementation Survey [draft-ietf-idr-bgp-gr-survey-01] (10 pages) - Autonomous-System-Wide Unique BGP Identifier for BGP-4 [draft-ietf-idr-bgp-identifier-14] (4 pages) - Advertising In-situ Flow Information Telemetry (IFIT) Capabilities in BGP [draft-ietf-idr-bgp-ifit-capabilities-05] (11 pages) - BGP-4 Implementation Report [draft-ietf-idr-bgp-implementation-02] (97 pages) - IPv6 Extensions for Route Target Distribution [draft-ietf-idr-bgp-ipv6-rt-constrain-12] (6 pages) - Issues in Revising BGP-4 (RFC1771 to RFC4271) [draft-ietf-idr-bgp-issues-06] (170 pages) - Application-Specific Link Attributes Advertisement Using the Border Gateway Protocol - Link State (BGP-LS) [draft-ietf-idr-bgp-ls-app-specific-attr-16] (12 pages) - BGP Link-State Extensions for BGP-only Fabric [draft-ietf-idr-bgp-ls-bgp-only-fabric-03] (24 pages) - Border Gateway Protocol - Link State (BGP-LS) Extensions for Flexible Algorithm Advertisement [draft-ietf-idr-bgp-ls-flex-algo-12] (14 pages) - BGP-LS Extension for Inter-AS Topology Retrieval [draft-ietf-idr-bgpls-inter-as-topology-ext-16] (12 pages) - BGP-LS Extensions for IS-IS Flood Reflection [draft-ietf-idr-bgp-ls-isis-flood-reflection-04] (6 pages) - Signaling Maximum Transmission Unit (MTU) using BGP-LS [draft-ietf-idr-bgp-ls-link-mtu-07] (9 pages) - Advertising Node Admin Tags in BGP Link-State Advertisements [draft-ietf-idr-bgp-ls-node-admin-tag-extension-03] (11 pages) - Updates to the Allocation Policy for the Border Gateway Protocol - Link State (BGP-LS) Parameters Registries [draft-ietf-idr-bgp-ls-registry-06] (5 pages) - BGP - Link State (BGP-LS) Extensions for Seamless Bidirectional Forwarding Detection (S-BFD) [draft-ietf-idr-bgp-ls-sbfd-extensions-10] (6 pages) - Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering [draft-ietf-idr-bgpls-segment-routing-epe-19] (15 pages) - Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing [draft-ietf-idr-bgp-ls-segment-routing-ext-18] (27 pages) - Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State [draft-ietf-idr-bgp-ls-segment-routing-msd-18] (9 pages) - Signalling ERLD using BGP-LS [draft-ietf-idr-bgp-ls-segment-routing-rld-05] (6 pages) - Advertisement of Segment Routing Policies using BGP Link-State [draft-ietf-idr-bgp-ls-sr-policy-05] (51 pages) - SR Policies Extensions for Network Resource Partition in BGP-LS [draft-ietf-idr-bgp-ls-sr-policy-nrp-00] (8 pages) - SR Policies Extensions for Path Segment and Bidirectional Path in BGP-LS [draft-ietf-idr-bgp-ls-sr-policy-path-segment-07] (12 pages) - BGP-LS Advertisement of Segment Routing Service Segments [draft-ietf-idr-bgp-ls-sr-service-segments-02] (12 pages) - Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6) [draft-ietf-idr-bgpls-srv6-ext-14] (23 pages) - Applicability of BGP-LS with Multi-Topology (MT) for Segment Routing based Network Resource Partitions (NRP) [draft-ietf-idr-bgpls-sr-vtn-mt-06] (10 pages) - Advertisement of Traffic Engineering Paths using BGP Link-State [draft-ietf-idr-bgp-ls-te-path-01] (22 pages) - BGP AS Path Metrics [draft-ietf-idr-bgp-metrics-00] (8 pages) - BGP-4 MIB Implementation Survey [draft-ietf-idr-bgp-mibagent-survey-02] (37 pages) - YANG Model for Border Gateway Protocol (BGP-4) [draft-ietf-idr-bgp-model-17] (225 pages) - Multisession BGP [draft-ietf-idr-bgp-multisession-07] (19 pages) - Carrying next-hop cost information in BGP [draft-ietf-idr-bgp-nh-cost-03] (10 pages) - Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages [draft-ietf-idr-bgp-open-policy-24] (12 pages) - BGP Optimal Route Reflection (BGP ORR) [draft-ietf-idr-bgp-optimal-route-reflection-28] (9 pages) - Address-Prefix-Based Outbound Route Filter for BGP-4 [draft-ietf-idr-bgp-prefix-orf-05] (6 pages) - Segment Routing Prefix Segment Identifier Extensions for BGP [draft-ietf-idr-bgp-prefix-sid-27] (15 pages) - Route Refresh Capability for BGP-4 [draft-ietf-idr-bgp-route-refresh-01] (4 pages) - Border Gateway Protocol 4 (BGP-4) Send Hold Timer [draft-ietf-idr-bgp-sendholdtimer-15] (10 pages) - BGP Extension for SR-MPLS Entropy Label Position [draft-ietf-idr-bgp-srmpls-elp-01] (10 pages) - Segment Routing Segment Types Extensions for BGP SR Policy [draft-ietf-idr-bgp-sr-segtypes-ext-04] (17 pages) - Protection of BGP Sessions via the TCP MD5 Signature Option [draft-ietf-idr-bgp-tcp-md5-00] (6 pages) - Protection of BGP Sessions via the TCP MD5 Signature Option [draft-ietf-idr-bgp-tcp-md5bad-01] (5 pages) - BGP Security Vulnerabilities Analysis [draft-ietf-idr-bgp-vuln-01] (22 pages) - BGP for BIER-TE Path [draft-ietf-idr-bier-te-path-04] (15 pages) - Revision to Capability Codes Registration Procedures [draft-ietf-idr-capabilities-registry-change-09] (5 pages) - Subcodes for BGP Cease Notification Message [draft-ietf-idr-cease-subcode-07] (6 pages) - BGP Communities Attribute [draft-ietf-idr-communities-00] (5 pages) - An Application of the BGP Community Attribute in Multi-home Routing [draft-ietf-idr-community-00] (10 pages) - An Application of the BGP Community Attribute in Multi-home Routing [draft-ietf-idr-community-usage-00] (9 pages) - BGP Colored Prefix Routing (CPR) for SRv6 based Services [draft-ietf-idr-cpr-04] (15 pages) - BGP Custom Decision Process [draft-ietf-idr-custom-decision-08] (11 pages) - Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243 [draft-ietf-idr-deprecate-30-31-129-02] (3 pages) - Deprecation of BGP OPEN Message Error subcodes 8, 9, and 10. [draft-ietf-idr-deprecate-8-9-10-00] (3 pages) - Deprecation of AS_SET and AS_CONFED_SET in BGP [draft-ietf-idr-deprecate-as-set-confed-set-16] (14 pages) - Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP [draft-ietf-idr-deprecate-as-sets-06] (5 pages) - Deprecation of BGP Path Attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID [draft-ietf-idr-deprecate-dpa-etal-00] (3 pages) - Application of the BGP Destination Preference Attribute in Implementing Symmetric Routing [draft-ietf-idr-dpa-application-02] (8 pages) - Dynamic Capability for BGP-4 [draft-ietf-idr-dynamic-cap-16] (9 pages) - Distribution of Traffic Engineering Extended Administrative Groups Using the Border Gateway Protocol - Link State (BGP-LS) [draft-ietf-idr-eag-distribution-19] (7 pages) - BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute [draft-ietf-idr-encaps-safi-00] (13 pages) - Accelerated Routing Convergence for BGP Graceful Restart [draft-ietf-idr-enhanced-gr-06] (9 pages) - Enhanced Route Refresh Implementation Report [draft-ietf-idr-enhanced-refresh-impl-00] (5 pages) - BGP Next Hop Dependent Capabilities Attribute [draft-ietf-idr-entropy-label-14] (17 pages) - Revised Error Handling for BGP UPDATE Messages [draft-ietf-idr-error-handling-19] (19 pages) - IANA Registries for BGP Extended Communities [draft-ietf-idr-extcomm-iana-02] (16 pages) - Extended Optional Parameters Length for BGP OPEN Message [draft-ietf-idr-ext-opt-param-13] (6 pages) - Dissemination of Flow Specification Rules [draft-ietf-idr-flow-spec-09] (22 pages) - Applying BGP flowspec rules on a specific interface set [draft-ietf-idr-flowspec-interfaceset-05] (9 pages) - BGP Dissemination of L2 Flow Specification Rules [draft-ietf-idr-flowspec-l2vpn-23] (20 pages) - BGP Flow Specification Filter for MPLS Label [draft-ietf-idr-flowspec-mpls-match-02] (8 pages) - BGP Flowspec for IETF Network Slice Traffic Steering [draft-ietf-idr-flowspec-network-slice-ts-02] (10 pages) - BGP Dissemination of Flow Specification Rules for Tunneled Traffic [draft-ietf-idr-flowspec-nvo3-20] (20 pages) - BGP Flow Specification Packet-Rate Action [draft-ietf-idr-flowspec-packet-rate-01] (5 pages) - Flowspec Indirection-id Redirect [draft-ietf-idr-flowspec-path-redirect-12] (11 pages) - BGP Flow-Spec Redirect-to-IP Action [draft-ietf-idr-flowspec-redirect-ip-03] (9 pages) - Clarification of the Flowspec Redirect Extended Community [draft-ietf-idr-flowspec-redirect-rt-bis-05] (7 pages) - BGP Flow Specification for SRv6 [draft-ietf-idr-flowspec-srv6-05] (10 pages) - BGP Flow Specification Version 2 [draft-ietf-idr-flowspec-v2-04] (73 pages) - Dissemination of Flow Specification Rules for IPv6 [draft-ietf-idr-flow-spec-v6-22] (19 pages) - Subcodes for BGP Finite State Machine Error [draft-ietf-idr-fsm-subcode-03] (5 pages) - BGP Flow Specification Version 2 - for Basic IP [draft-ietf-idr-fsv2-ip-basic-00] (57 pages) - Inter-Domain Routing Protocol, Version 2 [draft-ietf-idr-idrp2-00] (110 pages) - IDRP for IP v4 and v6 [draft-ietf-idr-idrp-v4v6-02] (20 pages) - Internet Exchange BGP Route Server [draft-ietf-idr-ix-bgp-route-server-12] (12 pages) - Internet Exchange Route Server - Implementation Report [draft-ietf-idr-ix-bgp-route-server-implementation-00] (5 pages) - BGP Large Communities Attribute [draft-ietf-idr-large-community-12] (8 pages) - Reservation of Last Autonomous System (AS) Numbers [draft-ietf-idr-last-as-reservation-07] (5 pages) - Automatic Route Target Filtering for legacy PEs [draft-ietf-idr-legacy-rtc-08] (10 pages) - BGP Link Bandwidth Extended Community [draft-ietf-idr-link-bandwidth-08] (5 pages) - Long-Lived Graceful Restart for BGP [draft-ietf-idr-long-lived-gr-06] (20 pages) - North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP [draft-ietf-idr-ls-distribution-13] (48 pages) - BGP Link-State Information Distribution Implementation Report [draft-ietf-idr-ls-distribution-impl-04] (15 pages) - Distribution of TRILL Link-State using BGP [draft-ietf-idr-ls-trill-05] (16 pages) - Key Management Considerations for the TCP MD5 Signature Option [draft-ietf-idr-md5-keys-00] (7 pages) - Multicast Distribution Control Signaling [draft-ietf-idr-mdcs-00] (9 pages) - Multicast Distribution Reachability Signaling [draft-ietf-idr-mdrs-00] (6 pages) - MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement [draft-ietf-idr-mpbgp-extension-4map6-02] (17 pages) - Revisions to the BGP 'Minimum Route Advertisement Interval' [draft-ietf-idr-mrai-dep-04] (4 pages) - BGP MultiNexthop Attribute [draft-ietf-idr-multinexthop-attribute-01] (54 pages) - BGP Next-Hop dependent capabilities [draft-ietf-idr-next-hop-capability-08] (13 pages) - BGP Extended Community for Identifying the Target Nodes [draft-ietf-idr-node-target-ext-comm-02] (7 pages) - BGP OPERATIONAL Message [draft-ietf-idr-operational-message-00] (29 pages) - Revised Error Handling for BGP UPDATE Messages [draft-ietf-idr-optional-transitive-04] (10 pages) - Performance-based BGP Routing Mechanism [draft-ietf-idr-performance-routing-04] (11 pages) - Configuring IDRP Confederations [draft-ietf-idr-rdc-config-01] (5 pages) - Registered Wide BGP Community Values [draft-ietf-idr-registered-wide-bgp-communities-02] (18 pages) - Assigned BGP extended communities [draft-ietf-idr-reserved-extended-communities-09] (6 pages) - Graceful Restart Mechanism for BGP [draft-ietf-idr-restart-13] (15 pages) - Reclassification of RFC 1863 to Historic [draft-ietf-idr-rfc1863-historic-00] (3 pages) - Protection of BGP Sessions via the TCP MD5 Signature Option [draft-ietf-idr-rfc2385bis-01] (6 pages) - BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) [draft-ietf-idr-rfc2796bis-02] (12 pages) - Capabilities Advertisement with BGP-4 [draft-ietf-idr-rfc2842bis-01] (6 pages) - Multiprotocol Extensions for BGP-4 [draft-ietf-idr-rfc2858bis-10] (12 pages) - Autonomous System Confederations for BGP [draft-ietf-idr-rfc3065bis-06] (14 pages) - Capabilities Advertisement with BGP-4 [draft-ietf-idr-rfc3392bis-05] (7 pages) - Multiprotocol Extensions for BGP-4 [draft-ietf-idr-rfc4760bis-03] (13 pages) - BGP Support for Four-Octet Autonomous System (AS) Number Space [draft-ietf-idr-rfc4893bis-07] (12 pages) - Dissemination of Flow Specification Rules [draft-ietf-idr-rfc5575bis-27] (36 pages) - Distribution of Link-State and Traffic Engineering Information Using BGP [draft-ietf-idr-rfc7752bis-17] (72 pages) - Extended BGP Administrative Shutdown Communication [draft-ietf-idr-rfc8203bis-08] (7 pages) - Making Route Flap Damping Usable [draft-ietf-idr-rfd-usable-04] (8 pages) - Extensions for Selective Updates in Inter Domain Routing [draft-ietf-idr-rifs-00] (9 pages) - BGP Route Flap Damping [draft-ietf-idr-route-damp-03] (37 pages) - Outbound Route Filtering Capability for BGP-4 [draft-ietf-idr-route-filter-17] (12 pages) - Methods for Detection and Mitigation of BGP Route Leaks [draft-ietf-idr-route-leak-detection-mitigation-11] (11 pages) - Border Gateway Protocol (BGP) Persistent Route Oscillation Condition [draft-ietf-idr-route-oscillation-00] (19 pages) - Solutions for BGP Persistent Route Oscillation [draft-ietf-idr-route-oscillation-stop-04] (9 pages) - BGP Route Reflection An alternative to full mesh IBGP [draft-ietf-idr-route-reflect-02] (7 pages) - BGP Route Reflection - An Alternative to Full Mesh IBGP [draft-ietf-idr-route-reflect-v2-03] (11 pages) - BGP Extensions for Routing Policy Distribution (RPD) [draft-ietf-idr-rpd-19] (22 pages) - Making Route Servers Aware of Data Link Failures at IXPs [draft-ietf-idr-rs-bfd-09] (14 pages) - Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios [draft-ietf-idr-rtc-hierarchical-rr-04] (6 pages) - Route Target Constrained Distribution of Routes with no Route Targets [draft-ietf-idr-rtc-no-rt-12] (7 pages) - Extended Communities Derived from Route Targets [draft-ietf-idr-rt-derived-community-02] (7 pages) - BGP UPDATE for SD-WAN Edge Discovery [draft-ietf-idr-sdwan-edge-discovery-16] (40 pages) - Advertising Segment Routing Policies in BGP [draft-ietf-idr-segment-routing-te-policy-26] (39 pages) - BGP Administrative Shutdown Communication [draft-ietf-idr-shutdown-10] (6 pages) - Inter-domain Traffic Conditioning Agreement (TCA) Exchange Attribute [draft-ietf-idr-sla-exchange-13] (32 pages) - Inter-domain SLA Exchange Implementation Report-02 [draft-ietf-idr-sla-exchange-impl-02] (5 pages) - Segment Routing BGP Egress Peer Engineering over Layer 2 Bundle Members [draft-ietf-idr-sr-epe-over-l2bundle-00] (11 pages) - Advertising p2mp policies in BGP [draft-ietf-idr-sr-p2mp-policy-00] (20 pages) - BGP SR Policy Extensions to Enable IFIT [draft-ietf-idr-sr-policy-ifit-08] (16 pages) - BGP SR Policy Extensions for metric [draft-ietf-idr-sr-policy-metric-01] (8 pages) - BGP SR Policy Extensions for Network Resource Partition [draft-ietf-idr-sr-policy-nrp-01] (8 pages) - Segment Routing Path MTU in BGP [draft-ietf-idr-sr-policy-path-mtu-09] (11 pages) - SR Policy Extensions for Path Segment and Bidirectional Path [draft-ietf-idr-sr-policy-path-segment-12] (13 pages) - Advertising Segment Routing Policies in BGP [draft-ietf-idr-sr-policy-safi-06] (41 pages) - BGP SR Policy Extensions for Segment List Identifier [draft-ietf-idr-sr-policy-seglist-id-02] (8 pages) - Advertising SID Algorithm Information in BGP [draft-ietf-idr-sr-te-policy-attr-00] (12 pages) - Current Practice of Implementing Symmetric Routing and Load Sharing in the Multi-Provider Internet [draft-ietf-idr-symm-multi-prov-02] (13 pages) - Distribution of Traffic Engineering (TE) Policies and State using BGP-LS [draft-ietf-idr-te-lsp-distribution-19] (58 pages) - BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions [draft-ietf-idr-te-pm-bgp-18] (10 pages) - Traffic Steering using BGP FlowSpec with SR Policy [draft-ietf-idr-ts-flowspec-srv6-policy-04] (14 pages) - The BGP Tunnel Encapsulation Attribute [draft-ietf-idr-tunnel-encaps-22] (41 pages) - Advertising an IPv4 NLRI with an IPv6 Next Hop [draft-ietf-idr-v4nlri-v6nh-01] (10 pages) - VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4 [draft-ietf-idr-vpn-prefix-orf-07] (26 pages) - BGP Community Container Attribute [draft-ietf-idr-wide-bgp-communities-11] (25 pages) - IDRP for SIP [draft-ietf-ipidrp-sip-01] (9 pages) - Border Gateway Protocol (BGP) [draft-ietf-iwg-bgp-00] (29 pages) - Application of the Border Gateway Protocol in the Internet [draft-ietf-iwg-bgpapplication-00] (23 pages) - Definitions of Managed Objects for the Border Gateway Protocol: Version 3 [draft-ietf-iwg-bgp-mib-02] (13 pages) - Internet Exchange Route Server - Implementation Report [draft-jasinska-ix-bgp-route-server-implementation-00] (5 pages) - Path validation toward BGP next-hop with AUTO-BFD [draft-jdurand-auto-bfd-00] (8 pages) - Traffic Steering using BGP Flowspec with SRv6 Policy [draft-jiang-idr-ts-flowspec-srv6-policy-07] (10 pages) - BGP Classful Transport Planes [draft-kaliraj-idr-bgp-classful-transport-planes-17] (37 pages) - BGP MultiNexthop Attribute [draft-kaliraj-idr-multinexthop-attribute-11] (52 pages) - Application Specific Attributes Advertisement with BGP Link-State [draft-ketant-idr-bgp-ls-app-specific-attr-01] (13 pages) - BGP Link-State Extensions for BGP-only Fabric [draft-ketant-idr-bgp-ls-bgp-only-fabric-05] (25 pages) - Flexible Algorithm Definition Advertisement with BGP Link-State [draft-ketant-idr-bgp-ls-flex-algo-01] (10 pages) - Distribution of Link-State and Traffic Engineering Information Using BGP [draft-ketant-idr-rfc7752bis-01] (58 pages) - Constrain Attribute announcement within BGP [draft-keyupate-idr-bgp-attribute-announcement-01] (9 pages) - Segment Routing Prefix SID extensions for BGP [draft-keyupate-idr-bgp-prefix-sid-05] (15 pages) - Deprecation of AS_SET and AS_CONFED_SET in BGP [draft-kumari-deprecate-as-set-confed-set-14] (6 pages) - Carrying Label Information for BGP FlowSpec [draft-liang-idr-bgp-flowspec-label-02] (9 pages) - BGP FlowSpec with Time Constraints [draft-liang-idr-bgp-flowspec-time-00] (9 pages) - BGP Link-State Extensions for Seamless BFD [draft-li-idr-bgp-ls-sbfd-extensions-03] (9 pages) - SR Policies Extensions for Path Segment and Bidirectional Path in BGP-LS [draft-li-idr-bgp-ls-sr-policy-path-segment-03] (10 pages) - BGP FlowSpec Redirect to Generalized Segment ID Action [draft-li-idr-flowspec-redirect-generalized-sid-00] (8 pages) - BGP Extensions for Routing Policy Distribution (RPD) [draft-li-idr-flowspec-rpd-05] (18 pages) - BGP Flow Specification for SRv6 [draft-li-idr-flowspec-srv6-07] (10 pages) - BGP Extensions for Service-Oriented MPLS Path Programming (MPP) [draft-li-idr-mpls-path-programming-04] (14 pages) - Segment Routing Path MTU in BGP [draft-li-idr-sr-policy-path-mtu-03] (8 pages) - SR Policy Extensions for Path Segment and Bidirectional Path [draft-li-idr-sr-policy-path-segment-01] (11 pages) - Segment Routing BGP Egress Peer Engineering over Layer 2 Bundle Members [draft-lin-idr-sr-epe-over-l2bundle-08] (11 pages) - BGP Extensions of SR Policy for Headend Behavior [draft-lin-idr-sr-policy-headend-behavior-04] (7 pages) - BGP SR Policy Extensions for Segment List Identifier [draft-lin-idr-sr-policy-seglist-id-05] (7 pages) - Applying BGP flowspec rules on a specific interface set [draft-litkowski-idr-flowspec-interfaceset-03] (13 pages) - Inter Domain considerations for Constrained Route distribution [draft-litkowski-idr-rtc-interas-01] (8 pages) - BGP BFD Strict-Mode [draft-merciaz-idr-bgp-bfd-strict-mode-02] (7 pages) - BGP Peer Auto-Configuration [draft-minto-idr-bgp-autodiscovery-01] (15 pages) - Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE) [draft-ooms-v6ops-bgp-tunnel-07] (14 pages) - Advertising SID Algorithm Information in BGP [draft-peng-idr-segment-routing-te-policy-attr-11] (12 pages) - Segment Routing Egress Peer Engineering BGP-LS Extensions [draft-previdi-idr-bgpls-segment-routing-epe-03] (17 pages) - Advertising Segment Routing Policies in BGP [draft-previdi-idr-segment-routing-te-policy-07] (30 pages) - Advertising Node Admin Tags in BGP Link-State Advertisements [draft-psarkar-idr-bgp-ls-node-admin-tag-extension-05] (11 pages) - BGP SR Policy Extensions to Enable IFIT [draft-qin-idr-sr-policy-ifit-04] (15 pages) - BGP Auto Discovery [draft-raszuk-idr-bgp-auto-discovery-08] (14 pages) - Registered Wide BGP Community Values [draft-raszuk-registered-wide-bgp-communities-00] (17 pages) - Wide BGP Communities Attribute [draft-raszuk-wide-bgp-communities-05] (23 pages) - Multicast Distribution Control Signaling [draft-rekhter-mdcs-01] (9 pages) - Multicast Distribution Reachability Signaling [draft-rekhter-mdrs-01] (6 pages) - Advertisement of Multiple Paths in BGP: Implementation Report [draft-retana-idr-add-paths-implementation-01] (16 pages) - Route Target Constrained Distribution of Routes with no Route Targets [draft-rosen-idr-rtc-no-rt-01] (6 pages) - Using the BGP Tunnel Encapsulation Attribute without the BGP Encapsulation SAFI [draft-rosen-idr-tunnel-encaps-03] (29 pages) - Inbound BGP Maximum Prefix Limits [draft-sas-idr-maxprefix-inbound-05] (8 pages) - Revision to Capability Codes Registration Procedures [draft-scudder-idr-capabilities-registry-change-02] (4 pages) - BGP Entropy Label Capability, Version 3 [draft-scudder-idr-entropy-label-01] (9 pages) - Deprecation of BGP Path Attribute values 30, 31, 129, 241, 242, and 234 [draft-snijders-idr-deprecate-30-31-129-02] (3 pages) - Extended BGP Administrative Shutdown Communication [draft-snijders-idr-rfc8203bis-01] (7 pages) - The Shutdown Communication BGP Cease Notification Message subcode [draft-snijders-idr-shutdown-00] (6 pages) - Border Gateway Protocol 4 (BGP-4) Send Hold Timer [draft-spaghetti-idr-bgp-sendholdtimer-09] (8 pages) - Deprecation of BGP OPEN Message Error subcodes 8, 9, and 10. [draft-spaghetti-idr-deprecate-8-9-10-01] (3 pages) - Methods for Detection and Mitigation of BGP Route Leaks [draft-sriram-idr-route-leak-detection-mitigation-01] (17 pages) - Generic Metric for the AIGP attribute [draft-ssangli-idr-bgp-generic-metric-aigp-08] (17 pages) - Signaling Maximum SID Depth using Border Gateway Protocol Link-State [draft-tantsura-idr-bgp-ls-segment-routing-msd-05] (7 pages) - Support for Long-lived BGP Graceful Restart [draft-uttaro-idr-bgp-persistence-05] (25 pages) - Signalling ERLD using BGP-LS [draft-vandevelde-idr-bgp-ls-segment-routing-rld-03] (6 pages) - Flowspec Indirection-id Redirect [draft-vandevelde-idr-flowspec-path-redirect-03] (12 pages) - BGP Remote-Next-Hop [draft-vandevelde-idr-remote-next-hop-09] (17 pages) - BGP Persistent Route Oscillation Solutions [draft-walton-bgp-route-oscillation-stop-09] (9 pages) - BGP Extension for Advertising In-situ Flow Information Telemetry (IFIT) Capabilities [draft-wang-idr-bgp-ifit-capabilities-05] (10 pages) - BGP-LS Extension for Inter-AS Topology Retrieval [draft-wang-idr-bgpls-inter-as-topology-ext-02] (10 pages) - BGP Colored Prefix Routing (CPR) for SRv6 based Services [draft-wang-idr-cpr-03] (13 pages) - Distribution of MPLS-TE Extended admin Group Using BGP [draft-wang-idr-eag-distribution-02] (5 pages) - Route Distinguisher Outbound Route Filter (RD-ORF) for BGP-4 [draft-wang-idr-rd-orf-08] (13 pages) - VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4 [draft-wang-idr-vpn-prefix-orf-06] (22 pages) - BGP Extensions for IDs Allocation [draft-wu-idr-bgp-segment-allocation-ext-14] (16 pages) - A YANG Data Model for Flow Specification [draft-wu-idr-flowspec-yang-cfg-02] (32 pages) - BGP-LS with Multi-topology for Segment Routing based Virtual Transport Networks [draft-xie-idr-bgpls-sr-vtn-mt-04] (11 pages) - MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement [draft-xie-idr-mpbgp-extension-4map6-09] (16 pages) - BGP Extensions for BIER [draft-xu-idr-bier-extensions-02] (7 pages) - BGP Neighbor Discovery [draft-xu-idr-neighbor-autodiscovery-12] (33 pages) - Performance-based BGP Routing Mechanism [draft-xu-idr-performance-routing-01] (9 pages) - Route Leak Prevention using Roles in Update and Open messages [draft-ymbk-idr-bgp-open-policy-03] (10 pages) - Layer-3 Neighbor Discovery [draft-ymbk-idr-l3nd-06] (28 pages) - L3ND Upper-Layer Protocol Configuration [draft-ymbk-idr-l3nd-ulpc-07] (9 pages) - Making Route Servers Aware of Data Link Failures at IXPs [draft-ymbk-idr-rs-bfd-01] (8 pages) - BGP Flow Specification Filter for MPLS Label [draft-yong-idr-flowspec-mpls-match-00] (8 pages) - BGP SR Policy Extensions for metric [draft-zhang-idr-sr-policy-metric-05] (8 pages) - BGP Extension for SR-MPLS Entropy Label Position [draft-zhou-idr-bgp-srmpls-elp-08] (9 pages) - Signaling Maximum Transmission Unit (MTU) using BGP-LS [draft-zhu-idr-bgp-ls-path-mtu-05] (9 pages) - Extended Communities Derived from Route Targets [draft-zzhang-idr-rt-derived-community-04] (7 pages) - MPLS Label Stacks in Tunnel Encapsulation Attribute [draft-zzhang-idr-tunnel-encapsulation-label-stack-02] (8 pages) Requests for Comments: RFC1163: Border Gateway Protocol (BGP) (29 pages) * Obsoletes RFC1267 RFC1164: Application of the Border Gateway Protocol in the Internet (23 pages) * Obsoletes RFC1268 RFC1265: BGP Protocol Analysis (8 pages) RFC1266: Experience with the BGP Protocol (9 pages) RFC1267: Border Gateway Protocol 3 (BGP-3) (35 pages) RFC1268: Application of the Border Gateway Protocol in the Internet (13 pages) * Obsoletes RFC1655 RFC1269: Definitions of Managed Objects for the Border Gateway Protocol: Version 3 (13 pages) * Obsoletes RFC4273 RFC1364: BGP OSPF Interaction (14 pages) * Obsoletes RFC1403 RFC1397: Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol (2 pages) RFC1654: A Border Gateway Protocol 4 (BGP-4) (56 pages) * Obsoletes RFC1771 RFC1655: Application of the Border Gateway Protocol in the Internet (19 pages) * Obsoletes RFC1772 RFC1656: BGP-4 Protocol Document Roadmap and Implementation Experience (4 pages) * Obsoletes RFC1773 RFC1657: Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2 (21 pages) * Obsoletes RFC4273 RFC1745: BGP4/IDRP for IP---OSPF Interaction (19 pages) RFC1773: Experience with the BGP-4 protocol (9 pages) RFC1774: BGP-4 Protocol Analysis (10 pages) RFC1863: A BGP/IDRP Route Server alternative to a full mesh routing (16 pages) * Obsoletes RFC4223 RFC1930: Guidelines for creation, selection, and registration of an Autonomous System (AS) (10 pages) * Updates RFC6996 * Updates RFC7300 RFC1965: Autonomous System Confederations for BGP (7 pages) * Obsoletes RFC3065 RFC1966: BGP Route Reflection An alternative to full mesh IBGP (7 pages) * Obsoletes RFC4456 * Updates RFC2796 RFC1997: BGP Communities Attribute (5 pages) * Updates RFC7606 * Updates RFC8642 RFC1998: An Application of the BGP Community Attribute in Multi-home Routing (9 pages) RFC2270: Using a Dedicated AS for Sites Homed to a Single Provider (6 pages) RFC2283: Multiprotocol Extensions for BGP-4 (9 pages) * Obsoletes RFC2858 RFC2385: Protection of BGP Sessions via the TCP MD5 Signature Option (6 pages) * Obsoletes RFC5925 * Updates RFC6691 RFC2439: BGP Route Flap Damping (37 pages) RFC2519: A Framework for Inter-Domain Route Aggregation (13 pages) RFC2545: Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing (5 pages) RFC2796: BGP Route Reflection - An Alternative to Full Mesh IBGP (11 pages) * Obsoletes RFC4456 RFC2842: Capabilities Advertisement with BGP-4 (5 pages) * Obsoletes RFC3392 RFC2858: Multiprotocol Extensions for BGP-4 (11 pages) * Obsoletes RFC4760 RFC2918: Route Refresh Capability for BGP-4 (4 pages) * Updates RFC7313 RFC3065: Autonomous System Confederations for BGP (11 pages) * Obsoletes RFC5065 RFC3345: Border Gateway Protocol (BGP) Persistent Route Oscillation Condition (19 pages) RFC3392: Capabilities Advertisement with BGP-4 (6 pages) * Obsoletes RFC5492 RFC3562: Key Management Considerations for the TCP MD5 Signature Option (7 pages) RFC4223: Reclassification of RFC 1863 to Historic (3 pages) RFC4271: A Border Gateway Protocol 4 (BGP-4) (104 pages) * Updates RFC6286 * Updates RFC6608 * Updates RFC6793 * Updates RFC7607 * Updates RFC7606 * Updates RFC7705 * Updates RFC8212 * Updates RFC8654 * Updates RFC9072 RFC4272: BGP Security Vulnerabilities Analysis (22 pages) RFC4273: Definitions of Managed Objects for BGP-4 (32 pages) RFC4274: BGP-4 Protocol Analysis (16 pages) RFC4275: BGP-4 MIB Implementation Survey (37 pages) RFC4276: BGP-4 Implementation Report (97 pages) RFC4277: Experience with the BGP-4 Protocol (19 pages) RFC4360: BGP Extended Communities Attribute (12 pages) * Updates RFC7153 * Updates RFC7606 RFC4456: BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) (12 pages) * Updates RFC7606 RFC4486: Subcodes for BGP Cease Notification Message (6 pages) * Updates RFC8203 * Updates RFC9003 RFC4724: Graceful Restart Mechanism for BGP (15 pages) * Updates RFC8538 RFC4760: Multiprotocol Extensions for BGP-4 (12 pages) * Updates RFC7606 RFC4798: Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE) (14 pages) RFC4893: BGP Support for Four-octet AS Number Space (10 pages) * Obsoletes RFC6793 RFC5004: Avoid BGP Best Path Transitions from One External to Another (6 pages) RFC5065: Autonomous System Confederations for BGP (14 pages) RFC5291: Outbound Route Filtering Capability for BGP-4 (12 pages) RFC5292: Address-Prefix-Based Outbound Route Filter for BGP-4 (6 pages) RFC5396: Textual Representation of Autonomous System (AS) Numbers (3 pages) RFC5398: Autonomous System (AS) Number Reservation for Documentation Use (4 pages) RFC5492: Capabilities Advertisement with BGP-4 (7 pages) * Updates RFC8810 RFC5575: Dissemination of Flow Specification Rules (22 pages) * Updates RFC7674 * Obsoletes RFC8955 RFC6286: Autonomous-System-Wide Unique BGP Identifier for BGP-4 (4 pages) RFC6472: Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP (5 pages) RFC6608: Subcodes for BGP Finite State Machine Error (5 pages) RFC6793: BGP Support for Four-Octet Autonomous System (AS) Number Space (12 pages) RFC6938: Deprecation of BGP Path Attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID (3 pages) RFC6996: Autonomous System (AS) Reservation for Private Use (4 pages) RFC7153: IANA Registries for BGP Extended Communities (16 pages) * Updates RFC9184 RFC7196: Making Route Flap Damping Usable (8 pages) RFC7300: Reservation of Last Autonomous System (AS) Numbers (5 pages) RFC7311: The Accumulated IGP Metric Attribute for BGP (15 pages) RFC7313: Enhanced Route Refresh Capability for BGP-4 (8 pages) RFC7606: Revised Error Handling for BGP UPDATE Messages (19 pages) RFC7607: Codification of AS 0 Processing (5 pages) RFC7674: Clarification of the Flowspec Redirect Extended Community (7 pages) * Obsoletes RFC8955 RFC7705: Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute (16 pages) RFC7752: North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP (48 pages) * Updates RFC9029 * Obsoletes RFC9552 RFC7911: Advertisement of Multiple Paths in BGP (8 pages) RFC7947: Internet Exchange BGP Route Server (12 pages) RFC7964: Solutions for BGP Persistent Route Oscillation (9 pages) RFC8092: BGP Large Communities Attribute (8 pages) RFC8093: Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243 (3 pages) RFC8203: BGP Administrative Shutdown Communication (6 pages) * Obsoletes RFC9003 RFC8538: Notification Message Support for BGP Graceful Restart (10 pages) RFC8571: BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions (10 pages) RFC8654: Extended Message Support for BGP (7 pages) RFC8669: Segment Routing Prefix Segment Identifier Extensions for BGP (15 pages) RFC8810: Revision to Capability Codes Registration Procedures (5 pages) RFC8814: Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State (9 pages) RFC8955: Dissemination of Flow Specification Rules (36 pages) * Updates RFC8956 * Updates RFC9117 * Updates RFC9184 RFC8956: Dissemination of Flow Specification Rules for IPv6 (19 pages) RFC9003: Extended BGP Administrative Shutdown Communication (7 pages) RFC9012: The BGP Tunnel Encapsulation Attribute (41 pages) RFC9029: Updates to the Allocation Policy for the Border Gateway Protocol - Link State (BGP-LS) Parameters Registries (5 pages) * Obsoletes RFC9552 RFC9072: Extended Optional Parameters Length for BGP OPEN Message (6 pages) RFC9085: Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing (27 pages) * Updates RFC9356 RFC9086: Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering (15 pages) RFC9104: Distribution of Traffic Engineering Extended Administrative Groups Using the Border Gateway Protocol - Link State (BGP-LS) (7 pages) RFC9107: BGP Optimal Route Reflection (BGP ORR) (9 pages) RFC9117: Revised Validation Procedure for BGP Flow Specifications (12 pages) RFC9184: BGP Extended Community Registries Update (5 pages) RFC9234: Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages (12 pages) RFC9247: BGP - Link State (BGP-LS) Extensions for Seamless Bidirectional Forwarding Detection (S-BFD) (6 pages) RFC9294: Application-Specific Link Attributes Advertisement Using the Border Gateway Protocol - Link State (BGP-LS) (12 pages) RFC9351: Border Gateway Protocol - Link State (BGP-LS) Extensions for Flexible Algorithm Advertisement (14 pages) RFC9384: A BGP Cease NOTIFICATION Subcode for Bidirectional Forwarding Detection (BFD) (5 pages) RFC9494: Long-Lived Graceful Restart for BGP (20 pages) RFC9514: Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6) (23 pages) RFC9552: Distribution of Link-State and Traffic Engineering Information Using BGP (60 pages) Locator/ID Separation Protocol (lisp) ------------------------------------- Charter Last Modified: 2023-03-29 Current Status: Active Chairs: Luigi Iannone Padma Pillay-Esnault Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Jim Guichard Secretary: Alberto Rodriguez-Natal Mailing Lists: General Discussion: lisp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lisp Archive: https://mailarchive.ietf.org/arch/browse/lisp/ Description of Working Group: LISP supports an overlay routing architecture that decouples the routing locators and endpoint identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the endpoint space. LISP requires no changes to endpoints or routers that do not directly participate in the LISP deployment. LISP aims for an incrementally deployable protocol, so new features and services can be added easily and quickly to the network using overlays. The LISP WG is chartered to continue work on the LISP protocol, including minor extensions for which the working group has consensus on deeming them necessary for the use cases identified by the working group as main LISP applications. Such use cases have to be documented in an applicability document providing rationale for the work done. The working group will work on the following items: - Moving to Standard Track: The core specifications of LISP have been published as “Standard Track” ([RFC9300], [RFC9301]). The WG will continue the work of moving select specifications to “Standard Track” (e.g., LISP Canonical Address Format [RFC8060], LISP Multicast [RFC6831][RFC8378], etc). - Map Server Reliable Transport: LISP control plane messages are transported over UDP, however, in some cases, the use of a reliable transport protocol (such as TCP) is a better fit, since it actually helps reduce periodic signaling. - YANG Models: The management of LISP protocol and deployments including data models, OAM, as well as allowing for programmable management interfaces. - LISP for Traffic Engineering: Specifics on how to do traffic engineering on LISP deployments could be useful. For instance, encode in a mapping not only the routing locators associated to EIDs, but also an ordered set of re-encapsulating tunnel routers (RTRs) used to specify a path. - NAT-Traversal: LISP protocol extensions to support a NAT-traversal solution in deployments where LISP tunnel endpoints are separated from by a NAT (e.g., LISP mobile node). The LISP WG will collaborate with the TSVWG working on NAT-Traversal. - Privacy and Security: The WG will work on EID anonymity, VPN segmentation leveraging the Instance ID, and traffic anonymization. The reuse of existing mechanisms will be prioritized. - LISP External Connectivity: [RFC6832] defines the Proxy ETR element, to be used to connect LISP sites with non-LISP sites. However, LISP deployments could benefit from more advanced interworking, for instance by defining mechanisms to discover such external connectivity. - Mobility: Some LISP deployment scenarios include endpoints that move across different LISP xTRs and/or LISP xTRs that are themselves mobile. Support needs to be provided to achieve seamless connectivity. - LISP Applicability: LISP has proved to be a very flexible protocol that can be used in various use cases not considered during its design phase. [RFC7215], while remaining a good source of information, covers one single use case, which is no longer the main LISP application scenario. The LISP WG will document LISP deployments for the most recent and relevant use cases, so as to update and complement [RFC7215] as needed. Goals and Milestones: Nov 2023 - Submit LISP Name Encoding document to the IESG for consideration (Extension) [EXPERIMENTAL] Mar 2024 - Submit LISP Reliable Transport document to the IESG for consideration (Map Server Reliable Transport) [STANDARDS TRACK] Mar 2024 - Submit LISP YANG model document to the IESG for consideration (YANG Models) [EXPERIMENTAL] Mar 2024 - Submit LISP Traffic Engineering document to the IESG for consideration (Extension) [EXPERIMENTAL] Mar 2024 - Submit LISP Geo-Coordinates document to the IESG for consideration (Mobility) [EXPERIMENTAL] Nov 2024 - Submit LISP NAT Traversal document to the IESG for consideration (NAT Traversal) [STANDARDS TRACK] Nov 2024 - Submit LISP DDT bis document to the IESG for consideration [STANDARDS TRACK] Nov 2024 - Submit LISP LCAF bis document to the IESG for consideration [STANDARDS TRACK] Mar 2025 - Submit LISP Privacy and Security document(s) to the IESG for consideration (Privacy and Security) [EXPERIMENTAL] Mar 2025 - Submit LISP External Connectivity document(s) to the IESG for consideration (LISP External Connectivity) [EXPERIMENTAL] Jul 2025 - Submit LISP Mobility document(s) to the IESG for consideration (Mobility) [EXPERIMENTAL] Nov 2025 - Submit LISP Multicast document(s) to the IESG for consideration [STANDARDS TRACK] Mar 2026 - Submit LISP Applicability document(s) to the IESG for consideration (LISP Applicability) [INFORMATIONAL] Nov 2026 - Wrap-Up or recharter Internet-Drafts: - Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations [draft-boucadair-lisp-rfc8113bis-01] (5 pages) - An Architectural Perspective on the LISP Location-Identity Separation System [draft-chiappa-lisp-architecture-01] (19 pages) - An Introduction to the LISP Location-Identity Separation System [draft-chiappa-lisp-introduction-01] (29 pages) - LISP Configuration YANG Model [draft-ermagan-lisp-yang-01] (80 pages) - LISP Data-Plane Confidentiality [draft-farinacci-lisp-crypto-01] (10 pages) - LISP Control-Plane ECDSA Authentication and Authorization [draft-farinacci-lisp-ecdsa-auth-03] (17 pages) - LISP EID Anonymity [draft-farinacci-lisp-eid-anonymity-02] (9 pages) - LISP Geo-Coordinate Use-Cases [draft-farinacci-lisp-geo-15] (13 pages) - LISP Canonical Address Format (LCAF) [draft-farinacci-lisp-lcaf-10] (29 pages) - LISP Distinguished Name Encoding [draft-farinacci-lisp-name-encoding-15] (9 pages) - LISP Predictive RLOCs [draft-farinacci-lisp-predictive-rlocs-02] (13 pages) - The Locator/ID Separation Protocol (LISP) for Multicast Environments [draft-farinacci-lisp-rfc6831bis-02] (31 pages) - Signal-Free Locator/ID Separation Protocol (LISP) Multicast [draft-farinacci-lisp-rfc8378bis-00] (22 pages) - LISP Traffic Engineering Use-Cases [draft-farinacci-lisp-te-12] (18 pages) - Locator/ID Separation Protocol (LISP) Map-Versioning [draft-iannone-6834bis-00] (19 pages) - The Locator/ID Separation Protocol (LISP) [draft-ietf-lisp-24] (75 pages) - Locator/ID Separation Protocol (LISP) Map-Versioning [draft-ietf-lisp-6834bis-14] (15 pages) - Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT) [draft-ietf-lisp-alt-10] (25 pages) - An Architectural Perspective on the LISP Location-Identity Separation System [draft-ietf-lisp-architecture-00] (19 pages) - Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality [draft-ietf-lisp-crypto-10] (18 pages) - Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) [draft-ietf-lisp-ddt-09] (44 pages) - Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations [draft-ietf-lisp-deployment-12] (30 pages) - LISP Control-Plane ECDSA Authentication and Authorization [draft-ietf-lisp-ecdsa-auth-13] (18 pages) - LISP EID Anonymity [draft-ietf-lisp-eid-anonymity-16] (12 pages) - Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [draft-ietf-lisp-eid-block-13] (12 pages) - Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [draft-ietf-lisp-eid-block-mgmnt-07] (10 pages) - LISP L2/L3 EID Mobility Using a Unified Control Plane [draft-ietf-lisp-eid-mobility-14] (30 pages) - LISP Geo-Coordinate Use-Cases [draft-ietf-lisp-geo-08] (17 pages) - Locator/ID Separation Protocol (LISP) Generic Protocol Extension [draft-ietf-lisp-gpe-19] (14 pages) - Locator/ID Separation Protocol (LISP) Impact [draft-ietf-lisp-impact-05] (18 pages) - Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites [draft-ietf-lisp-interworking-06] (19 pages) - An Architectural Introduction to the Locator/ID Separation Protocol (LISP) [draft-ietf-lisp-introduction-15] (24 pages) - LISP Canonical Address Format (LCAF) [draft-ietf-lisp-lcaf-22] (36 pages) - The Locator/ID Separation Protocol Internet Groper (LIG) [draft-ietf-lisp-lig-06] (12 pages) - LISP Map Server Reliable Transport [draft-ietf-lisp-map-server-reliable-transport-04] (22 pages) - Locator/ID Separation Protocol (LISP) Map-Versioning [draft-ietf-lisp-map-versioning-09] (21 pages) - Locator/ID Separation Protocol (LISP) MIB [draft-ietf-lisp-mib-13] (66 pages) - LISP Mobile Node [draft-ietf-lisp-mn-15] (26 pages) - Locator/ID Separation Protocol (LISP) Map-Server Interface [draft-ietf-lisp-ms-16] (13 pages) - The Locator/ID Separation Protocol (LISP) for Multicast Environments [draft-ietf-lisp-multicast-14] (28 pages) - LISP Distinguished Name Encoding [draft-ietf-lisp-name-encoding-14] (14 pages) - Network-Hexagons:Geolocation Mapping Network Based On H3 and LISP [draft-ietf-lisp-nexagon-53] (32 pages) - An Architectural Perspective on the LISP Location-Identity Separation System [draft-ietf-lisp-perspective-00] (21 pages) - LISP Predictive RLOCs [draft-ietf-lisp-predictive-rlocs-14] (16 pages) - Publish/Subscribe Functionality for the Locator/ID Separation Protocol (LISP) [draft-ietf-lisp-pubsub-15] (18 pages) - The Locator/ID Separation Protocol (LISP) [draft-ietf-lisp-rfc6830bis-38] (33 pages) - The Locator/ID Separation Protocol (LISP) for Multicast Environments [draft-ietf-lisp-rfc6831bis-00] (31 pages) - Locator/ID Separation Protocol (LISP) Control Plane [draft-ietf-lisp-rfc6833bis-31] (42 pages) - Locator/ID Separation Protocol (LISP): Shared Extension Message and IANA Registry for Packet Type Allocations [draft-ietf-lisp-rfc8113bis-03] (5 pages) - Signal-Free Locator/ID Separation Protocol (LISP) Multicast [draft-ietf-lisp-rfc8378bis-00] (22 pages) - Locator/ID Separation Protocol Security (LISP-SEC) [draft-ietf-lisp-sec-29] (23 pages) - Signal-Free Locator/ID Separation Protocol (LISP) Multicast [draft-ietf-lisp-signal-free-multicast-09] (21 pages) - LISP Site External Connectivity [draft-ietf-lisp-site-external-connectivity-00] (7 pages) - LISP Traffic Engineering [draft-ietf-lisp-te-19] (20 pages) - Locator/ID Separation Protocol (LISP) Threat Analysis [draft-ietf-lisp-threats-15] (19 pages) - Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations [draft-ietf-lisp-type-iana-06] (6 pages) - Vendor-Specific LISP Canonical Address Format (LCAF) [draft-ietf-lisp-vendor-lcaf-12] (5 pages) - LISP Virtual Private Networks (VPNs) [draft-ietf-lisp-vpn-12] (17 pages) - LISP YANG Model [draft-ietf-lisp-yang-21] (82 pages) - LISP Site External Connectivity [draft-jain-lisp-site-external-connectivity-09] (7 pages) - LISP Mobile Node [draft-meyer-lisp-mn-16] (22 pages) - LISP Virtual Private Networks (VPNs) [draft-moreno-lisp-vpn-00] (16 pages) - LISP L2/L3 EID Mobility Using a Unified Control Plane [draft-portoles-lisp-eid-mobility-02] (23 pages) - Publish/Subscribe Functionality for LISP [draft-rodrigueznatal-lisp-pubsub-02] (10 pages) - Vendor Specific LCAF [draft-rodrigueznatal-lisp-vendor-lcaf-00] (5 pages) - LISP Impact [draft-saucez-lisp-impact-07] (15 pages) - LISP Multicast Overlay Group to Underlay RLOC Mappings [draft-vdas-lisp-group-mapping-03] (10 pages) Requests for Comments: RFC6830: The Locator/ID Separation Protocol (LISP) (75 pages) * Updates RFC8113 * Obsoletes RFC9300 * Obsoletes RFC9301 RFC6831: The Locator/ID Separation Protocol (LISP) for Multicast Environments (28 pages) RFC6832: Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites (19 pages) RFC6833: Locator/ID Separation Protocol (LISP) Map-Server Interface (13 pages) * Obsoletes RFC9301 RFC6834: Locator/ID Separation Protocol (LISP) Map-Versioning (21 pages) * Obsoletes RFC9302 RFC6835: The Locator/ID Separation Protocol Internet Groper (LIG) (12 pages) RFC6836: Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT) (25 pages) RFC7052: Locator/ID Separation Protocol (LISP) MIB (66 pages) RFC7215: Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations (30 pages) RFC7834: Locator/ID Separation Protocol (LISP) Impact (18 pages) RFC7835: Locator/ID Separation Protocol (LISP) Threat Analysis (19 pages) RFC7954: Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block (12 pages) RFC7955: Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block (10 pages) RFC8060: LISP Canonical Address Format (LCAF) (36 pages) * Updates RFC9306 RFC8061: Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality (18 pages) RFC8111: Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) (44 pages) RFC8113: Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations (6 pages) * Obsoletes RFC9304 RFC8378: Signal-Free Locator/ID Separation Protocol (LISP) Multicast (21 pages) RFC9299: An Architectural Introduction to the Locator/ID Separation Protocol (LISP) (24 pages) RFC9300: The Locator/ID Separation Protocol (LISP) (33 pages) RFC9301: Locator/ID Separation Protocol (LISP) Control Plane (42 pages) RFC9302: Locator/ID Separation Protocol (LISP) Map-Versioning (15 pages) RFC9303: Locator/ID Separation Protocol Security (LISP-SEC) (23 pages) RFC9304: Locator/ID Separation Protocol (LISP): Shared Extension Message and IANA Registry for Packet Type Allocations (5 pages) RFC9305: Locator/ID Separation Protocol (LISP) Generic Protocol Extension (14 pages) RFC9306: Vendor-Specific LISP Canonical Address Format (LCAF) (5 pages) RFC9437: Publish/Subscribe Functionality for the Locator/ID Separation Protocol (LISP) (18 pages) Link State Routing (lsr) ------------------------ Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Acee Lindem Christian Hopps Yingzhen Qu Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Gunter Van de Velde Mailing Lists: General Discussion: lsr@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lsr Archive: https://mailarchive.ietf.org/arch/browse/lsr/ Description of Working Group: The Link-State Routing (LSR) Working Group is chartered to document current protocol implementation practices and improvements, protocol usage scenarios, maintenance and extensions of the link-state interior gateway routing protocols (IGPs) - specifically IS-IS, OSPFv2, and OSPFv3. The LSR Working Group was formed by merging the isis and ospf WGs and assigning all their existing adopted work at the time of chartering to LSR. IS-IS is an IGP specified and standardized by ISO through ISO 10589:2002 and additional RFC standards with extensions to support IP that has been deployed in the Internet for decades. For the IS-IS protocol, LSR-WG’s work is focused on IP routing, currently based on the agreement in RFC 3563 with ISO/JTC1/SC6. The LSR-WG will interact with other standards bodies that have responsibility for standardizing IS-IS. LSR-WG will continue to support Layer 2 routing (for example TRILL work) as needed. OSPFv2 [RFC 2328 and extensions], is an IGP that has been deployed in the Internet for decades. OSPFv3 [RFC5340 and extensions] provides OSPF for IPv6 and IPv4 [RFC5838] which can be delivered over IPv6 or IPv4 [RFC 7949]. The LSR Working Group will generally manage its specific work items by milestones agreed with the responsible Area Director. In addition to ongoing maintenance, the following topics are specific work-items for the WG. 1) Improve OSPF support for IPv6 and create at least parity with IPv4 functionality by adding OSPFv3 extensions using the OSPFv3 Extended LSAs. 2) Extensions needed for Segment Routing and associated architectural changes 3) YANG models for the management of IS-IS, OSPFv2, and OSPFv3 and extensions 4) Extensions for source-destination routing 5) Improvements to flooding (and other behaviors) to better support dense meshed network topologies, such as are commonly used in data centers. The Link-State Routing (LSR) Working Group will coordinate with other working groups, such as RTGWG, SPRING, MPLS, TEAS, PCE, V6OPS, and 6MAN, to understand the need for extensions and to confirm that the planned work meets the needs and is compatible with IS-IS and/or OSPF from functional, architectural and performance point of views. LSR-WG will coordinate with CCAMP, TEAS, and BIER on their extensions to the LSR IGPs as applicable to LSR protocol operation and scale. LSR-WG should coordinate with other WGs as needed. Goals and Milestones: Sep 2023 - SUBMITTED: IS-IS Fast Flooding Dec 2023 - SUBMITTED: Dynamic Flooding on Dense Graphs Dec 2023 - SUBMITTED: Area Proxy for IS-IS Jan 2024 - SUBMITTED: YANG Model for OSPFv3 Extended LSAs Feb 2024 - WGLC: Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints Jan 2025 - UPNEXT: Extensions to OSPF for Advertising Prefix Administrative Tags Jan 2025 - UPNEXT: Multi-part TLVs in IS-IS Jan 2025 - IS-IS Segment Routing SR YANG Model Jan 2025 - OSPF Segment Routing YANG Model Internet-Drafts: - IS-IS YANG Model Augmentations for Additional Features - Version 1 [draft-acee-lsr-isis-yang-augmentation-v1-04] (17 pages) - Extensions to OSPF for Advertising Prefix Administrative Tags [draft-acee-lsr-ospf-admin-tags-07] (9 pages) - OSPF Transport Instance Extensions [draft-acee-lsr-ospf-transport-instance-02] (14 pages) - YANG Model for OSPFv3 Extended LSAs [draft-acee-lsr-ospfv3-extended-lsa-yang-06] (30 pages) - OSPF YANG Model Augmentations for Additional Features - Version 1 [draft-acee-lsr-ospf-yang-augmentation-v1-01] (23 pages) - IPv6 Source/Destination Routing using IS-IS [draft-baker-ipv6-isis-dst-src-routing-07] (12 pages) - IGP Flexible Algorithms (Flex-Algorithm) In IP Networks [draft-bonica-lsr-ip-flexalgo-01] (17 pages) - ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering [draft-chen-lsr-isis-rfc5316bis-02] (20 pages) - Update to OSPF Terminology [draft-fox-lsr-ospf-terminology-01] (5 pages) - Invalid TLV Handling in IS-IS [draft-ginsberg-lsr-isis-invalid-tlv-03] (8 pages) - IS-IS Application-Specific Link Attributes [draft-ginsberg-lsr-rfc8919bis-02] (25 pages) - Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints [draft-hegde-lsr-flex-algo-bw-con-02] (27 pages) - YANG Data Model for IS-IS SRv6 [draft-hu-isis-srv6-yang-06] (24 pages) - YANG Data Model for OSPF SRv6 [draft-hu-lsr-ospf-srv6-yang-04] (25 pages) - IPv6 Source/Destination Routing using IS-IS [draft-ietf-isis-ipv6-dst-src-routing-00] (12 pages) - Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS [draft-ietf-isis-mpls-elc-13] (7 pages) - IS-IS Routing with Reverse Metric [draft-ietf-isis-reverse-metric-17] (15 pages) - IS-IS Extensions for Segment Routing [draft-ietf-isis-segment-routing-extensions-25] (28 pages) - Signaling Maximum SID Depth (MSD) Using IS-IS [draft-ietf-isis-segment-routing-msd-19] (10 pages) - A YANG Data Model for IS-IS Segment Routing for the MPLS Data Plane [draft-ietf-isis-sr-yang-22] (33 pages) - IS-IS Application-Specific Link Attributes [draft-ietf-isis-te-app-19] (20 pages) - YANG Data Model for the IS-IS Protocol [draft-ietf-isis-yang-isis-cfg-42] (103 pages) - Algorithm Related IGP-Adjacency SID Advertisement [draft-ietf-lsr-algorithm-related-adjacency-sid-07] (16 pages) - Updates to Anycast Property advertisement for OSPFv2 [draft-ietf-lsr-anycast-flag-00] (6 pages) - IS-IS Distributed Flooding Reduction [draft-ietf-lsr-distoptflood-06] (15 pages) - Dynamic Flooding on Dense Graphs [draft-ietf-lsr-dynamic-flooding-18] (48 pages) - IGP Flexible Algorithm [draft-ietf-lsr-flex-algo-26] (42 pages) - Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints [draft-ietf-lsr-flex-algo-bw-con-14] (33 pages) - Flooding Topology Minimum Degree Algorithm [draft-ietf-lsr-flooding-topo-min-degree-09] (12 pages) - IGP Flexible Algorithms Reverse Affinity Constraint [draft-ietf-lsr-igp-flex-algo-reverse-affinity-03] (9 pages) - IGP Unreachable Prefix Announcement [draft-ietf-lsr-igp-ureach-prefix-announce-02] (14 pages) - IGP Flexible Algorithm in IP Networks [draft-ietf-lsr-ip-flexalgo-17] (21 pages) - Area Proxy for IS-IS [draft-ietf-lsr-isis-area-proxy-12] (20 pages) - IS-IS Extended Hierarchy [draft-ietf-lsr-isis-extended-hierarchy-06] (19 pages) - IS-IS Fast Flooding [draft-ietf-lsr-isis-fast-flooding-11] (27 pages) - IS-IS Flood Reflection [draft-ietf-lsr-isis-flood-reflection-12] (19 pages) - Invalid TLV Handling in IS-IS [draft-ietf-lsr-isis-invalid-tlv-03] (8 pages) - Restart Signaling for IS-IS [draft-ietf-lsr-isis-rfc5306bis-09] (22 pages) - IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering [draft-ietf-lsr-isis-rfc5316bis-07] (19 pages) - IS-IS Traffic Engineering (TE) Metric Extensions [draft-ietf-lsr-isis-rfc7810bis-05] (21 pages) - IS-IS Routing for Spine-Leaf Topology [draft-ietf-lsr-isis-spine-leaf-ext-02] (17 pages) - IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane [draft-ietf-lsr-isis-srv6-extensions-19] (25 pages) - YANG Data Model for IS-IS SRv6 [draft-ietf-lsr-isis-srv6-yang-06] (25 pages) - Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP) [draft-ietf-lsr-isis-sr-vtn-mt-08] (9 pages) - IS-IS Topology-Transparent Zone [draft-ietf-lsr-isis-ttz-09] (25 pages) - IS-IS YANG Model Augmentations for Additional Features - Version 1 [draft-ietf-lsr-isis-yang-augmentation-v1-08] (36 pages) - Revision to Registration Procedures for IS-IS Neighbor Link-Attribute Bit Values [draft-ietf-lsr-labv-registration-03] (3 pages) - Multi-part TLVs in IS-IS [draft-ietf-lsr-multi-tlv-05] (27 pages) - Extensions to OSPF for Advertising Prefix Administrative Tags [draft-ietf-lsr-ospf-admin-tags-21] (20 pages) - OSPF Bidirectional Forwarding Detection (BFD) Strict-Mode [draft-ietf-lsr-ospf-bfd-strict-mode-10] (10 pages) - Advertising Layer 2 Bundle Member Link Attributes in OSPF [draft-ietf-lsr-ospf-l2bundles-10] (12 pages) - Advertising Infinity Links in OSPF [draft-ietf-lsr-ospf-ls-link-infinity-00] (9 pages) - Prefix Flag Extension for OSPFv2 and OSPFv3 [draft-ietf-lsr-ospf-prefix-extended-flags-02] (10 pages) - OSPF Prefix Originator Extensions [draft-ietf-lsr-ospf-prefix-originator-12] (9 pages) - OSPF Reverse Metric [draft-ietf-lsr-ospf-reverse-metric-13] (11 pages) - YANG Data Model for OSPF SRv6 [draft-ietf-lsr-ospf-srv6-yang-06] (25 pages) - Update to OSPF Terminology [draft-ietf-lsr-ospf-terminology-09] (6 pages) - OSPF-GT (Generalized Transport) [draft-ietf-lsr-ospf-transport-instance-07] (15 pages) - YANG Model for OSPFv3 Extended LSAs [draft-ietf-lsr-ospfv3-extended-lsa-yang-29] (29 pages) - OSPFv3 Extensions for Segment Routing over IPv6 (SRv6) [draft-ietf-lsr-ospfv3-srv6-extensions-15] (26 pages) - OSPF YANG Model Augmentations for Additional Features - Version 1 [draft-ietf-lsr-ospf-yang-augmentation-v1-13] (58 pages) - IGP Extension for Path Computation Element Communication Protocol (PCEP) Security Capability Support in PCE Discovery (PCED) [draft-ietf-lsr-pce-discovery-security-support-13] (13 pages) - IS-IS Application-Specific Link Attributes [draft-ietf-lsr-rfc8919bis-04] (21 pages) - OSPF Application-Specific Link Attributes [draft-ietf-lsr-rfc8920bis-06] (20 pages) - A YANG Module for IS-IS Reverse Metric [draft-ietf-lsr-yang-isis-reverse-metric-06] (13 pages) - OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement [draft-ietf-ospf-lls-interface-id-09] (8 pages) - Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPF [draft-ietf-ospf-mpls-elc-15] (8 pages) - Host Router Support for OSPFv2 [draft-ietf-ospf-ospfv2-hbit-12] (8 pages) - OSPFv3 Extensions for Segment Routing [draft-ietf-ospf-ospfv3-segment-routing-extensions-23] (18 pages) - Signaling Maximum SID Depth (MSD) Using OSPF [draft-ietf-ospf-segment-routing-msd-25] (11 pages) - A YANG Data Model for OSPF Segment Routing for the MPLS Data Plane [draft-ietf-ospf-sr-yang-31] (49 pages) - OSPF Application-Specific Link Attributes [draft-ietf-ospf-te-link-attr-reuse-16] (19 pages) - OSPF Routing with Cross-Address Family Traffic Engineering Tunnels [draft-ietf-ospf-xaf-te-07] (8 pages) - YANG Data Model for the OSPF Protocol [draft-ietf-ospf-yang-29] (116 pages) - OSPF Strict-Mode for BFD [draft-ketant-lsr-ospf-bfd-strict-mode-03] (10 pages) - Advertising L2 Bundle Member Link Attributes in OSPF [draft-ketant-lsr-ospf-l2bundles-02] (10 pages) - OSPF Reverse Metric [draft-ketant-lsr-ospf-reverse-metric-02] (12 pages) - Dynamic Flooding on Dense Graphs [draft-li-lsr-dynamic-flooding-02] (37 pages) - Area Proxy for IS-IS [draft-li-lsr-isis-area-proxy-07] (20 pages) - OSPFv3 Extensions for SRv6 [draft-li-lsr-ospfv3-srv6-extensions-00] (23 pages) - Algorithm Related IGP-Adjacency SID Advertisement [draft-peng-lsr-algorithm-related-adjacency-sid-03] (13 pages) - Multi-part TLVs in IS-IS [draft-pkaneria-lsr-multi-tlv-04] (25 pages) - OSPF Application-Specific Link Attributes [draft-ppsenak-lsr-rfc8920bis-02] (23 pages) - IS-IS Flood Reflection [draft-przygienda-lsr-flood-reflection-01] (17 pages) - Advertisement of Stub Link Attributes [draft-wang-lsr-stub-link-attributes-08] (14 pages) - IS-IS Optimal Distributed Flooding for Dense Topologies [draft-white-lsr-distoptflood-03] (12 pages) Requests for Comments: RFC8476: Signaling Maximum SID Depth (MSD) Using OSPF (11 pages) RFC8491: Signaling Maximum SID Depth (MSD) Using IS-IS (10 pages) RFC8500: IS-IS Routing with Reverse Metric (15 pages) RFC8510: OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement (8 pages) RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions (21 pages) RFC8666: OSPFv3 Extensions for Segment Routing (18 pages) RFC8667: IS-IS Extensions for Segment Routing (28 pages) RFC8687: OSPF Routing with Cross-Address Family Traffic Engineering Tunnels (8 pages) RFC8706: Restart Signaling for IS-IS (22 pages) RFC8770: Host Router Support for OSPFv2 (8 pages) RFC8918: Invalid TLV Handling in IS-IS (8 pages) RFC8919: IS-IS Application-Specific Link Attributes (20 pages) * Obsoletes RFC9479 RFC8920: OSPF Application-Specific Link Attributes (19 pages) * Obsoletes RFC9492 RFC9084: OSPF Prefix Originator Extensions (9 pages) RFC9088: Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS (7 pages) RFC9089: Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPF (8 pages) RFC9129: YANG Data Model for the OSPF Protocol (116 pages) RFC9130: YANG Data Model for the IS-IS Protocol (103 pages) RFC9194: A YANG Module for IS-IS Reverse Metric (13 pages) RFC9339: OSPF Reverse Metric (11 pages) RFC9346: IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering (19 pages) RFC9350: IGP Flexible Algorithm (42 pages) RFC9352: IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane (25 pages) RFC9353: IGP Extension for Path Computation Element Communication Protocol (PCEP) Security Capability Support in PCE Discovery (PCED) (13 pages) RFC9355: OSPF Bidirectional Forwarding Detection (BFD) Strict-Mode (10 pages) RFC9356: Advertising Layer 2 Bundle Member Link Attributes in OSPF (12 pages) RFC9377: IS-IS Flood Reflection (19 pages) RFC9454: Update to OSPF Terminology (6 pages) RFC9479: IS-IS Application-Specific Link Attributes (21 pages) RFC9492: OSPF Application-Specific Link Attributes (20 pages) RFC9502: IGP Flexible Algorithm in IP Networks (21 pages) RFC9513: OSPFv3 Extensions for Segment Routing over IPv6 (SRv6) (26 pages) RFC9587: YANG Data Model for OSPFv3 Extended Link State Advertisements (LSAs) (25 pages) RFC9650: Revision to Registration Procedures for IS-IS Neighbor Link-Attribute Bit Values (3 pages) Link State Vector Routing (lsvr) -------------------------------- Charter Last Modified: 2024-05-01 Current Status: Active Chairs: Jie Dong Ketan Talaulikar Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Jim Guichard Mailing Lists: General Discussion: lsvr@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lsvr Archive: https://mailarchive.ietf.org/arch/browse/lsvr/ Description of Working Group: Data Centers have been steadily growing to commonly host tens of thousands of end points, or more, in a single network. Because of their topologies (traditional and emerging), traffic patterns, need for fast restoration, and for low human intervention, data center networks have a unique set of requirements that is resulting in the design of routing solutions specific to them. The Link-State Vector Routing (LSVR) Working Group is chartered to develop and document a hybrid routing protocol utilizing a combination of link-state and path-vector routing mechanisms. The LSVR WG will utilize existing IPv4/IPv6 transport, packet formats and error handling of BGP-4 consistent with BGP-LS NLRI encoding mechanisms (RFC7752) to facilitate Link-State Vector (LSV) routing information distribution. An LSV is intended to be specified as a data structure comprised of link attributes, neighbor information, and other and other potential attributes that can be utilized to make routing decisions. The LSVR specification is initially focused on operation within a single datacenter (DC) as a single distribution domain, which is defined as a set of participating nodes in a single administrative domain. Routing protocol functionality defined by LSVR would be typically routing within a datacenter’s underlay routing plane. The work will include coexistence considerations with BGP IPv4/IPv6 unicast address families installing and advertising routes into the same RIB. The WG will consider the effects (if any) of deploying the LSVR protocol while concurrently using the same transport session as other existing BGP address families. These considerations will be documented as part of the main protocol specification. A mechanism to be able to independently deploy LSVR from other address families may be defined (as needed). The LSVR protocol is intended as a self-standing routing protocol even if using existing BGP transport mechanisms and encodings, or if sharing the same transport session with other existing BGP address families. Similar as existing routing protocols, the LSVR protocol will not internally combine the route selection mechanisms or share routing information, except through common external interaction methods in the RIB. In order to achieve the noted objective, the working group will focus on standardization of protocol functionality, defining Link-State Vectors (LSVs) and defining standard path-vector route selection utilizing the Dijkstra SPF based algorithm, BGP-4 protocol mechanics and BGP-LS NRLI encoding. The working group will provide specifications to manage routing information from other unicast routing protocols or BGP address families to common prefixes. The LSVR WG is chartered to deliver the following documents: - Specification document describing LSV with standard Dijkstra SPF route/path selection (calculation) utilizing existing BGP protocol baseline functionality and BGP-LS packet encoding formats - Specification documenting protocol extensions required to efficiently reuse BGP to distribute LSVs within an IPv4/IPv6 DC with scope to include privacy and security considerations - The impact of these extensions to the security properties of BGP will be studied and documented - New attack vectors will be explored and documented - Mitigations to any new attack vectors identified will be discussed and documented - Applicability Statement for the use of LSVR in the Datacenter - YANG model specification for LSVR management The WG will closely collaborate with the idr WG. Any modifications or extension to BGP that will not be specifically constrained to be used by LSVR must be carried out in the idr WG, but may be done in this WG after agreement with all the relevant chairs and the responsible Area Directors. Goals and Milestones: Mar 2019 - LSVR with standard Dijkstra path selection Mar 2019 - LSV distribution using BGP transport Mar 2019 - Applicability statement for LSVR in DCs Jul 2019 - YANG specification for LSVR Internet-Drafts: - Usage and Applicability of Link State Vector Routing in Data Centers [draft-ietf-lsvr-applicability-12] (15 pages) - A YANG Model for BGP-LS, BGP-LS-VPN, and BGP-LS-SPF [draft-ietf-lsvr-bgp-ls-yang-02] (51 pages) - BGP Link-State Shortest Path First (SPF) Routing [draft-ietf-lsvr-bgp-spf-33] (39 pages) - Layer-3 Discovery and Liveness [draft-ietf-lsvr-l3dl-12] (48 pages) - Layer-3 Discovery and Liveness Signing [draft-ietf-lsvr-l3dl-signing-06] (10 pages) - L3DL Upper-Layer Protocol Configuration [draft-ietf-lsvr-l3dl-ulpc-05] (9 pages) - Link State Over Ethernet [draft-ietf-lsvr-lsoe-01] (27 pages) - Usage and Applicability of Link State Vector Routing in Data Centers [draft-keyupate-lsvr-applicability-02] (11 pages) - Shortest Path Routing Extensions for BGP Protocol [draft-keyupate-lsvr-bgp-spf-00] (15 pages) - Layer 3 Discovery and Liveness Signing [draft-ymbk-lsvr-l3dl-signing-01] (9 pages) - L3DL Upper Layer Protocol Configuration [draft-ymbk-lsvr-l3dl-ulpc-03] (8 pages) - Link State Over Ethernet [draft-ymbk-lsvr-lsoe-03] (24 pages) No Requests for Comments Mobile Ad-hoc Networks (manet) ------------------------------ Charter Last Modified: 2024-05-21 Current Status: Active Chairs: Donald E. Eastlake 3rd Don Fedyk Ronald in 't Velt Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Jim Guichard Mailing Lists: General Discussion: manet@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/manet Archive: https://mailarchive.ietf.org/arch/browse/manet/ Description of Working Group: The purpose of the MANET working group is to standardize IP routing protocol functionality suitable for wireless routing applications within both static and dynamic topologies with increased dynamics due to node motion or other factors. Approaches are intended to be relatively lightweight in nature, suitable for multiple hardware and wireless environments, and address scenarios where MANETs are deployed at the edges of an IP infrastructure. Hybrid mesh infrastructures (e.g., a mixture of fixed and mobile routers) should also be supported by MANET specifications and management features. When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. The WG will put special attention on the standardization of a bidirectional, dynamic link exchange protocol (DLEP) between the router and the modem. The MANET WG will coordinate with other Working Groups, such as the pim WG for multicast support, the Routing Area WG (rtgwg), OSPF WG and Babel WG on the general use of DLEP, as well as the IPPM WG on topics related to traffic classification. The MANET WG is responsible for the maintenance of OLSRv2 [RFC 7181], NHDP [RFC 6130] and the Generalized MANET Packet/Message Format [RFC5444], and their extensions. Work Items: - Develop a dynamic link exchange protocol (DLEP). - DLEP extension to provide a credit-windowing scheme for destination-specific flow control. - DLEP extensions for reporting statistics by traffic classification. - Multicast MANET protocol framework based on Simplified Multicast Forwarding [RFC 6621] for scoped forwarding within MANET networks. As part of this framework the WG will produce a well defined MANET multicast forwarding information base (FIB). - Document outlining challenges and best practices for deploying and managing MANET networks. Goals and Milestones: Nov 2016 - MANET Management Document (Informational) Nov 2016 - DLEP Credit Windowing Extensions (Standards Track) Nov 2016 - DLEP (Standards Track) Jul 2017 - DLEP traffic extensions (Standards Track) Nov 2017 - Multicast FIB (Standards Track) Internet-Drafts: - Security Threats for the Optimized Link State Routing Protocol version 2 (OLSRv2) [draft-clausen-manet-olsrv2-sec-threats-01] (24 pages) - Rules For Designing Protocols Using the RFC5444 Generalized Packet/ Message Format [draft-clausen-manet-rfc5444-usage-00] (17 pages) - Link Identifier Extension to DLEP [draft-dlep-lid-02] (7 pages) - The Adaptive Demand-Driven Multicast Routing Protocol for Mobile Ad Hoc Networks (ADMR) [draft-ietf-manet-admr-01] (63 pages) - Ad hoc Multicast Routing protocol utilizing Increasing id-numberS (AMRIS) Functional Specification [draft-ietf-manet-amris-spec-00] (23 pages) - Ad hoc On-Demand Distance Vector (AODV) Routing [draft-ietf-manet-aodv-13] (37 pages) - Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing [draft-ietf-manet-aodvv2-16] (84 pages) - MANET Routing Protocol Applicability Statement [draft-ietf-manet-appl-00] (3 pages) - IP Flooding in Ad hoc Mobile Networks [draft-ietf-manet-bcast-00] (0 pages) - Cluster Based Routing Protocol(CBRP) Functional Specification [draft-ietf-manet-cbrp-spec-01] (27 pages) - Core Extraction Distributed Ad hoc Routing (CEDAR) Specification [draft-ietf-manet-cedar-spec-00] (29 pages) - Credit Windowing extension for DLEP [draft-ietf-manet-credit-window-07] (13 pages) - Differential Destination Multicast (DDM) Specification [draft-ietf-manet-ddm-00] (21 pages) - Dynamic Link Exchange Protocol (DLEP) [draft-ietf-manet-dlep-29] (82 pages) - DLEP Radio Channel Utilization Extension [draft-ietf-manet-dlep-channel-utilization-00] (8 pages) - DLEP Credit-Based Flow Control Messages and Data Items [draft-ietf-manet-dlep-credit-flow-control-15] (19 pages) - DLEP DiffServ Aware Credit Window Extension [draft-ietf-manet-dlep-da-credit-extension-18] (6 pages) - DLEP IEEE 802.1Q Aware Credit Window Extension [draft-ietf-manet-dlep-ether-credit-extension-06] (7 pages) - Dynamic Link Exchange Protocol (DLEP) Latency Range Extension [draft-ietf-manet-dlep-latency-extension-05] (5 pages) - Dynamic Link Exchange Protocol (DLEP) Link Identifier Extension [draft-ietf-manet-dlep-lid-extension-06] (9 pages) - Dynamic Link Exchange Protocol (DLEP) Multi-Hop Forwarding Extension [draft-ietf-manet-dlep-multi-hop-extension-07] (10 pages) - Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension [draft-ietf-manet-dlep-pause-extension-08] (12 pages) - DLEP Radio Band Extension [draft-ietf-manet-dlep-radio-band-00] (6 pages) - DLEP Radio Quality Extension [draft-ietf-manet-dlep-radio-quality-00] (7 pages) - DLEP Traffic Classification Data Item [draft-ietf-manet-dlep-traffic-classification-12] (14 pages) - The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4 [draft-ietf-manet-dsr-10] (107 pages) - Flow State in the Dynamic Source Routing Protocol for Mobile Ad Hoc Networks [draft-ietf-manet-dsrflow-00] (30 pages) - Dynamic MANET On-demand (AODVv2) Routing [draft-ietf-manet-dymo-26] (60 pages) - Definition of Managed Objects for the DYMO Manet Routing Protocol [draft-ietf-manet-dymo-mib-04] (41 pages) - Fisheye State Routing Protocol (FSR) for Ad Hoc Networks [draft-ietf-manet-fsr-03] (17 pages) - IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols [draft-ietf-manet-iana-07] (5 pages) - Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols [draft-ietf-manet-ibs-05] (17 pages) - An Internet MANET Encapsulation Protocol (IMEP) Specification [draft-ietf-manet-imep-spec-01] (37 pages) - INSIGNIA [draft-ietf-manet-insignia-01] (22 pages) - Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations [draft-ietf-manet-issues-02] (12 pages) - Jitter Considerations in Mobile Ad Hoc Networks (MANETs) [draft-ietf-manet-jitter-04] (12 pages) - Landmark Routing Protocol (LANMAR) for Large Scale Ad Hoc Networks [draft-ietf-manet-lanmar-05] (21 pages) - Long-lived Ad Hoc Routing based on the Concept of Associativity [draft-ietf-manet-longlived-adhoc-routing-00] (18 pages) - Multicast Ad hoc On-Demand Distance Vector (MAODV) Routing [draft-ietf-manet-maodv-00] (24 pages) - Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) [draft-ietf-manet-nhdp-15] (88 pages) - Definition of Managed Objects for the Neighborhood Discovery Protocol [draft-ietf-manet-nhdp-mib-19] (67 pages) - Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2) [draft-ietf-manet-nhdp-olsrv2-sec-05] (15 pages) - Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs [draft-ietf-manet-nhdp-olsrv2-tlv-extension-05] (16 pages) - An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) [draft-ietf-manet-nhdp-optimization-04] (9 pages) - Using Integrity Check Values and Timestamps For Router Admittance in NHDP [draft-ietf-manet-nhdp-sec-02] (12 pages) - Security Threats for the Neighborhood Discovery Protocol (NHDP) [draft-ietf-manet-nhdp-sec-threats-06] (20 pages) - On-Demand Multicast Routing Protocol (ODMRP) for Ad-Hoc Networks [draft-ietf-manet-odmrp-04] (29 pages) - Optimized Link State Routing Protocol (OLSR) [draft-ietf-manet-olsr-11] (75 pages) - The Optimized Link State Routing Protocol Version 2 [draft-ietf-manet-olsrv2-19] (115 pages) - Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2) [draft-ietf-manet-olsrv2-dat-metric-12] (21 pages) - Snapshot of OLSRv2-Routed MANET Management [draft-ietf-manet-olsrv2-management-snapshot-03] (14 pages) - Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale [draft-ietf-manet-olsrv2-metrics-rationale-04] (25 pages) - Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2 [draft-ietf-manet-olsrv2-mib-12] (86 pages) - Multipath Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2) [draft-ietf-manet-olsrv2-multipath-15] (26 pages) - Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2) [draft-ietf-manet-olsrv2-multitopology-07] (23 pages) - Routing Multipoint Relay Optimization for the Optimized Link State Routing Protocol Version 2 (OLSRv2) [draft-ietf-manet-olsrv2-rmpr-optimization-01] (5 pages) - Security Threats to the Optimized Link State Routing Protocol Version 2 (OLSRv2) [draft-ietf-manet-olsrv2-sec-threats-04] (26 pages) - Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format [draft-ietf-manet-packetbb-17] (60 pages) - Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) [draft-ietf-manet-packetbb-sec-09] (21 pages) - Relative Distance Micro-discovery Ad Hoc Routing (RDMAR) Protocol [draft-ietf-manet-rdmar-00] (15 pages) - Definition of Managed Objects for Performance Reporting [draft-ietf-manet-report-mib-04] (35 pages) - Rules for Designing Protocols Using the Generalized Packet/Message Format from RFC 5444 [draft-ietf-manet-rfc5444-usage-07] (29 pages) - Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) [draft-ietf-manet-rfc6622-bis-06] (31 pages) - Definition of Managed Objects for the Neighborhood Discovery Protocol [draft-ietf-manet-rfc6779bis-07] (72 pages) - A Simple Protocol for Multicast and Broadcast in Mobile Ad Hoc Networks [draft-ietf-manet-simple-mbcast-01] (11 pages) - Simplified Multicast Forwarding [draft-ietf-manet-smf-14] (55 pages) - Definition of Managed Objects for the Mobile Ad Hoc Network (MANET) Simplified Multicast Framework Relay Set Process [draft-ietf-manet-smf-mib-13] (65 pages) - Security Threats to Simplified Multicast Forwarding (SMF) [draft-ietf-manet-smf-sec-threats-06] (15 pages) - SOURCE TREE ADAPTIVE ROUTING (STAR) PROTOCOL [draft-ietf-manet-star-00] (26 pages) - Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) [draft-ietf-manet-tbrpf-11] (46 pages) - Mobile Ad Hoc Networking Terminology [draft-ietf-manet-term-01] (9 pages) - Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs) [draft-ietf-manet-timetlv-08] (14 pages) - TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format [draft-ietf-manet-tlv-naming-05] (15 pages) - Temporally-Ordered Routing Algorithm (TORA) Version 1 Functional Specification [draft-ietf-manet-tora-spec-04] (23 pages) - The Bordercast Resolution Protocol (BRP) for Ad Hoc Networks [draft-ietf-manet-zone-brp-02] (13 pages) - The Intrazone Routing Protocol (IARP) for Ad Hoc Networks [draft-ietf-manet-zone-iarp-02] (11 pages) - The Interzone Routing Protocol (IERP) for Ad Hoc Networks [draft-ietf-manet-zone-ierp-02] (14 pages) - The Zone Routing Protocol (ZRP) for Ad Hoc Networks [draft-ietf-manet-zone-zrp-04] (11 pages) - AMRoute: Adhoc Multicast Routing Protocol [draft-talpade-manet-amroute-00] (24 pages) Requests for Comments: RFC2501: Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations (12 pages) RFC3561: Ad hoc On-Demand Distance Vector (AODV) Routing (37 pages) RFC3626: Optimized Link State Routing Protocol (OLSR) (75 pages) RFC3684: Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) (46 pages) * Updates RFC9141 RFC4728: The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4 (107 pages) RFC5148: Jitter Considerations in Mobile Ad Hoc Networks (MANETs) (12 pages) RFC5444: Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format (60 pages) * Updates RFC7631 * Updates RFC8245 RFC5497: Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs) (14 pages) RFC5498: IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols (5 pages) RFC6130: Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) (88 pages) * Updates RFC7183 * Updates RFC7188 * Updates RFC7466 RFC6621: Simplified Multicast Forwarding (55 pages) RFC6622: Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) (21 pages) * Obsoletes RFC7182 RFC6779: Definition of Managed Objects for the Neighborhood Discovery Protocol (67 pages) * Obsoletes RFC7939 RFC7181: The Optimized Link State Routing Protocol Version 2 (115 pages) * Updates RFC7183 * Updates RFC7187 * Updates RFC7188 * Updates RFC7466 RFC7182: Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) (31 pages) RFC7183: Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2) (15 pages) RFC7184: Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2 (86 pages) RFC7185: Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale (25 pages) RFC7186: Security Threats for the Neighborhood Discovery Protocol (NHDP) (20 pages) * Updates RFC7985 RFC7187: Routing Multipoint Relay Optimization for the Optimized Link State Routing Protocol Version 2 (OLSRv2) (5 pages) RFC7188: Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs (16 pages) * Updates RFC7722 RFC7367: Definition of Managed Objects for the Mobile Ad Hoc Network (MANET) Simplified Multicast Framework Relay Set Process (65 pages) RFC7466: An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) (9 pages) RFC7631: TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format (15 pages) * Updates RFC7722 RFC7722: Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2) (23 pages) RFC7779: Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2) (21 pages) RFC7859: Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols (17 pages) RFC7939: Definition of Managed Objects for the Neighborhood Discovery Protocol (72 pages) RFC7985: Security Threats to Simplified Multicast Forwarding (SMF) (15 pages) RFC8116: Security Threats to the Optimized Link State Routing Protocol Version 2 (OLSRv2) (26 pages) RFC8175: Dynamic Link Exchange Protocol (DLEP) (82 pages) RFC8218: Multipath Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2) (26 pages) RFC8245: Rules for Designing Protocols Using the Generalized Packet/Message Format from RFC 5444 (29 pages) RFC8629: Dynamic Link Exchange Protocol (DLEP) Multi-Hop Forwarding Extension (10 pages) RFC8651: Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension (12 pages) RFC8703: Dynamic Link Exchange Protocol (DLEP) Link Identifier Extension (9 pages) RFC8757: Dynamic Link Exchange Protocol (DLEP) Latency Range Extension (5 pages) Multiprotocol Label Switching (mpls) ------------------------------------ Charter Last Modified: 2024-03-26 Current Status: Active Chairs: Nicolai Leymann Tarek Saad Tony Li Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Jim Guichard Secretary: Mach Chen Mailing Lists: General Discussion: mpls@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mpls Archive: https://mailarchive.ietf.org/arch/browse/mpls/ Description of Working Group: The MPLS working group is responsible for standardizing technology for label switching and for the implementation of label-switched paths over packet based link-level technologies. The working group's responsibilities include procedures and protocols for the distribution of labels between Label Switching Routers (LSRs), MPLS packet encapsulation, and for Operation, Administration, and Maintenance (OAM) for MPLS systems including the necessary management objects expressed as YANG models or MIB modules. The current WG focus areas and work items are: - Maintain existing MPLS requirements, mechanisms, and protocols, as currently documented in RFCs, in coordination with other working groups that work in overlapping areas including the BESS, BFD, CCAMP, OPSAWG, PALS, SPRING, and TEAS working groups. - Evolve key MPLS protocols, including LDP, tLDP, mLDP, RSVP-TE for packet networks, and LSP Ping to meet new requirements. - Document MPLS-specific aspects of traffic engineering including for multi-areas/multi-AS scenarios in cooperation with the TEAS working group. - Coordinate the work on RSVP-TE with CCAMP and TEAS. In the cases where there is an overlap, generic parts will be done by the TEAS working group, MPLS data plane specific parts will be done by the MPLS working group, and support for any other specific data planes will be done by the CCAMP working group. The TEAS working group acts as the hub for coordinating this work, and the MPLS working group will track agreements about work to be done in this working group through milestones in this charter. - Define data models for MPLS working group related solutions. YANG models and MIB modules may be considered. Coordinate with the LIME and NETMOD working groups for core YANG models. - Define an overall OAM framework for topology-driven, traffic engineered, and transport profile MPLS applications to achieve a common set of approaches and tools across the full family of MPLS applications. - Define the necessary extensions for MPLS key protocols for dual- stack and IPv6-only networks. - Document current implementation practices for MPLS load sharing. - Document mechanisms for securing MPLS protocols and data plane. - Document mechanisms for adding multi-topology support to existing MPLS protocols. - Define the necessary protection protocols and scenarios for transport profile MPLS applications - Document use cases for MPLS protocols. Goals and Milestones: Abandoned - Submit draft-ietf-mpls-seamless-mpls for publication Done - Submit documents from original MPLS effort to IESG Done - Framework for IP multicast over label-switched paths ready for advancement. Done - LDP fault tolerance specification ready for advancement to Proposed Standard. Done - Specification for MPLS-specific recovery ready for advancement. Done - Submit Multiprotocol Label Switching (MPLS) Forward Equivalency Class-To-Next Hop Label Forwarding Entry Management Information Base to the IESG for publication as Proposed Standards Done - Submit Multiprotocol Label Switching (MPLS) Management Overview to the IESG for publication as Proposed Standards Done - Submit Multiprotocol Label Switching (MPLS) Label Switching Router (LSR), Management Information Base to the IESG for publication as Proposed Standards Done - Submit Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base to the IESG for publication as Proposed Standards Done - Submit Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management to the IESG for publication as Proposed Standards Done - Submit Definitions of Managed Objects for MultoiProtocol Label Switching, Label Distribution Protocol (LDP) to the IESG for publication as Proposed Standards Done - Submit the Traffic Engineering Link MIB to the IESG for as a Proposed Standard Done - Submit a specification on Encapsulations to carry MPLS over IP and GRE to the IESG for as a Proposed Standard Done - Submit a document defining the scope, requirements, and issues to resolve for setup of P2MP TE LSPs (MPLS and GMPLS) Done - Submit specification on LSP Ping to the IESG for publication as a Proposed Standard Done - Submit an OAM Framework Document to the IESG for publication as an Informational RFC Done - Submit a BCP on MPLS load sharing to the IESG Done - Submit specification on LSR Self Test to the IESG for publication as a Proposed Standard Done - Submit document(s) specifying protocol extensions, enhancements and mechanisms for setup of P2MP TE LSPs Done - Submit point to multipoint TE MIB to IESG as proposed standard Done - Submit EXP field clarification document to IESG as proposed standard Done - Submit a specification on Soft Pre-emption of LSP Tunnels to the IESG for publication as a Proposed Standard Done - Submit LDP extensions for P2MP LSPs Done - Submit MPLS security framework for publication as an informational RFC Done - Submit requirements for point-to-multipoint extensions to LDP Done - Submit draft-ietf-mpls-ldp-gtsm for publication Done - Submit draft-ietf-mpls-entropy-label for publication Done - Submit draft-ietf-mpls-tp-itu-t-identifiers for publication Done - Submit draft-ietf-mpls-mldp-in-band-signaling for publication Done - Submit draft-ietf-mpls-tp-security-framework for publication Done - Submit draft-ietf-mpls-ipv6-pw-lsp-ping for publication Done - Submit draft-ietf-mpls-tp-ring-protection for publication Done - Submit draft-ietf-mpls-gach-adv for publication Done - Submit draft-ietf-mpls-tp-ethernet-addressing for publication Done - Submit draft-ietf-mpls-tp-use-cases-and-design for publication Done - Submit draft-ietf-mpls-retire-ach-tlv for publication Done - Submit draft-ietf-mpls-ldp-dod for publication Done - Submit draft-ietf-mpls-mldp-hsmp for publication Done - Submit draft-ietf-mpls-tp-mip-mep-map for publication Done - Submit draft-ietf-mpls-tp-rosetta-stone for publication Done - Submit draft-ietf-mpls-return-path-specified-lsp-ping for publication Done - Submit draft-ietf-mpls-targeted-mldp for publication Done - Submit draft-ietf-mpls-tp-p2mp-framework for publication Done - draft-ietf-mpls-tp-psc-itu Done - Submit draft-ietf-mpls-moving-iana-registries for publication Done - Submit draft-ietf-mpls-forwardig for publication Done - Submit draft-ietf-mpls-extended-admin-group for publication Done - Submit draft-ietf-mpls-ldp-hello-crypto-auth for publication Done - Submit draft-ietf-mpls-special-purpose-labels Done - Submit draft-ietf-mpls-ldp-applicability-label-adv for publication Done - Submit draft-ietf-mpls-lsp-ping-ttl-tlv for publication Done - Submit draft-ietf-mpls-psc-updates for publication Done - Submit draft-ietf-mpls-ldp-multi-topology for publication Done - Submit draft-ietf-mpls-deprecate-bgp-entropy-label for publication Done - Submit draft-ietf-mpls-smp-requirements for publication Done - Submit draft-ietf-mpls-mldp-in-band-wildcard-encoding for publication Done - Submit draft-ietf-mpls-pim-sm-over-mldp Done - Submit draft-ietf-mpls-tp-te-mib for publication Done - Submit draft-ietf-mpls-p2mp-loose-path-reopt for publicatiion Done - Submit draft-ietf-mpls-ipv6-only-gap for publication Done - Submit draft-ietf-mpls-in-udp for publication Done - Submit draft-ietf-mpls-ldp-ip-pw-capability for publication Done - Submit draft-ietf-mpls-proxy-lsp-ping fpr publication Done - Submit draft-ietf-mpls-seamless-mcast for publication Done - Submit draft-ietf-mpls-ldp-ipv6 for publication Done - Submit draft-ietf-mpls-tp-oam-id-mib for publication Done - ** Progress draft-ietf-mpls-pim-sm-over-mldp to publication Done - ++ Progress draft-ietf-mpls-lsp-ping-registry to publication Done - Submit draft-ietf-mpls-lsp-ping-relay-reply for publication Done - ++ Progress draft-ietf-mpls-ldp-ip-pw-capability to publication Done - Submit draft-ietf-mpls-rfc6374-udp-return-path for publicatiion Done - ++ Progress draft-ietf-mpls-ldp-ipv6 for publication to publication Done - Submit draft-ietf-mpls-mldp-node-protection for publication Done - Submit draft-ietf-mpls-lsp-ping-registry for publication Done - Submit draft-ietf-mpls-oam-ipv6-rao for publication Done - ++ Progress draft-ietf-mpls-seamless-mcast to publication Done - Submit draft-ietf-mpls-entropy-lsp-ping for publication Done - ++ Progress draft-ietf-mpls-proxy-lsp-ping to publication Done - ++ Progress draft-ietf-mpls-oam-ipv6-rao to publication Done - Submit draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf for publication Done - ++ Progress draft-ietf-mpls-in-udp to publication Done - Submit draft-ietf-mpls-lsp-ping-reply-mode-simple for publication Done - Submit draft-ietf-mpls-ldp-mrt for publication Done - Submit draft-ietf-mpls-lsp-ping-lag-multipath for publication Done - Submit draft-ietf-mpls-tp-linear-protection-mib Done - Submit draft-ietf-mpls-tp-temporal-hitless-psm for publication Moved to TEAS - Submit draft-ietf-mpls-te-express-path Internet-Drafts: - Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Network using Entropy Labels (EL) [draft-akiya-mpls-entropy-lsp-ping-04] (21 pages) - Label Switched Path (LSP) Ping/Trace Multipath Support for Link Aggregation Group (LAG) Interfaces [draft-akiya-mpls-lsp-ping-lag-multipath-05] (27 pages) - Label Switched Path (LSP) Ping/Traceroute Reply Mode Simplification [draft-akiya-mpls-lsp-ping-reply-mode-simple-03] (11 pages) - Updating the IANA MPLS LSP Ping Parameters [draft-andersson-mpls-lsp-ping-registries-update-02] (12 pages) - Updates to RFC 4379 IANA section [draft-andersson-mpls-lsp-ping-upd-00] (4 pages) - MPLS Network Actions Framework [draft-andersson-mpls-mna-fwk-04] (18 pages) - The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols [draft-andersson-mpls-sig-decision-03] (11 pages) - LDP Extensions to Support Maximally Redundant Trees [draft-atlas-mpls-ldp-mrt-03] (16 pages) - Performance-based Path Selection for Explicitly Routed LSPs using TE Metric Extensions [draft-atlas-mpls-te-express-path-04] (10 pages) - Requirements for MPLS Network Action Indicators and MPLS Ancillary Data [draft-bocci-mpls-miad-adi-requirements-04] (10 pages) - LSP Self-Ping [draft-bonica-mpls-self-ping-06] (11 pages) - MPLS Flow Identification Considerations [draft-bryant-mpls-flow-ident-03] (11 pages) - MPLS Performance Measurement UDP Return Path [draft-bryant-mpls-oam-udp-return-02] (8 pages) - RFC6374 Synonymous Flow Labels [draft-bryant-mpls-rfc6374-sfl-04] (20 pages) - A Simple Control Protocol for MPLS SFLs [draft-bryant-mpls-sfl-control-09] (14 pages) - Synonymous Flow Label Framework [draft-bryant-mpls-sfl-framework-05] (10 pages) - MPLS Segment Routing in IP Networks [draft-bryant-mpls-unified-ip-sr-03] (18 pages) - PSC protocol updates for non-revertive operation [draft-cdh-mpls-tp-psc-non-revertive-01] (23 pages) - Refresh Interval Independent FRR Facility Protection [draft-chandra-mpls-ri-rsvp-frr-04] (24 pages) - Encapsulation For MPLS Performance Measurement with Alternate Marking Method [draft-cheng-mpls-inband-pm-encapsulation-04] (14 pages) - MPLS-TP Shared-Ring protection (MSRP) mechanism for ring topology [draft-cheng-mpls-tp-shared-ring-protection-06] (46 pages) - Extensions to RSVP-TE for LSP Egress Local Protection [draft-chen-mpls-p2mp-egress-protection-11] (15 pages) - Extensions to RSVP-TE for LSP Ingress Local Protection [draft-chen-mpls-p2mp-ingress-protection-11] (28 pages) - MultiProtocol Label Switching (MPLS) Source Label [draft-chen-mpls-source-label-06] (13 pages) - Use Cases and Requirements for MPLS-TP multi-failure protection [draft-cui-mpls-tp-mfp-use-case-and-requirements-08] (8 pages) - IANA registries for LSP ping Code Points [draft-decraene-mpls-lsp-ping-registry-00] (6 pages) - Supporting the Exercise command for PSC linear protection protocol [draft-dj-mpls-tp-exer-psc-02] (10 pages) - Application-aware Targeted LDP [draft-esale-mpls-app-aware-tldp-03] (17 pages) - LDP Extensions for RMR [draft-esale-mpls-ldp-rmr-extensions-02] (13 pages) - An MPLS-Based Forwarding Plane for Service Function Chaining [draft-farrel-mpls-sfc-05] (24 pages) - MPLS Data Plane Encapsulation for In-situ OAM Data [draft-gandhi-mpls-ioam-sr-06] (17 pages) - MPLS Network Actions for Transporting In Situ Operations, Administration, and Maintenance (IOAM) Data Fields and Direct Exporting [draft-gandhi-mpls-mna-ioam-dex-01] (14 pages) - Performance Measurement Using RFC 6374 for Segment Routing Networks with MPLS Data Plane [draft-gandhi-mpls-rfc6374-sr-05] (20 pages) - Gap Analysis for Operating IPv6-only MPLS Networks [draft-george-mpls-ipv6-only-gap-05] (24 pages) - Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Egress Peer Engineering Segment Identifiers (SIDs) with MPLS Data Planes [draft-hegde-mpls-spring-epe-oam-07] (17 pages) - IANA Registry for the First Nibble Following a Label Stack [draft-ietf-mpls-1stnibble-09] (17 pages) - Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages [draft-ietf-mpls-3209-patherr-06] (7 pages) - Application-Aware Targeted LDP [draft-ietf-mpls-app-aware-tldp-09] (18 pages) - Multiprotocol Label Switching Architecture [draft-ietf-mpls-arch-07] (61 pages) - MPLS using LDP and ATM VC Switching [draft-ietf-mpls-atm-04] (20 pages) - A YANG Data Model for MPLS Base [draft-ietf-mpls-base-yang-17] (29 pages) - Bidirectional Forwarding Detection (BFD) Directed Return Path for MPLS Label Switched Paths (LSPs) [draft-ietf-mpls-bfd-directed-31] (12 pages) - Carrying Label Information in BGP-4 [draft-ietf-mpls-bgp4-mpls-05] (8 pages) - Graceful Restart Mechanism for BGP with MPLS [draft-ietf-mpls-bgp-mpls-restart-05] (10 pages) - Link Bundling in MPLS Traffic Engineering (TE) [draft-ietf-mpls-bundle-06] (12 pages) - Link Bundling Management Information Base [draft-ietf-mpls-bundle-mib-04] (52 pages) - Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field [draft-ietf-mpls-cosfield-def-08] (9 pages) - Constraint-Based LSP Setup using LDP [draft-ietf-mpls-cr-ldp-06] (42 pages) - Applicability Statement for CR-LDP [draft-ietf-mpls-crldp-applic-01] (7 pages) - Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol) [draft-ietf-mpls-crldp-unnum-10] (8 pages) - LSP Modification Using CR-LDP [draft-ietf-mpls-crlsp-modify-03] (11 pages) - Deprecation of BGP Entropy Label Capability Attribute [draft-ietf-mpls-deprecate-bgp-entropy-label-02] (4 pages) - Multi-Protocol Label Switching (MPLS) Support of Differentiated Services [draft-ietf-mpls-diff-ext-09] (64 pages) - Avoiding Equal Cost Multipath Treatment in MPLS Networks [draft-ietf-mpls-ecmp-bcp-03] (8 pages) - MPLS Egress Protection Framework [draft-ietf-mpls-egress-protection-framework-07] (25 pages) - Egress Validation in Label Switched Path Ping and Traceroute Mechanisms [draft-ietf-mpls-egress-tlv-for-nil-fec-15] (13 pages) - The Use of Entropy Labels in MPLS Forwarding [draft-ietf-mpls-entropy-label-06] (25 pages) - Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy Labels (ELs) [draft-ietf-mpls-entropy-lsp-ping-05] (23 pages) - Removing a Restriction on the use of MPLS Explicit NULL [draft-ietf-mpls-explicit-null-02] (7 pages) - Component Link Recording and Resource Control for TE Links [draft-ietf-mpls-explicit-resource-control-bundle-10] (13 pages) - Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE) [draft-ietf-mpls-extended-admin-group-07] (7 pages) - Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute [draft-ietf-mpls-fastreroute-mib-21] (53 pages) - MPLS Flow Identification Considerations [draft-ietf-mpls-flow-ident-07] (11 pages) - MPLS Forwarding Compliance and Performance Requirements [draft-ietf-mpls-forwarding-09] (59 pages) - Use of Label Switching on Frame Relay Networks Specification [draft-ietf-mpls-fr-06] (24 pages) - Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB) [draft-ietf-mpls-ftn-mib-09] (42 pages) - MPLS Generic Associated Channel (G-ACh) Advertisement Protocol [draft-ietf-mpls-gach-adv-08] (23 pages) - The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol [draft-ietf-mpls-git-uus-04] (25 pages) - PathErr Message Triggered MPLS and GMPLS LSP Reroutes [draft-ietf-mpls-gmpls-lsp-reroute-06] (12 pages) - Codepoint Registry for the Flags Field in the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Session Attribute Object [draft-ietf-mpls-iana-rsvp-session-flags-01] (5 pages) - ICMP Extensions for Multiprotocol Label Switching [draft-ietf-mpls-icmp-08] (8 pages) - LDP IGP Synchronization [draft-ietf-mpls-igp-sync-01] (8 pages) - Encapsulation For MPLS Performance Measurement with Alternate-Marking Method [draft-ietf-mpls-inband-pm-encapsulation-18] (17 pages) - Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) [draft-ietf-mpls-in-ip-or-gre-08] (14 pages) - Detecting MPLS Data Plane Failures in Inter-AS and inter-provider Scenarios [draft-ietf-mpls-interas-lspping-00] (18 pages) - Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment [draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp-01] (17 pages) - Encapsulating MPLS in UDP [draft-ietf-mpls-in-udp-11] (19 pages) - Label Edge Router Forwarding of IPv4 Option Packets [draft-ietf-mpls-ip-options-07] (9 pages) - Gap Analysis for Operating IPv6-Only MPLS Networks [draft-ietf-mpls-ipv6-only-gap-04] (28 pages) - Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6 [draft-ietf-mpls-ipv6-pw-lsp-ping-04] (8 pages) - MPLS Label Stack Encoding [draft-ietf-mpls-label-encaps-08] (23 pages) - Multiprotocol Label Switching (MPLS) Label-Controlled Asynchronous Transfer Mode (ATM) and Frame-Relay Management Interface Definition [draft-ietf-mpls-lc-if-mib-08] (22 pages) - LDP Specification [draft-ietf-mpls-ldp-11] (132 pages) - LDP Applicability [draft-ietf-mpls-ldp-applic-02] (7 pages) - Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs) [draft-ietf-mpls-ldp-applicability-label-adv-03] (8 pages) - LDP Capabilities [draft-ietf-mpls-ldp-capabilities-04] (12 pages) - LDP Downstream-on-Demand in Seamless MPLS [draft-ietf-mpls-ldp-dod-09] (35 pages) - Signaling LDP Label Advertisement Completion [draft-ietf-mpls-ldp-end-of-lib-04] (9 pages) - Experience with the Label Distribution Protocol (LDP) [draft-ietf-mpls-ldp-experience-00] (7 pages) - Fault Tolerance for the Label Distribution Protocol (LDP) [draft-ietf-mpls-ldp-ft-06] (52 pages) - The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP) [draft-ietf-mpls-ldp-gtsm-09] (8 pages) - LDP Hello Cryptographic Authentication [draft-ietf-mpls-ldp-hello-crypto-auth-10] (14 pages) - Label Distribution Protocol (LDP) Internet Assigned Numbers Authority (IANA) Considerations Update [draft-ietf-mpls-ldp-iana-01] (5 pages) - LDP IGP Synchronization [draft-ietf-mpls-ldp-igp-sync-04] (7 pages) - LDP IGP Synchronization for Broadcast Networks [draft-ietf-mpls-ldp-igp-sync-bcast-06] (9 pages) - LDP Extension for Inter-Area Label Switched Paths (LSPs) [draft-ietf-mpls-ldp-interarea-04] (12 pages) - Controlling State Advertisements of Non-negotiated LDP Applications [draft-ietf-mpls-ldp-ip-pw-capability-09] (15 pages) - Updates to LDP for IPv6 [draft-ietf-mpls-ldp-ipv6-17] (24 pages) - Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP) [draft-ietf-mpls-ldp-mib-14] (106 pages) - YANG Data Model for MPLS LDP and mLDP [draft-ietf-mpls-ldp-mldp-yang-00] (115 pages) - LDP Extensions to Support Maximally Redundant Trees [draft-ietf-mpls-ldp-mrt-07] (21 pages) - Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol [draft-ietf-mpls-ldp-mtu-extensions-03] (9 pages) - LDP Extensions for Multi-Topology [draft-ietf-mpls-ldp-multi-topology-12] (20 pages) - Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths [draft-ietf-mpls-ldp-p2mp-15] (39 pages) - Graceful Restart Mechanism for Label Distribution Protocol [draft-ietf-mpls-ldp-restart-06] (12 pages) - Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP) [draft-ietf-mpls-ldp-restart-applic-01] (16 pages) - LDP Extensions for RMR [draft-ietf-mpls-ldp-rmr-extensions-03] (13 pages) - LDP State Machine [draft-ietf-mpls-ldp-state-04] (78 pages) - The Label Distribution Protocol (LDP) Implementation Survey Results [draft-ietf-mpls-ldp-survey2002-00] (23 pages) - Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC) [draft-ietf-mpls-ldp-typed-wildcard-07] (10 pages) - MPLS Upstream Label Assignment for LDP [draft-ietf-mpls-ldp-upstream-10] (13 pages) - YANG Data Model for MPLS LDP [draft-ietf-mpls-ldp-yang-09] (79 pages) - Link Management Protocol (LMP) [draft-ietf-mpls-lmp-02] (58 pages) - MPLS Loop Prevention Mechanism [draft-ietf-mpls-loop-prevention-03] (44 pages) - Packet Loss and Delay Measurement for MPLS Networks [draft-ietf-mpls-loss-delay-04] (52 pages) - Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE) [draft-ietf-mpls-lsp-hierarchy-08] (14 pages) - Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures [draft-ietf-mpls-lsp-ping-13] (50 pages) - Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels [draft-ietf-mpls-lsp-ping-enhanced-dsmap-11] (23 pages) - Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces [draft-ietf-mpls-lsp-ping-lag-multipath-08] (29 pages) - Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using Label Switched Path (LSP) Ping [draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-16] (29 pages) - Deprecating the Use of Router Alert in LSP Ping [draft-ietf-mpls-lspping-norao-08] (10 pages) - OSPFv3 Code Point for MPLS LSP Ping [draft-ietf-mpls-lsp-ping-ospfv3-codepoint-06] (6 pages) - Updating the MPLS Label Switched Paths (LSPs) Ping Parameters IANA Registry [draft-ietf-mpls-lsp-ping-registries-update-11] (31 pages) - IANA Registries for LSP Ping Code Points [draft-ietf-mpls-lsp-ping-registry-03] (7 pages) - Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping [draft-ietf-mpls-lsp-ping-relay-reply-11] (18 pages) - Label Switched Path (LSP) Ping and Traceroute Reply Mode Simplification [draft-ietf-mpls-lsp-ping-reply-mode-simple-05] (17 pages) - Definition of Time to Live TLV for LSP-Ping Mechanisms [draft-ietf-mpls-lsp-ping-ttl-tlv-10] (8 pages) - Multi Protocol Label Switching Label Distribution Protocol Query Message Description [draft-ietf-mpls-lsp-query-09] (19 pages) - Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB) [draft-ietf-mpls-lsr-mib-14] (60 pages) - Label Switching Router Self-Test [draft-ietf-mpls-lsr-self-test-07] (15 pages) - Multiprotocol Label Switching (MPLS) Management Overview [draft-ietf-mpls-mgmt-overview-09] (32 pages) - Requirements for MPLS Network Action Indicators and MPLS Ancillary Data [draft-ietf-mpls-miad-mna-requirements-00] (22 pages) - LDP Extensions for Hub and Spoke Multipoint Label Switched Path [draft-ietf-mpls-mldp-hsmp-06] (15 pages) - Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths [draft-ietf-mpls-mldp-in-band-signaling-08] (12 pages) - Multipoint LDP (mLDP) In-Band Signaling with Wildcards [draft-ietf-mpls-mldp-in-band-wildcard-encoding-03] (16 pages) - mLDP Extensions for Multi-Topology Routing [draft-ietf-mpls-mldp-multi-topology-09] (16 pages) - Multipoint LDP (mLDP) Node Protection [draft-ietf-mpls-mldp-node-protection-08] (19 pages) - Using Multipoint LDP When the Backbone Has No Route to the Root [draft-ietf-mpls-mldp-recurs-fec-04] (12 pages) - YANG Data Model for MPLS mLDP [draft-ietf-mpls-mldp-yang-11] (74 pages) - MPLS Network Actions (MNA) Framework [draft-ietf-mpls-mna-fwk-10] (21 pages) - MPLS Network Action (MNA) Sub-Stack Solution [draft-ietf-mpls-mna-hdr-08] (28 pages) - Requirements for Solutions that Support MPLS Network Actions (MNA) [draft-ietf-mpls-mna-requirements-16] (12 pages) - Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data [draft-ietf-mpls-mna-usecases-13] (14 pages) - Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry [draft-ietf-mpls-moving-iana-registries-04] (7 pages) - Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol [draft-ietf-mpls-mp-ldp-reqs-08] (20 pages) - Security Framework for MPLS and GMPLS Networks [draft-ietf-mpls-mpls-and-gmpls-security-framework-09] (66 pages) - YANG Data Model for Maximum SID Depth Types and MPLS Maximum SID Depth [draft-ietf-mpls-msd-yang-12] (15 pages) - Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment [draft-ietf-mpls-multicast-08] (30 pages) - MPLS Multicast Encapsulations [draft-ietf-mpls-multicast-encaps-10] (11 pages) - Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP) [draft-ietf-mpls-multipath-use-04] (15 pages) - Definition of a Record Route Object (RRO) Node-Id Sub-Object [draft-ietf-mpls-nodeid-subobject-07] (10 pages) - A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link [draft-ietf-mpls-number-0-bw-te-lsps-12] (8 pages) - A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM) [draft-ietf-mpls-oam-frmwk-05] (11 pages) - IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM) [draft-ietf-mpls-oam-ipv6-rao-03] (6 pages) - Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks [draft-ietf-mpls-oam-requirements-07] (15 pages) - Opportunistic Security in MPLS Networks [draft-ietf-mpls-opportunistic-encrypt-03] (38 pages) - Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3 [draft-ietf-mpls-over-l2tpv3-03] (12 pages) - BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP [draft-ietf-mpls-p2mp-bfd-08] (12 pages) - Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping [draft-ietf-mpls-p2mp-lsp-ping-18] (28 pages) - Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks [draft-ietf-mpls-p2mp-oam-reqs-01] (14 pages) - Requirements for Point to Multipoint Traffic Engineered MPLS LSPs [draft-ietf-mpls-p2mp-requirement-04] (34 pages) - Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs) [draft-ietf-mpls-p2mp-sig-requirement-04] (30 pages) - Point-to-Multipoint Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) module [draft-ietf-mpls-p2mp-te-mib-09] (62 pages) - Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP) [draft-ietf-mpls-pim-sm-over-mldp-03] (11 pages) - MPLS Performance Measurement UDP Return Path [draft-ietf-mpls-pm-udp-return-00] (8 pages) - Proxy MPLS Echo Request [draft-ietf-mpls-proxy-lsp-ping-05] (28 pages) - Updates to MPLS Transport Profile Linear Protection [draft-ietf-mpls-psc-updates-06] (11 pages) - Framework for Multi-Protocol Label Switching (MPLS)-based Recovery [draft-ietf-mpls-recovery-frmwrk-08] (40 pages) - Proxy LSP Ping [draft-ietf-mpls-remote-lsp-ping-03] (19 pages) - Residence Time Measurement in MPLS Networks [draft-ietf-mpls-residence-time-15] (30 pages) - Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel [draft-ietf-mpls-retire-ach-tlv-03] (5 pages) - Return Path Specified Label Switched Path (LSP) Ping [draft-ietf-mpls-return-path-specified-lsp-ping-15] (21 pages) - LDP Specification [draft-ietf-mpls-rfc3036bis-04] (135 pages) - Using BGP to Bind MPLS Labels to Address Prefixes [draft-ietf-mpls-rfc3107bis-04] (23 pages) - Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures [draft-ietf-mpls-rfc4379bis-09] (78 pages) - RFC6374 Synonymous Flow Labels [draft-ietf-mpls-rfc6374-sfl-10] (21 pages) - Performance Measurement for Segment Routing Networks with MPLS Data Plane [draft-ietf-mpls-rfc6374-sr-11] (20 pages) - UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks [draft-ietf-mpls-rfc6374-udp-return-path-05] (10 pages) - Clarification of Segment ID Sub-TLV Length for RFC 8287 [draft-ietf-mpls-rfc8287-len-clarification-04] (7 pages) - Refresh-interval Independent FRR Facility Protection [draft-ietf-mpls-ri-rsvp-frr-22] (28 pages) - Resilient MPLS Rings [draft-ietf-mpls-rmr-14] (20 pages) - Resilient MPLS Rings and Multicast [draft-ietf-mpls-rmr-multicast-00] (7 pages) - Fast Reroute Extensions to RSVP-TE for LSP Tunnels [draft-ietf-mpls-rsvp-lsp-fastreroute-07] (38 pages) - RSVP-TE: Extensions to RSVP for LSP Tunnels [draft-ietf-mpls-rsvp-lsp-tunnel-09] (61 pages) - Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane [draft-ietf-mpls-rsvp-shared-labels-09] (24 pages) - Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) [draft-ietf-mpls-rsvpte-attributes-05] (21 pages) - Hub and Spoke Multipoint Label Switched Path Tunnels [draft-ietf-mpls-rsvp-te-hsmp-lsp-01] (8 pages) - Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths [draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09] (10 pages) - Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs) [draft-ietf-mpls-rsvp-te-p2mp-07] (53 pages) - Applicability Statement for Extensions to RSVP for LSP-Tunnels [draft-ietf-mpls-rsvp-tunnel-applicability-02] (8 pages) - Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) [draft-ietf-mpls-rsvp-unnum-08] (9 pages) - Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs) [draft-ietf-mpls-seamless-mcast-17] (42 pages) - Seamless MPLS Architecture [draft-ietf-mpls-seamless-mpls-07] (42 pages) - Label Switched Path (LSP) Self-Ping [draft-ietf-mpls-self-ping-06] (12 pages) - An MPLS-Based Forwarding Plane for Service Function Chaining [draft-ietf-mpls-sfc-07] (32 pages) - MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH) [draft-ietf-mpls-sfc-encapsulation-04] (9 pages) - Synonymous Flow Label Framework [draft-ietf-mpls-sfl-framework-11] (9 pages) - Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection [draft-ietf-mpls-smp-requirements-09] (16 pages) - MPLS Traffic Engineering Soft Preemption [draft-ietf-mpls-soft-preemption-18] (13 pages) - Allocating and Retiring Special-Purpose MPLS Labels [draft-ietf-mpls-special-purpose-labels-06] (11 pages) - Special-Purpose Label Terminology [draft-ietf-mpls-spl-terminology-06] (8 pages) - Entropy Label for Source Packet Routing in Networking (SPRING) Tunnels [draft-ietf-mpls-spring-entropy-label-12] (22 pages) - Path Monitoring System/Head-end based MPLS Ping and Traceroute in Inter-domain Segment Routing Networks [draft-ietf-mpls-spring-inter-domain-oam-20] (27 pages) - Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes [draft-ietf-mpls-spring-lsp-ping-13] (25 pages) - Label Switched Path (LSP) Ping for Segment Routing (SR) Path Segment Identifier with MPLS Data Planes [draft-ietf-mpls-spring-lsp-ping-path-sid-02] (17 pages) - Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Egress Peer Engineering Segment Identifiers (SIDs) with MPLS Data Plane [draft-ietf-mpls-sr-epe-oam-19] (18 pages) - MPLS Segment Routing over IP [draft-ietf-mpls-sr-over-ip-07] (17 pages) - A YANG Data Model for MPLS Static LSPs [draft-ietf-mpls-static-yang-14] (14 pages) - RSVP-TE Summary Fast Reroute Extensions for Label Switched Path (LSP) Tunnels [draft-ietf-mpls-summary-frr-rsvpte-09] (18 pages) - Using LDP Multipoint Extensions on Targeted LDP Sessions [draft-ietf-mpls-targeted-mldp-04] (9 pages) - Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management [draft-ietf-mpls-tc-mib-10] (20 pages) - Performance-based Path Selection for Explicitly Routed LSPs using TE Metric Extensions [draft-ietf-mpls-te-express-path-00] (10 pages) - Improving Topology Data Base Accuracy with Label Switched Path Feedback in Constraint Based Label Distribution Protocol [draft-ietf-mpls-te-feed-06] (13 pages) - Traffic Engineering Link Management Information Base [draft-ietf-mpls-telink-mib-07] (54 pages) - Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) [draft-ietf-mpls-te-mib-14] (68 pages) - An Analysis of Scaling Issues in MPLS-TE Core Networks [draft-ietf-mpls-te-scaling-analysis-05] (45 pages) - MPLS-TP 1toN Protection [draft-ietf-mpls-tp-1ton-protection-02] (36 pages) - Definition of ACH TLV Structure [draft-ietf-mpls-tp-ach-tlv-02] (9 pages) - Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode [draft-ietf-mpls-tp-aps-updates-04] (9 pages) - Proactive Connection Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile [draft-ietf-mpls-tp-bfd-cc-cv-00] (12 pages) - Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile [draft-ietf-mpls-tp-cc-cv-rdi-06] (21 pages) - MPLS Transport Profile Data Plane Architecture [draft-ietf-mpls-tp-data-plane-04] (15 pages) - MPLS Transport Profile (MPLS-TP) Next-Hop Ethernet Addressing [draft-ietf-mpls-tp-ethernet-addressing-08] (9 pages) - MPLS Fault Management Operations, Administration, and Maintenance (OAM) [draft-ietf-mpls-tp-fault-07] (17 pages) - A Framework for MPLS in Transport Networks [draft-ietf-mpls-tp-framework-12] (56 pages) - An In-Band Data Communication Network For the MPLS Transport Profile [draft-ietf-mpls-tp-gach-dcn-06] (8 pages) - MPLS Generic Associated Channel [draft-ietf-mpls-tp-gach-gal-06] (19 pages) - MPLS Transport Profile (MPLS-TP) Identifiers [draft-ietf-mpls-tp-identifiers-07] (17 pages) - MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions [draft-ietf-mpls-tp-itu-t-identifiers-08] (12 pages) - MPLS Transport Profile Lock Instruct and Loopback Functions [draft-ietf-mpls-tp-li-lb-08] (12 pages) - MPLS Transport Profile (MPLS-TP) Linear Protection [draft-ietf-mpls-tp-linear-protection-09] (45 pages) - MPLS Transport Profile Linear Protection MIB [draft-ietf-mpls-tp-linear-protection-mib-12] (48 pages) - Packet Loss and Delay Measurement for the MPLS Transport Profile [draft-ietf-mpls-tp-loss-delay-00] (30 pages) - A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks [draft-ietf-mpls-tp-loss-delay-profile-04] (5 pages) - LSP-Ping and BFD encapsulation over ACH [draft-ietf-mpls-tp-lsp-ping-bfd-procedures-01] (9 pages) - Use Cases and Requirements for MPLS-TP multi-failure protection [draft-ietf-mpls-tp-mfp-use-case-and-requirements-03] (9 pages) - Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview [draft-ietf-mpls-tp-mib-management-overview-08] (29 pages) - Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs) [draft-ietf-mpls-tp-mip-mep-map-09] (11 pages) - Network Management Framework for MPLS-based Transport Networks [draft-ietf-mpls-tp-nm-framework-05] (18 pages) - Network Management Requirements for MPLS-based Transport Networks [draft-ietf-mpls-tp-nm-req-06] (24 pages) - An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks [draft-ietf-mpls-tp-oam-analysis-09] (21 pages) - Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks [draft-ietf-mpls-tp-oam-framework-11] (62 pages) - MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB) [draft-ietf-mpls-tp-oam-id-mib-11] (36 pages) - Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks [draft-ietf-mpls-tp-oam-requirements-06] (17 pages) - MPLS On-Demand Connectivity Verification and Route Tracing [draft-ietf-mpls-tp-on-demand-cv-07] (22 pages) - A Framework for Point-to-Multipoint MPLS in Transport Networks [draft-ietf-mpls-tp-p2mp-framework-06] (12 pages) - MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators [draft-ietf-mpls-tp-psc-itu-04] (40 pages) - Requirements of an MPLS Transport Profile [draft-ietf-mpls-tp-requirements-10] (31 pages) - Applicability of MPLS Transport Profile for Ring Topologies [draft-ietf-mpls-tp-ring-protection-06] (30 pages) - A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations [draft-ietf-mpls-tp-rosetta-stone-13] (21 pages) - MPLS Transport Profile (MPLS-TP) Security Framework [draft-ietf-mpls-tp-security-framework-09] (15 pages) - MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology [draft-ietf-mpls-tp-shared-ring-protection-06] (56 pages) - MPLS Transport Profile (MPLS-TP) Survivability Framework [draft-ietf-mpls-tp-survive-fwk-06] (56 pages) - MPLS Transport Profile (MPLS-TP) Traffic Engineering (TE) Management Information Base (MIB) [draft-ietf-mpls-tp-te-mib-11] (62 pages) - Requirements for Hitless MPLS Path Segment Monitoring [draft-ietf-mpls-tp-temporal-hitless-psm-14] (16 pages) - MPLS Transport Profile User-to-Network and Network-to-Network Interfaces [draft-ietf-mpls-tp-uni-nni-03] (6 pages) - MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design [draft-ietf-mpls-tp-use-cases-and-design-08] (16 pages) - Requirements for Traffic Engineering Over MPLS [draft-ietf-mpls-traffic-eng-01] (29 pages) - Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks [draft-ietf-mpls-ttl-04] (10 pages) - MPLS Upstream Label Assignment and Context-Specific Label Space [draft-ietf-mpls-upstream-label-07] (13 pages) - VCID Notification over ATM link for LDP [draft-ietf-mpls-vcid-atm-05] (19 pages) - LDP Specification [draft-ijln-mpls-rfc5036bis-04] (141 pages) - MPLS Network Action (MNA) Sub-Stack Solution [draft-jags-mpls-mna-hdr-05] (30 pages) - Hub and Spoke Multipoint Label Switched Path Tunnels [draft-jjb-mpls-rsvp-te-hsmp-lsp-04] (8 pages) - Entropy labels for source routed stacked tunnels [draft-kini-mpls-spring-entropy-label-03] (11 pages) - Label Distribution Using ARP [draft-kompella-mpls-larp-11] (12 pages) - Deprecating the Use of Router Alert in LSP Ping [draft-kompella-mpls-lspping-norao-02] (7 pages) - Resilient MPLS Rings [draft-kompella-mpls-rmr-02] (14 pages) - Multi-path Label Switched Paths Signaled Using RSVP-TE [draft-kompella-mpls-rsvp-ecmp-06] (19 pages) - Allocating and Retiring Special Purpose MPLS Labels [draft-kompella-mpls-special-purpose-labels-04] (9 pages) - Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using MPLS Dataplane [draft-kumarkini-mpls-spring-lsp-ping-06] (17 pages) - Moving Generic Associated Channel (G-ACh) IANA registries to a new registry [draft-lcap-mpls-moving-iana-registries-02] (7 pages) - Proxy MPLS Echo Request [draft-lim-mpls-proxy-lsp-ping-03] (24 pages) - Entropy Values [draft-li-mpls-entropy-01] (41 pages) - Management Information Base for MPLS LDP Multi Topology [draft-li-mpls-ldp-mt-mib-06] (29 pages) - MPLS Network Actions for No Further Fast Reroute [draft-li-mpls-mna-nffrr-01] (5 pages) - MPLS Network Actions for Network Resource Partition Selector [draft-li-mpls-mna-nrp-selector-01] (8 pages) - MPLS Encapsulation for SFC NSH [draft-malis-mpls-sfc-encapsulation-03] (7 pages) - Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management [draft-manral-mpls-rfc3811bis-04] (24 pages) - Supporting In-Situ Operations, Administration, and Maintenance Direct Export Using MPLS Network Actions [draft-mb-mpls-ioam-dex-08] (10 pages) - Bidirectional Forwarding Detection (BFD) Directed Return Path [draft-mirsky-mpls-bfd-directed-04] (10 pages) - BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP [draft-mirsky-mpls-p2mp-bfd-15] (11 pages) - Residence Time Measurement in MPLS network [draft-mirsky-mpls-residence-time-07] (23 pages) - RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels [draft-mtaillon-mpls-summary-frr-rsvpte-05] (16 pages) - YANG Data Model for MPLS LSP Ping [draft-nainar-mpls-lsp-ping-yang-06] (38 pages) - RFC8287 Sub-TLV Length Clarification [draft-nainar-mpls-rfc8287-len-clarification-00] (6 pages) - PMS/Head-end based MPLS Ping and Traceroute in Inter-domain SR Networks [draft-ninan-mpls-spring-inter-domain-oam-04] (22 pages) - Extended Administrative Groups in MPLS-TE [draft-osborne-mpls-extended-admin-groups-03] (6 pages) - Updates to PSC [draft-osborne-mpls-psc-updates-03] (8 pages) - "MPLS LSP Ping TLVs and sub-TLVs registry" [draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02] (17 pages) - A YANG Model for MPLS MSD [draft-qu-mpls-mpls-msd-yang-07] (9 pages) - Entropy label for seamless MPLS [draft-ravisingh-mpls-el-for-seamless-mpls-04] (24 pages) - LDP IP and PW Capability [draft-raza-mpls-ldp-ip-pw-capability-01] (11 pages) - YANG Data Model for MPLS LDP and mLDP [draft-raza-mpls-ldp-mldp-yang-04] (114 pages) - IPv6 Router Alert Option for MPLS OAM [draft-raza-mpls-oam-ipv6-rao-02] (5 pages) - Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs [draft-rekhter-mpls-pim-sm-over-mldp-08] (12 pages) - Priority Modification for the PSC Linear Protection [draft-rhd-mpls-tp-psc-priority-01] (11 pages) - Supporting Signal Degrade in PSC Linear Protection [draft-rhd-mpls-tp-psc-sd-01] (27 pages) - Using BGP to Bind MPLS Labels to Address Prefixes [draft-rosen-mpls-rfc3107bis-01] (22 pages) - MPLS Transport Profile (MPLS-TP) Linear Protection in Support of ITU-T's Requirements [draft-ryoogray-mpls-tp-psc-itu-01] (31 pages) - Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode [draft-ryoo-mpls-tp-aps-updates-03] (7 pages) - A YANG Data Model for MPLS Base [draft-saad-mpls-base-yang-00] (10 pages) - Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data [draft-saad-mpls-miad-usecases-02] (12 pages) - A YANG Data Model for MPLS Static LSPs [draft-saad-mpls-static-yang-03] (13 pages) - Deprecation of BGP Entropy Label Capability Attribute [draft-scudder-mpls-deprecate-bgp-entropy-label-00] (3 pages) - MPLS Egress Protection Framework [draft-shen-mpls-egress-protection-framework-07] (27 pages) - Signaling RSVP-TE tunnels on a shared MPLS forwarding plane [draft-sitaraman-mpls-rsvp-shared-labels-03] (21 pages) - Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures [draft-smack-mpls-rfc4379bis-09] (52 pages) - MPLS Network Actions using Post-Stack Extension Headers [draft-song-mpls-extension-header-13] (14 pages) - The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) [draft-sprecher-mpls-tp-oam-considerations-03] (33 pages) - Definitions of Managed Objects for the LDP Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths [draft-tiruveedhula-mpls-mldp-mib-05] (37 pages) - Reoptimization of Point-to-Multipoint Traffic Engineering Loosely Routed LSPs [draft-tsaad-mpls-p2mp-loose-path-reopt-03] (11 pages) - Handling the TC and TTL fields in a Label Stack Entry that Contains the Generic Associated Channel Label [draft-vainshtein-mpls-gal-tc-ttl-handling-03] (7 pages) - MPLS Forwarding Compliance and Performance Requirements [draft-villamizar-mpls-forwarding-02] (50 pages) - Use of Multipath with MPLS-TP and MPLS [draft-villamizar-mpls-multipath-use-02] (13 pages) - MPLS-TP Traffic Engineering (TE) Management Information Base (MIB) [draft-vkst-mpls-tp-te-mib-02] (39 pages) - Requirements for MPLS Shared Mesh Protection [draft-weingarten-mpls-smp-requirements-03] (13 pages) - mLDP In-Band Signaling with Wildcards [draft-wijnands-mpls-mldp-in-band-wildcard-encoding-03] (16 pages) - mLDP Extensions for Multi-Topology Routing [draft-wijnands-mpls-mldp-multi-topology-04] (14 pages) - mLDP Node Protection [draft-wijnands-mpls-mldp-node-protection-04] (16 pages) - Label Switched Path (LSP) Ping for Segment Routing (SR) Path Segment Identifiers (SIDs) with MPLS Data Planes [draft-xp-mpls-spring-lsp-ping-path-sid-09] (17 pages) - SR-MPLS over IP [draft-xu-mpls-sr-over-ip-01] (16 pages) - Unified Source Routing Instructions using MPLS Label Stack [draft-xu-mpls-unified-source-routing-instruction-04] (14 pages) - P2MP Based mLDP Node Protection Mechanisms for mLDP LSP [draft-zhao-mpls-mldp-protections-05] (19 pages) - YANG Data Model for LSP-Ping [draft-zheng-mpls-lsp-ping-yang-cfg-10] (29 pages) - Resilient MPLS Rings and Multicast [draft-zzhang-mpls-rmr-multicast-03] (7 pages) Requests for Comments: RFC2702: Requirements for Traffic Engineering Over MPLS (29 pages) RFC3031: Multiprotocol Label Switching Architecture (61 pages) * Updates RFC6178 * Updates RFC6790 RFC3032: MPLS Label Stack Encoding (23 pages) * Updates RFC3443 * Updates RFC4182 * Updates RFC5332 * Updates RFC3270 * Updates RFC5129 * Updates RFC5462 * Updates RFC5586 * Updates RFC7274 * Updates RFC9017 RFC3033: The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol (25 pages) RFC3034: Use of Label Switching on Frame Relay Networks Specification (24 pages) RFC3035: MPLS using LDP and ATM VC Switching (20 pages) RFC3036: LDP Specification (132 pages) * Obsoletes RFC5036 RFC3037: LDP Applicability (7 pages) RFC3038: VCID Notification over ATM link for LDP (19 pages) * Updates RFC7274 RFC3063: MPLS Loop Prevention Mechanism (44 pages) RFC3107: Carrying Label Information in BGP-4 (8 pages) * Updates RFC6790 * Obsoletes RFC8277 RFC3209: RSVP-TE: Extensions to RSVP for LSP Tunnels (61 pages) * Updates RFC3936 * Updates RFC4420 * Updates RFC4874 * Updates RFC5151 * Updates RFC5420 * Updates RFC5711 * Updates RFC6780 * Updates RFC6790 * Updates RFC7274 RFC3210: Applicability Statement for Extensions to RSVP for LSP-Tunnels (8 pages) RFC3212: Constraint-Based LSP Setup using LDP (42 pages) * Updates RFC3468 * Updates RFC7358 RFC3213: Applicability Statement for CR-LDP (7 pages) RFC3214: LSP Modification Using CR-LDP (11 pages) RFC3215: LDP State Machine (78 pages) RFC3270: Multi-Protocol Label Switching (MPLS) Support of Differentiated Services (64 pages) * Updates RFC5462 RFC3353: Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment (30 pages) RFC3443: Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks (10 pages) * Updates RFC5462 RFC3468: The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols (11 pages) RFC3469: Framework for Multi-Protocol Label Switching (MPLS)-based Recovery (40 pages) * Updates RFC5462 RFC3477: Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) (9 pages) * Updates RFC6107 RFC3478: Graceful Restart Mechanism for Label Distribution Protocol (12 pages) RFC3479: Fault Tolerance for the Label Distribution Protocol (LDP) (52 pages) RFC3480: Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol) (8 pages) RFC3612: Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP) (16 pages) RFC3811: Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management (20 pages) * Updates RFC7274 RFC3812: Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) (68 pages) RFC3813: Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB) (60 pages) RFC3814: Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB) (42 pages) RFC3815: Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP) (106 pages) RFC3988: Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol (9 pages) RFC4023: Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) (14 pages) * Updates RFC5332 RFC4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels (38 pages) * Updates RFC8271 * Updates RFC8537 * Updates RFC8796 RFC4182: Removing a Restriction on the use of MPLS Explicit NULL (7 pages) * Updates RFC5462 * Updates RFC7274 RFC4201: Link Bundling in MPLS Traffic Engineering (TE) (12 pages) RFC4206: Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE) (14 pages) * Updates RFC6001 * Updates RFC6107 RFC4220: Traffic Engineering Link Management Information Base (54 pages) RFC4221: Multiprotocol Label Switching (MPLS) Management Overview (32 pages) RFC4368: Multiprotocol Label Switching (MPLS) Label-Controlled Asynchronous Transfer Mode (ATM) and Frame-Relay Management Interface Definition (22 pages) RFC4377: Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks (15 pages) RFC4378: A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM) (11 pages) RFC4379: Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures (50 pages) * Updates RFC5462 * Updates RFC6424 * Updates RFC6425 * Updates RFC6426 * Updates RFC6829 * Updates RFC7506 * Updates RFC7537 * Updates RFC7743 * Obsoletes RFC8029 RFC4420: Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) (21 pages) * Obsoletes RFC5420 RFC4461: Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs) (30 pages) RFC4561: Definition of a Record Route Object (RRO) Node-Id Sub-Object (10 pages) RFC4687: Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks (14 pages) RFC4781: Graceful Restart Mechanism for BGP with MPLS (10 pages) RFC4817: Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3 (12 pages) RFC4859: Codepoint Registry for the Flags Field in the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Session Attribute Object (5 pages) RFC4875: Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs) (53 pages) * Updates RFC6510 RFC4928: Avoiding Equal Cost Multipath Treatment in MPLS Networks (8 pages) * Updates RFC7274 RFC4950: ICMP Extensions for Multiprotocol Label Switching (8 pages) RFC5036: LDP Specification (135 pages) * Updates RFC6720 * Updates RFC6790 * Updates RFC7358 * Updates RFC7552 RFC5037: Experience with the Label Distribution Protocol (LDP) (7 pages) RFC5038: The Label Distribution Protocol (LDP) Implementation Survey Results (23 pages) RFC5283: LDP Extension for Inter-Area Label Switched Paths (LSPs) (12 pages) RFC5330: A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link (8 pages) RFC5331: MPLS Upstream Label Assignment and Context-Specific Label Space (13 pages) * Updates RFC7274 RFC5332: MPLS Multicast Encapsulations (11 pages) RFC5439: An Analysis of Scaling Issues in MPLS-TE Core Networks (45 pages) RFC5443: LDP IGP Synchronization (7 pages) * Updates RFC6138 RFC5462: Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field (9 pages) RFC5561: LDP Capabilities (12 pages) RFC5586: MPLS Generic Associated Channel (19 pages) * Updates RFC6423 * Updates RFC7026 * Updates RFC7214 * Updates RFC7274 RFC5654: Requirements of an MPLS Transport Profile (31 pages) RFC5710: PathErr Message Triggered MPLS and GMPLS LSP Reroutes (12 pages) RFC5711: Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages (7 pages) RFC5712: MPLS Traffic Engineering Soft Preemption (13 pages) RFC5718: An In-Band Data Communication Network For the MPLS Transport Profile (8 pages) RFC5860: Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks (17 pages) RFC5918: Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC) (10 pages) * Updates RFC7358 RFC5919: Signaling LDP Label Advertisement Completion (9 pages) RFC5920: Security Framework for MPLS and GMPLS Networks (66 pages) RFC5921: A Framework for MPLS in Transport Networks (56 pages) * Updates RFC6215 * Updates RFC7274 RFC5950: Network Management Framework for MPLS-based Transport Networks (18 pages) RFC5951: Network Management Requirements for MPLS-based Transport Networks (24 pages) RFC5960: MPLS Transport Profile Data Plane Architecture (15 pages) * Updates RFC7274 RFC6138: LDP IGP Synchronization for Broadcast Networks (9 pages) RFC6178: Label Edge Router Forwarding of IPv4 Option Packets (9 pages) RFC6215: MPLS Transport Profile User-to-Network and Network-to-Network Interfaces (6 pages) RFC6348: Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol (20 pages) RFC6370: MPLS Transport Profile (MPLS-TP) Identifiers (17 pages) RFC6371: Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks (62 pages) * Updates RFC6435 RFC6372: MPLS Transport Profile (MPLS-TP) Survivability Framework (56 pages) RFC6374: Packet Loss and Delay Measurement for MPLS Networks (52 pages) * Updates RFC7214 RFC6375: A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks (5 pages) RFC6378: MPLS Transport Profile (MPLS-TP) Linear Protection (45 pages) * Updates RFC7214 * Updates RFC7271 * Updates RFC7324 RFC6388: Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (39 pages) * Updates RFC7358 RFC6389: MPLS Upstream Label Assignment for LDP (13 pages) RFC6424: Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels (23 pages) * Updates RFC7537 * Obsoletes RFC8029 RFC6425: Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping (28 pages) RFC6426: MPLS On-Demand Connectivity Verification and Route Tracing (22 pages) RFC6427: MPLS Fault Management Operations, Administration, and Maintenance (OAM) (17 pages) * Updates RFC7214 RFC6428: Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile (21 pages) * Updates RFC7214 RFC6435: MPLS Transport Profile Lock Instruct and Loopback Functions (12 pages) RFC6445: Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute (53 pages) RFC6511: Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths (10 pages) RFC6512: Using Multipoint LDP When the Backbone Has No Route to the Root (12 pages) RFC6639: Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview (29 pages) RFC6669: An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks (21 pages) RFC6670: The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) (33 pages) RFC6720: The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP) (8 pages) * Updates RFC7552 RFC6790: The Use of Entropy Labels in MPLS Forwarding (25 pages) * Updates RFC7274 * Updates RFC7447 * Updates RFC8012 RFC6826: Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (12 pages) * Updates RFC7438 RFC6829: Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6 (8 pages) * Obsoletes RFC8029 RFC6923: MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions (12 pages) RFC6941: MPLS Transport Profile (MPLS-TP) Security Framework (15 pages) RFC6965: MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design (16 pages) RFC6974: Applicability of MPLS Transport Profile for Ring Topologies (30 pages) RFC7026: Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel (5 pages) RFC7032: LDP Downstream-on-Demand in Seamless MPLS (35 pages) RFC7054: Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs) (11 pages) RFC7060: Using LDP Multipoint Extensions on Targeted LDP Sessions (9 pages) RFC7087: A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations (21 pages) RFC7110: Return Path Specified Label Switched Path (LSP) Ping (21 pages) * Updates RFC7737 RFC7140: LDP Extensions for Hub and Spoke Multipoint Label Switched Path (15 pages) * Updates RFC7358 RFC7167: A Framework for Point-to-Multipoint MPLS in Transport Networks (12 pages) RFC7190: Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP) (15 pages) RFC7212: MPLS Generic Associated Channel (G-ACh) Advertisement Protocol (23 pages) RFC7213: MPLS Transport Profile (MPLS-TP) Next-Hop Ethernet Addressing (9 pages) RFC7214: Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry (7 pages) RFC7271: MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators (40 pages) * Updates RFC8234 RFC7274: Allocating and Retiring Special-Purpose MPLS Labels (11 pages) * Updates RFC9017 RFC7307: LDP Extensions for Multi-Topology (20 pages) RFC7308: Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE) (7 pages) RFC7324: Updates to MPLS Transport Profile Linear Protection (11 pages) RFC7325: MPLS Forwarding Compliance and Performance Requirements (59 pages) RFC7349: LDP Hello Cryptographic Authentication (14 pages) RFC7358: Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs) (8 pages) RFC7394: Definition of Time to Live TLV for LSP-Ping Mechanisms (8 pages) RFC7412: Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection (16 pages) RFC7438: Multipoint LDP (mLDP) In-Band Signaling with Wildcards (16 pages) RFC7439: Gap Analysis for Operating IPv6-Only MPLS Networks (28 pages) RFC7442: Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP) (11 pages) RFC7447: Deprecation of BGP Entropy Label Capability Attribute (4 pages) RFC7453: MPLS Transport Profile (MPLS-TP) Traffic Engineering (TE) Management Information Base (MIB) (62 pages) RFC7473: Controlling State Advertisements of Non-negotiated LDP Applications (15 pages) * Updates RFC8223 RFC7506: IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM) (6 pages) RFC7510: Encapsulating MPLS in UDP (19 pages) RFC7524: Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs) (42 pages) * Updates RFC8534 RFC7537: IANA Registries for LSP Ping Code Points (7 pages) * Obsoletes RFC8029 RFC7552: Updates to LDP for IPv6 (24 pages) RFC7555: Proxy MPLS Echo Request (28 pages) RFC7697: MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB) (36 pages) RFC7715: Multipoint LDP (mLDP) Node Protection (19 pages) RFC7737: Label Switched Path (LSP) Ping and Traceroute Reply Mode Simplification (17 pages) RFC7743: Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping (18 pages) RFC7746: Label Switched Path (LSP) Self-Ping (12 pages) RFC7759: Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using Label Switched Path (LSP) Ping (29 pages) RFC7876: UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks (10 pages) RFC8012: Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy Labels (ELs) (23 pages) RFC8029: Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures (78 pages) * Updates RFC8611 * Updates RFC9041 * Updates RFC9570 RFC8150: MPLS Transport Profile Linear Protection MIB (48 pages) RFC8169: Residence Time Measurement in MPLS Networks (30 pages) RFC8223: Application-Aware Targeted LDP (18 pages) RFC8227: MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology (56 pages) RFC8234: Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode (9 pages) RFC8256: Requirements for Hitless MPLS Path Segment Monitoring (16 pages) RFC8277: Using BGP to Bind MPLS Labels to Address Prefixes (23 pages) RFC8287: Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes (25 pages) * Updates RFC8690 * Updates RFC9214 RFC8320: LDP Extensions to Support Maximally Redundant Trees (21 pages) RFC8372: MPLS Flow Identification Considerations (11 pages) RFC8577: Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane (24 pages) RFC8595: An MPLS-Based Forwarding Plane for Service Function Chaining (32 pages) RFC8596: MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH) (9 pages) RFC8611: Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces (29 pages) * Updates RFC9041 RFC8662: Entropy Label for Source Packet Routing in Networking (SPRING) Tunnels (22 pages) RFC8663: MPLS Segment Routing over IP (17 pages) RFC8679: MPLS Egress Protection Framework (25 pages) RFC8690: Clarification of Segment ID Sub-TLV Length for RFC 8287 (7 pages) RFC8796: RSVP-TE Summary Fast Reroute Extensions for Label Switched Path (LSP) Tunnels (18 pages) RFC8957: Synonymous Flow Label Framework (9 pages) RFC8960: A YANG Data Model for MPLS Base (29 pages) RFC9017: Special-Purpose Label Terminology (8 pages) RFC9041: Updating the MPLS Label Switched Paths (LSPs) Ping Parameters IANA Registry (31 pages) RFC9070: YANG Data Model for MPLS LDP (79 pages) RFC9214: OSPFv3 Code Point for MPLS LSP Ping (6 pages) RFC9570: Deprecating the Use of Router Alert in LSP Ping (9 pages) RFC9571: Extension of RFC 6374-Based Performance Measurement Using Synonymous Flow Labels (18 pages) RFC9612: Bidirectional Forwarding Detection (BFD) Reverse Path for MPLS Label Switched Paths (LSPs) (9 pages) RFC9613: Requirements for Solutions that Support MPLS Network Actions (MNAs) (10 pages) Network Virtualization Overlays (nvo3) -------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Matthew Bocci Sam Aldrin Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Gunter Van de Velde Tech Advisor: Ron Bonica Secretary: Yizhou Li Mailing Lists: General Discussion: nvo3@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/nvo3 Archive: https://mailarchive.ietf.org/arch/browse/nvo3/ Description of Working Group: The purpose of the NVO3 WG is to develop a set of protocols and/or protocol extensions that enable network virtualization within a data center (DC) environment that assumes an IP-based underlay. An NVO3 solution provides layer 2 and/or layer 3 services for virtual networks enabling multi-tenancy and workload mobility, addressing the issues described in the problem statement (including management and security), and consistent with the framework previously produced by the NVO3 WG. The NVO3 WG will develop solutions for network virtualization based on the following architectural tenets: - Support for an IP-based underlay data plane - A logically centralized authority for network virtualization Network virtualization approaches that do not adhere to these tenets are explicitly outside of the scope of the NVO3 WG. In pursuit of the solutions described above, the NVO3 WG will document an architecture for network virtualization within a data center environment. The NVO3 WG may produce requirements for a network virtualization control plane, and will select, extend, and/or develop one protocol for each of the functional interfaces identified to support the architecture. Such protocols are expected to fulfill the communication requirements between an End Device and a Network Virtualization Edge (NVE) in cases where the NVE is not co-resident with the End Device, and between an NVE and the Network Virtualization Authority (NVA). The internal mechanisms and protocols of a logically centralized NVA are explicitly out of scope of the NVO3 WG. Architectural issues raised by coexistence of multiple logically centralized control planes in the same data center may be considered by the WG. Inter-DC mechanisms are not in scope of the NVO3 WG at this time. The NVO3 WG may produce requirements for network virtualization data planes based on encapsulation of virtual network traffic over an IP- based underlay data plane. Such requirements should consider OAM and security. Based on these requirements the WG will select, extend, and/or develop one or more data plane encapsulation format(s). Additionally, the WG may document common use-cases for NVO3 solutions. The working group may choose to adopt a protocol or data encapsulation that was previously worked on outside the IETF as the basis for the WG's work. If the NVO3 WG anticipates the adoption of the technologies of another SDO as part of the selected protocols or data encapsulation, the NVO3 WG will first liaise with that SDO to ensure the compatibility of the approach. The NVO3 WG will not consider solutions to network virtualization within a data center environment based on extensions to BGP or LISP protocols. Goals and Milestones: Dec 2019 - Data Plane Requirements submitted for IESG review Mar 2020 - Security Requirements Submitted to IESG Mar 2020 - Security Solutions Submitted to IESG Aug 2020 - Recharter or close working group Aug 2020 - OAM Solution submitted for IESG Review Done - Problem Statement submitted for IESG review Done - Framework document submitted for IESG review Done - Use Cases submitted for IESG review Done - Architecture submitted for IESG review Done - End Device - NVE Control Plane Solution submitted for IESG review Done - Data Plane Solution submitted for IESG review Internet-Drafts: - A Framework for Multicast in NVO3 [draft-ghanwani-nvo3-mcast-framework-00] (15 pages) - Geneve: Generic Network Virtualization Encapsulation [draft-gross-geneve-02] (24 pages) - Generic UDP Encapsulation [draft-herbert-gue-03] (24 pages) - An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3) [draft-ietf-nvo3-arch-08] (35 pages) - BFD for Geneve [draft-ietf-nvo3-bfd-geneve-13] (12 pages) - NVO3 Data Plane Requirements [draft-ietf-nvo3-dataplane-requirements-03] (18 pages) - Network Virtualization Overlays (NVO3) Encapsulation Considerations [draft-ietf-nvo3-encap-12] (26 pages) - Applicability of Ethernet Virtual Private Network (EVPN) to Network Virtualization over Layer 3 (NVO3) Networks [draft-ietf-nvo3-evpn-applicability-06] (23 pages) - Framework for Data Center (DC) Network Virtualization [draft-ietf-nvo3-framework-09] (26 pages) - NVO3 Gap Analysis - Requirements Versus Available Technology Choices [draft-ietf-nvo3-gap-analysis-01] (21 pages) - Geneve: Generic Network Virtualization Encapsulation [draft-ietf-nvo3-geneve-16] (34 pages) - OAM for use in GENEVE [draft-ietf-nvo3-geneve-oam-11] (11 pages) - Generic UDP Encapsulation [draft-ietf-nvo3-gue-05] (37 pages) - Split Network Virtualization Edge (Split-NVE) Control-Plane Requirements [draft-ietf-nvo3-hpvr2nve-cp-req-17] (26 pages) - A Framework for Multicast in Network Virtualization over Layer 3 [draft-ietf-nvo3-mcast-framework-11] (17 pages) - Network Virtualization NVE to NVA Control Protocol Requirements [draft-ietf-nvo3-nve-nva-cp-req-05] (12 pages) - Problem Statement: Overlays for Network Virtualization [draft-ietf-nvo3-overlay-problem-statement-04] (23 pages) - Security Requirements of NVO3 [draft-ietf-nvo3-security-requirements-07] (19 pages) - Use Cases for Data Center Network Virtualization Overlay Networks [draft-ietf-nvo3-use-case-17] (16 pages) - Virtual Machine Mobility Solutions for L2 and L3 Overlay Networks [draft-ietf-nvo3-vmm-16] (17 pages) - Network-related VM Mobility Issues [draft-ietf-nvo3-vm-mobility-issues-03] (11 pages) - Generic Protocol Extension for VXLAN (VXLAN-GPE) [draft-ietf-nvo3-vxlan-gpe-13] (25 pages) - Base YANG Data Model for NVO3 Protocols [draft-ietf-nvo3-yang-cfg-05] (26 pages) - Framework for DC Network Virtualization [draft-lasserre-nvo3-framework-03] (22 pages) - Use Cases for DC Network Virtualization Overlays [draft-mity-nvo3-use-case-04] (17 pages) - Generic Protocol Extension for VXLAN [draft-quinn-vxlan-gpe-04] (22 pages) Requests for Comments: RFC7364: Problem Statement: Overlays for Network Virtualization (23 pages) RFC7365: Framework for Data Center (DC) Network Virtualization (26 pages) RFC8014: An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3) (35 pages) RFC8151: Use Cases for Data Center Network Virtualization Overlay Networks (16 pages) RFC8293: A Framework for Multicast in Network Virtualization over Layer 3 (17 pages) RFC8394: Split Network Virtualization Edge (Split-NVE) Control-Plane Requirements (26 pages) RFC8926: Geneve: Generic Network Virtualization Encapsulation (34 pages) RFC9469: Applicability of Ethernet Virtual Private Network (EVPN) to Network Virtualization over Layer 3 (NVO3) Networks (23 pages) RFC9521: Bidirectional Forwarding Detection (BFD) for Generic Network Virtualization Encapsulation (Geneve) (11 pages) Pseudowire And LDP-enabled Services (pals) ------------------------------------------ Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Andrew G. Malis Stewart Bryant Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Gunter Van de Velde Secretary: Dave Sinicrope Mailing Lists: General Discussion: pals@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/pals Archive: https://mailarchive.ietf.org/arch/browse/pals/ Description of Working Group: Many services that run in the Internet are facilitated in MPLS networks by the Label Distribution Protocol (LDP) and/or are established over pseudowires that emulate point-to-point or point-to-multipoint links and provide communication connectivity that is perceived by its users as an unshared link or circuit of an emulated Layer-1, Layer-2, or Layer-3 service type. Layer-2 Virtual Private Networks (L2VPNs) are one such service that provides an emulation of a "native" service over a packet switched network that is adequately faithful to, but may not be entirely indistinguishable from, the native service itself. The Pseudowire And LDP-enabled Services (PALS) working group is chartered to define, specify, and extend network services based on pseudowires and/or signaled using LDP. In particular, the working group will work on the following services: - All types of MPLS-based and L2TPv3-based pseudowire services including point-to-point and point-to-multipoint pseudowires, single segment and multi-segment pseudowires, single and multi-domain pseudowires, and signaled and statically provisioned pseudowires. - All types of dynamic or static provider-provisioned L2VPNs that operate over pseudowires or that are enabled over MPLS networks using LDP as a control plane mechanism. - IP-only L2VPN solutions (for IP-only services over a packet switched network). The working group may also suggest new services to be supported by LDP or pseudowires and these may be added to the working group charter subject to re-chartering. The working group is also responsible for the maintenance and development of pseudowires formerly carried out by the PWE3 working group The PALS working group will not define any mechanisms that exert control over the underlying packet switched network. When necessary it may, however, recommend or require the use of existing QoS and path control mechanisms between the edge nodes that provide the connectivity to the services. The working group may work on: - New pseudowire encapsulations or types for services emulated over IETF-specified Packet Switched Networks. - Operations, Administration, and Management (OAM) for pseudowires including interworking of OAM for pseudowires and native services, and OAM for other services worked on by PALS (including L2VPNs). But new techniques should be shared with the BFD and MPLS working groups to ensure consistency with existing OAM techniques, and with the LIME working group to provide for consistency of operation. - Protocol extensions for LDP in support of new pseudowire function and new services, but all protocol extensions must be reviewed by the MPLS working group which is responsible for the consistency and stability of LDP. - Mechanisms to enhance pseudowire and L2VPN functionality by including security, protection and restoration, congestion avoidance, and load balancing across parallel packet switched tunnels. - Mechanisms to permit optimization of multicast data traffic within an L2VPN. - Enhancements to increase the scalability of the control plane and data plane of L2VPN solutions and application of L2VPN solutions in the data center, the latter in coordination with the NVO3 working group - L2VPN discovery and membership mechanisms that utilize pseudowire control and management procedures. - Data models for modeling, managing, and operating the services worked on by the PALS working group using SMI or YANG. The PALS working group will not work on L2VPNs enabled using BGP, and where L2VPNs that are within the scope of the PALS working group use BGP to add functionality (for example for discovery of membership of a VPN) this work will be coordinated with the BESS working group. This also includes work on particular types of L2VPNs that support both LDP and BGP signaling, such as VPLS. Any contention between these working groups on the placement of such work will be resolved by the chairs. The PALS working group will coordinate closely with the MPLS working group for all work involving LDP and the MPLS data plane. It will also coordinate with the MPLS working group in developing shared security, and with the BFD and MPLS working groups on OAM solutions. Where extensions to pseudowires are needed to support time or frequency transfer, this work will be done by the PALS working group in consultation with the TICTOC working group. L2TP specifics of L2TPv3-based pseudowires will continue to be the responsibility of the L2TPEXT working group. Goals and Milestones: Done - Submit PW Congestion Considerations to the IESG Done - Submit STP Application of ICCP to the IESG Done - Submit Unified Control Channel for PWs to the IESG Done - Submit Pseudowire Redundancy on S-PE to the IESG Done - Submit MAC Address Withdrawal over Static Pseudowire to the IESG Done - Submit S-PE resilience for statically provisioned MS-PWs to the IESG Done - Submit LDP extensions for PW Binding to LSP Tunnels to the IESG Done - Submit LDP-VPLS for Ethernet Broadcast and Multicast to the IESG Done - Submit PW Endpoint Fast Failure Protection to the IESG Done - Submit P2MP PW Signaling (root initiated) to the IESG Done - Submit MPLS LSP PW status refresh reduction for Static PWs to the IESG Done - Submit PIM Snooping over VPLS to the IESG Done - Submit E-Tree Support in VPLS to the IESG jointly with the BESS WG Done - Submit L2VPN applicability statement for data center applications to the IESG Work transferred to the BESS working group - Submit YANG data model for SS-PWs and MS-PWs to the IESG Internet-Drafts: - Use of Ethernet Control Word RECOMMENDED [draft-bryant-pals-ethernet-cw-01] (8 pages) - Seamless BFD for VCCV [draft-gp-pals-seamless-vccv-01] (10 pages) - Extension to LDP-VPLS for Ethernet Broadcast and Multicast [draft-ietf-l2vpn-ldp-vpls-broadcast-exten-08] (19 pages) - MAC Address Withdrawal over Static Pseudowire [draft-ietf-l2vpn-mpls-tp-mac-wd-00] (8 pages) - Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) [draft-ietf-l2vpn-vpls-pe-etree-11] (26 pages) - Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS) [draft-ietf-l2vpn-vpls-pim-snooping-07] (39 pages) - OAM Procedures for VPWS Interworking [draft-ietf-l2vpn-vpws-iw-oam-04] (13 pages) - Pseudowire Congestion Considerations [draft-ietf-pals-congcons-02] (27 pages) - Pseudowire (PW) Endpoint Fast Failure Protection [draft-ietf-pals-endpoint-fast-protection-05] (43 pages) - Recommendation to Use the Ethernet Control Word [draft-ietf-pals-ethernet-cw-07] (9 pages) - Extension to LDP-VPLS for Ethernet Broadcast and Multicast [draft-ietf-pals-ldp-vpls-broadcast-exten-01] (19 pages) - Multi-Chassis Passive Optical Network (MC-PON) Protection in MPLS [draft-ietf-pals-mc-pon-05] (16 pages) - Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection [draft-ietf-pals-mpls-tp-dual-homing-coordination-06] (17 pages) - Dual-Homing Protection for MPLS and the MPLS Transport Profile (MPLS-TP) Pseudowires [draft-ietf-pals-mpls-tp-dual-homing-protection-06] (11 pages) - Media Access Control (MAC) Address Withdrawal over Static Pseudowire [draft-ietf-pals-mpls-tp-mac-wd-03] (10 pages) - LDP Extensions for Proactive Operations, Administration and Maintenance Configuration of Dynamic MPLS Transport Profile PseudoWire [draft-ietf-pals-mpls-tp-oam-config-03] (30 pages) - LDP Extensions for Pseudowire Binding to Label Switched Path (LSP) Tunnels [draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-09] (16 pages) - Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires [draft-ietf-pals-ms-pw-protection-04] (9 pages) - Signaling Root-Initiated Point-to-Multipoint Pseudowire Using LDP [draft-ietf-pals-p2mp-pw-04] (20 pages) - Definition of P2MP PW TLV for Label Switched Path (LSP) Ping Mechanisms [draft-ietf-pals-p2mp-pw-lsp-ping-05] (10 pages) - Private Line Emulation over Packet Switched Networks [draft-ietf-pals-ple-06] (35 pages) - Pseudowire Redundancy on the Switching Provider Edge (S-PE) [draft-ietf-pals-redundancy-spe-03] (9 pages) - Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) [draft-ietf-pals-rfc4447bis-05] (35 pages) - Seamless Bidirectional Forwarding Detection (S-BFD) for Virtual Circuit Connectivity Verification (VCCV) [draft-ietf-pals-seamless-vccv-03] (11 pages) - MPLS Label Switched Path (LSP) Pseudowire (PW) Status Refresh Reduction for Static PWs [draft-ietf-pals-status-reduction-05] (20 pages) - Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator [draft-ietf-pals-vccv-for-gal-06] (9 pages) - Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS) [draft-ietf-pals-vpls-pim-snooping-06] (43 pages) - Pseudowire Congestion Considerations [draft-ietf-pwe3-congcons-02] (22 pages) - PW Endpoint Fast Failure Protection [draft-ietf-pwe3-endpoint-fast-protection-02] (29 pages) - Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP) [draft-ietf-pwe3-iccp-stp-05] (25 pages) - Label Distribution Protocol Extensions for Proactive Operations, Administration and Maintenance Configuration of Dynamic MPLS Transport Profile PseudoWire [draft-ietf-pwe3-mpls-tp-oam-config-01] (23 pages) - LDP extensions for Pseudowire Binding to LSP Tunnels [draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-03] (15 pages) - Pseudowire Redundancy on S-PE [draft-ietf-pwe3-redundancy-spe-03] (8 pages) - Pseudowire Setup and Maintenance using the Label Distribution Protocol [draft-ietf-pwe3-rfc4447bis-03] (32 pages) - A Unified Control Channel for Pseudowires [draft-ietf-pwe3-vccv-for-gal-02] (9 pages) - Definition of P2MP PW TLV for LSP-Ping Mechanisms [draft-jain-pwe3-p2mp-pw-lsp-ping-03] (8 pages) - Private Line Emulation over Packet Switched Networks [draft-schmutzer-pals-ple-04] (29 pages) Requests for Comments: RFC7708: Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator (9 pages) RFC7727: Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP) (25 pages) RFC7769: Media Access Control (MAC) Address Withdrawal over Static Pseudowire (10 pages) RFC7771: Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires (9 pages) RFC7795: Pseudowire Redundancy on the Switching Provider Edge (S-PE) (9 pages) RFC7796: Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) (26 pages) RFC7885: Seamless Bidirectional Forwarding Detection (S-BFD) for Virtual Circuit Connectivity Verification (VCCV) (11 pages) RFC7893: Pseudowire Congestion Considerations (27 pages) RFC7965: LDP Extensions for Pseudowire Binding to Label Switched Path (LSP) Tunnels (16 pages) RFC8024: Multi-Chassis Passive Optical Network (MC-PON) Protection in MPLS (16 pages) RFC8077: Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) (35 pages) RFC8104: Pseudowire (PW) Endpoint Fast Failure Protection (43 pages) RFC8184: Dual-Homing Protection for MPLS and the MPLS Transport Profile (MPLS-TP) Pseudowires (11 pages) RFC8185: Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection (17 pages) RFC8220: Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS) (43 pages) RFC8237: MPLS Label Switched Path (LSP) Pseudowire (PW) Status Refresh Reduction for Static PWs (20 pages) RFC8338: Signaling Root-Initiated Point-to-Multipoint Pseudowire Using LDP (20 pages) RFC8339: Definition of P2MP PW TLV for Label Switched Path (LSP) Ping Mechanisms (10 pages) RFC8469: Recommendation to Use the Ethernet Control Word (9 pages) Path Computation Element (pce) ------------------------------ Charter Last Modified: 2023-06-29 Current Status: Active Chairs: Dhruv Dhody Julien Meuric Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: John Scudder Secretary: Andrew Stone Mailing Lists: General Discussion: pce@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/pce Archive: https://mailarchive.ietf.org/arch/browse/pce/ Description of Working Group: The PCE Working Group is chartered to specify the required protocols to enable a Path Computation Element (PCE)-based architecture for the computation of paths for MPLS and GMPLS Point to Point and Point to Multi-point traffic-engineered LSPs, as well as new path setup types of Segment Routing (SR), BIER, and Detnet. In this architecture path computation does not necessarily occur on the head-end (ingress) node, but on some other path computation entity that may not be physically located on each head-end node. The TEAS Working Group is responsible for defining and extending architectures for Traffic Engineering (TE) and it is expected that the PCE and TEAS WGs will work closely together on elements of TE architectures that utilize PCE. The PCE WG works on the application of this model within a single domain or within a group of domains (where a domain is a layer, IGP area, or Autonomous System with limited visibility from the head-end LSR). At this time, applying this model to large groups of domains such as the Internet is not thought to be possible, and the PCE WG will not spend energy on that topic. The WG specifies the PCE communication Protocol (PCEP) and needed extensions for communication between Path Computation Clients (PCCs) and PCEs, and between cooperating PCEs. Security mechanisms such as authentication and confidentiality are included. The WG works on the mechanisms for inter-domain as well as multi-layer path computation and PCEP extensions for communication between several domains or network layers. The WG defines the required PCEP extensions for Wavelength Switched Optical Networks (WSON) and Flexible Grid while keeping consistency with the GMPLS protocols specified in the CCAMP and TEAS WGs. Work Items: - PCEP extensions to support MPLS and GMPLS Traffic Engineered LSP path computation models involving PCEs. This includes the case of computing the paths of intra- and inter-domain TE LSPs. Such path computation includes the generation of primary, protection, and recovery paths, as well as computations for (local/global) reoptimization and load balancing. Both intra- and inter-domain applications are covered. - In cooperation with the TEAS Working Group, development of PCE- based architectures for Traffic Engineering including PCE as a Central Controller (PCECC) and Centralized Control Dynamic Routing (CCDR). The PCEP extensions are developed in the PCE Working Group. - In cooperation with protocol-specific Working Groups (e.g., MPLS, CCAMP), development of LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models. - Specification of PCEP extensions for expressing path computation requests and responses in the various GMPLS-controlled networks, including WSON and Flexible Grid. - Specification of PCEP extensions for path computation in multi-layer and inter-domain networks. - Specification of the PCEP extensions used by a stateful PCE for recommending a new path for an existing or new LSP to the PCC/PCE. Further protocol extensions must cover the case where the receiving PCC/PCE chooses not to follow the recommendation. The PCEP extensions for state synchronization are also in scope. - Specification of the PCEP extensions for SR-MPLS and SRv6 paths as per the SR Policy architecture in cooperation with SPRING Working Group. - Specification of the PCEP extensions for new path setup types (such as BIER and DETNET) in cooperation with the respective Working Groups. Goals and Milestones: Jan 2024 - Submit PCEP YANG Model as a Proposed Standard Mar 2024 - Submit PCEP extensions for SR Policy as Proposed Standard Mar 2024 - Submit PCEP extensions for Multipath as Proposed Standard Dec 2024 - Submit Enhancements to Stateful PCE Mar 2025 - Evaluate WG progress, recharter or close Done - Submit PCEP Native-IP extensions as a Proposed Standard Internet-Drafts: - Path Computation Element Communication Protocol (PCEP) Extensions for remote-initiated GMPLS LSP Setup [draft-ali-pce-remote-initiated-gmpls-lsp-03] (9 pages) - PCEP extension to support Segment Routing Policy Candidate Paths [draft-barth-pce-segment-routing-policy-cp-06] (20 pages) - PCEP Extensions for Tree Engineering for Bit Index Explicit Replication (BIER-TE) [draft-chen-pce-bier-13] (17 pages) - Path Computation Element Communication Protocol (PCEP) Extensions to Enable IFIT [draft-chen-pce-pcep-ifit-06] (23 pages) - PCEP extensions for Distribution of Link-State and TE Information [draft-dhodylee-pce-pcep-ls-27] (39 pages) - Update to the IANA PCEP Registration Procedures [draft-dhody-pce-iana-update-03] (8 pages) - Experimental Codepoint Allocation for Path Computation Element communication Protocol (PCEP) [draft-dhody-pce-pcep-exp-codepoints-03] (6 pages) - PCE Communication Protocol (PCEP) Extensions for Using the PCE as a Central Controller (PCECC) for Segment Routing over IPv6 (SRv6) Segment Identifier (SID) Allocation and Distribution. [draft-dhody-pce-pcep-extension-pce-controller-srv6-10] (19 pages) - Updates for PCEPS [draft-dhody-pce-pceps-tls13-02] (6 pages) - PCEP Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with Stateful PCE [draft-dhody-pce-stateful-pce-auto-bandwidth-09] (25 pages) - Extension for Stateful PCE to allow Optional Processing of PCEP Objects [draft-dhody-pce-stateful-pce-optional-08] (11 pages) - Conveying Vendor-Specific Information in the Path Computation Element (PCE) Communication Protocol (PCEP) extensions for Stateful PCE. [draft-dhody-pce-stateful-pce-vendor-16] (12 pages) - PCEP Extension for Stateful Inter-Domain Tunnels [draft-dugeon-pce-stateful-interdomain-04] (34 pages) - Conveying Vendor-Specific Constraints in the Path Computation Element communication Protocol [draft-farrel-pce-rfc7150bis-01] (12 pages) - Updated Rules for Processing Stateful PCE Request Parameters Flags [draft-farrel-pce-stateful-flags-03] (6 pages) - Unanswered Questions in the Path Computation Element Architecture [draft-farrkingel-pce-questions-03] (25 pages) - PCEP extensions for p2mp sr policy [draft-hsd-pce-sr-p2mp-policy-03] (36 pages) - Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN) [draft-ietf-pce-applicability-actn-12] (22 pages) - A Path Computation Element (PCE)-Based Architecture [draft-ietf-pce-architecture-05] (40 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs) [draft-ietf-pce-association-bidir-14] (20 pages) - Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling [draft-ietf-pce-association-diversity-15] (21 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs) [draft-ietf-pce-association-group-10] (28 pages) - Path Computation Element Communication Protocol (PCEP) Extension for Associating Policies and Label Switched Paths (LSPs) [draft-ietf-pce-association-policy-16] (15 pages) - PCEP Extensions for BIER-TE [draft-ietf-pce-bier-te-00] (16 pages) - Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks. [draft-ietf-pce-binding-label-sid-16] (25 pages) - A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths [draft-ietf-pce-brpc-09] (18 pages) - Path Computation Element Communication Protocol (PCEP) extensions for Circuit Style Policies [draft-ietf-pce-circuit-style-pcep-extensions-06] (14 pages) - Path Computation Element (PCE) Communication Protocol Generic Requirements [draft-ietf-pce-comm-protocol-gen-reqs-07] (21 pages) - Path Computation Element Communication Protocol (PCEP) extension to advertise the PCE Controlled Identifier Space [draft-ietf-pce-controlled-id-space-00] (18 pages) - Definitions of Managed Objects for Path Computation Element Discovery [draft-ietf-pce-disc-mib-04] (24 pages) - IGP protocol extensions for Path Computation Element (PCE) Discovery [draft-ietf-pce-disco-proto-igp-02] (37 pages) - IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery [draft-ietf-pce-disco-proto-isis-08] (17 pages) - OSPF Protocol Extensions for Path Computation Element (PCE) Discovery [draft-ietf-pce-disco-proto-ospf-08] (20 pages) - Requirements for Path Computation Element (PCE) Discovery [draft-ietf-pce-discovery-reqs-05] (19 pages) - Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol [draft-ietf-pce-dste-02] (9 pages) - Extensions to the Path Computation Element Communication Protocol for Enhanced Errors and Notifications [draft-ietf-pce-enhanced-errors-13] (23 pages) - Path Computation Element Communication Protocol (PCEP) Extension for SR-MPLS Entropy Label Positions [draft-ietf-pce-entropy-label-position-01] (10 pages) - PCEP Extension for Flexible Grid Networks [draft-ietf-pce-flexible-grid-10] (19 pages) - Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization [draft-ietf-pce-global-concurrent-optimization-10] (26 pages) - Requirements for GMPLS Applications of PCE [draft-ietf-pce-gmpls-aps-req-09] (12 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for GMPLS [draft-ietf-pce-gmpls-pcep-extensions-16] (38 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture [draft-ietf-pce-hierarchy-extensions-11] (27 pages) - The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS [draft-ietf-pce-hierarchy-fwk-05] (33 pages) - Update to the IANA PCEP Registration Procedures and Allowing Experimental Error Codes [draft-ietf-pce-iana-update-01] (12 pages) - Applicability of the Path Computation Element to Inter-area and Inter-AS MPLS and GMPLS Traffic Engineering [draft-ietf-pce-inter-area-as-applicability-08] (24 pages) - Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) [draft-ietf-pce-interas-pcecp-reqs-06] (14 pages) - Extensions to the Path Computation Element Communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering [draft-ietf-pce-inter-layer-ext-12] (22 pages) - Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering [draft-ietf-pce-inter-layer-frwk-10] (34 pages) - PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering [draft-ietf-pce-inter-layer-req-15] (12 pages) - Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP) [draft-ietf-pce-iro-update-07] (5 pages) - Local Protection Enforcement in the Path Computation Element Communication Protocol (PCEP) [draft-ietf-pce-local-protection-enforcement-11] (9 pages) - Ability for a Stateful Path Computation Element (PCE) to Request and Obtain Control of a Label Switched Path (LSP) [draft-ietf-pce-lsp-control-request-11] (11 pages) - Label Switched Path (LSP) Object Flag Extension for Stateful PCE [draft-ietf-pce-lsp-extended-flags-09] (9 pages) - Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages [draft-ietf-pce-lsp-setup-type-10] (12 pages) - Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts [draft-ietf-pce-manageability-requirements-11] (13 pages) - A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture [draft-ietf-pce-monitoring-09] (26 pages) - PCEP Extensions for Signaling Multipath Information [draft-ietf-pce-multipath-11] (24 pages) - Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP) [draft-ietf-pce-of-06] (23 pages) - Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE) [draft-ietf-pce-p2mp-app-02] (15 pages) - Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE [draft-ietf-pce-p2mp-req-05] (11 pages) - Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism [draft-ietf-pce-path-key-06] (19 pages) - Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering [draft-ietf-pce-pcecp-interarea-reqs-05] (12 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model [draft-ietf-pce-pce-initiated-lsp-11] (20 pages) - Path Computation Element (PCE) Communication Protocol (PCEP) [draft-ietf-pce-pcep-19] (87 pages) - Path Computation Element Protocol(PCEP) Extension for Color [draft-ietf-pce-pcep-color-04] (10 pages) - Domain Subobjects for the Path Computation Element Communication Protocol (PCEP) [draft-ietf-pce-pcep-domain-sequence-12] (35 pages) - Experimental Codepoint Allocation for the Path Computation Element Communication Protocol (PCEP) [draft-ietf-pce-pcep-exp-codepoints-05] (7 pages) - Path Computation Element Communication Protocol (PCEP) Procedures and Extensions for Using the PCE as a Central Controller (PCECC) of LSPs [draft-ietf-pce-pcep-extension-for-pce-controller-14] (33 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for Native IP Networks [draft-ietf-pce-pcep-extension-native-ip-40] (38 pages) - PCE Communication Protocol (PCEP) Extensions for Using PCE as a Central Controller (PCECC) for Segment Routing (SR) MPLS Segment Identifier (SID) Allocation and Distribution. [draft-ietf-pce-pcep-extension-pce-controller-sr-09] (34 pages) - PCE Communication Protocol (PCEP) Extensions for Using the PCE as a Central Controller (PCECC) for Segment Routing over IPv6 (SRv6) Segment Identifier (SID) Allocation and Distribution. [draft-ietf-pce-pcep-extension-pce-controller-srv6-03] (20 pages) - Path Computation Element Communication Protocol (PCEP) Extension for Flow Specification [draft-ietf-pce-pcep-flowspec-13] (29 pages) - Path Computation Element Communication Protocol (PCEP) Extensions to Enable IFIT [draft-ietf-pce-pcep-ifit-05] (23 pages) - PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths [draft-ietf-pce-pcep-inter-domain-p2mp-procedures-08] (25 pages) - PCEP Extension for Layer 2 (L2) Flow Specification [draft-ietf-pce-pcep-l2-flowspec-06] (14 pages) - PCEP extensions for Distribution of Link-State and TE Information [draft-ietf-pce-pcep-ls-01] (40 pages) - Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module [draft-ietf-pce-pcep-mib-11] (65 pages) - Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths [draft-ietf-pce-pcep-p2mp-extensions-11] (33 pages) - Support for Path MTU (PMTU) in the Path Computation Element (PCE) Communication Protocol (PCEP) [draft-ietf-pce-pcep-pmtu-06] (11 pages) - PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP) [draft-ietf-pce-pceps-18] (26 pages) - Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs) [draft-ietf-pce-pcep-service-aware-13] (31 pages) - A YANG Data Model for Segment Routing (SR) Policy and SR in IPv6 (SRv6) support in Path Computation Element Communications Protocol (PCEP) [draft-ietf-pce-pcep-srv6-yang-05] (23 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE Usage in GMPLS-Controlled Networks [draft-ietf-pce-pcep-stateful-pce-gmpls-23] (22 pages) - Updates for PCEPS: TLS Connection Establishment Restrictions [draft-ietf-pce-pceps-tls13-04] (6 pages) - Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations [draft-ietf-pce-pcep-svec-list-05] (18 pages) - Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions [draft-ietf-pce-pcep-xro-06] (16 pages) - A YANG Data Model for Path Computation Element Communications Protocol (PCEP) [draft-ietf-pce-pcep-yang-25] (132 pages) - Policy-Enabled Path Computation Framework [draft-ietf-pce-policy-enabled-path-comp-04] (36 pages) - Unanswered Questions in the Path Computation Element Architecture [draft-ietf-pce-questions-08] (29 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for remote-initiated GMPLS LSP Setup [draft-ietf-pce-remote-initiated-gmpls-lsp-06] (10 pages) - Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths [draft-ietf-pce-rfc6006bis-04] (43 pages) - Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol [draft-ietf-pce-rfc7150bis-01] (14 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing [draft-ietf-pce-segment-routing-16] (29 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for IPv6 Segment Routing [draft-ietf-pce-segment-routing-ipv6-25] (28 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths [draft-ietf-pce-segment-routing-policy-cp-17] (27 pages) - Carrying SR-Algorithm Information in PCE-based Networks. [draft-ietf-pce-sid-algo-13] (22 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) Paths [draft-ietf-pce-sr-bidir-path-14] (20 pages) - PCEP extensions for p2mp sr policy [draft-ietf-pce-sr-p2mp-policy-09] (47 pages) - Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR) [draft-ietf-pce-sr-path-segment-11] (26 pages) - Updated Rules for Processing Stateful PCE Request Parameters Flags [draft-ietf-pce-stateful-flags-01] (6 pages) - Hierarchical Stateful Path Computation Element (PCE) [draft-ietf-pce-stateful-hpce-15] (21 pages) - PCEP Extension for Stateful Inter-Domain Tunnels [draft-ietf-pce-stateful-interdomain-05] (47 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE [draft-ietf-pce-stateful-path-protection-11] (15 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE [draft-ietf-pce-stateful-pce-21] (57 pages) - Applicability of a Stateful Path Computation Element (PCE) [draft-ietf-pce-stateful-pce-app-08] (24 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Stateful PCE [draft-ietf-pce-stateful-pce-auto-bandwidth-12] (32 pages) - Cooperative Stateful Path Computation Element (PCE) for Inter-Domain Inter-Vendor PCE-initiated LSP Setup [draft-ietf-pce-stateful-pce-inter-domain-lsp-00] (12 pages) - PCE Communication Protocol (PCEP) Extensions for Label Switched Path (LSP) Scheduling with Stateful PCE [draft-ietf-pce-stateful-pce-lsp-scheduling-27] (23 pages) - Extension for Stateful PCE to allow Optional Processing of PCE Communication Protocol (PCEP) Objects [draft-ietf-pce-stateful-pce-optional-09] (12 pages) - Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs) [draft-ietf-pce-stateful-pce-p2mp-13] (33 pages) - Conveying Vendor-Specific Information in the Path Computation Element (PCE) Communication Protocol (PCEP) extensions for Stateful PCE. [draft-ietf-pce-stateful-pce-vendor-07] (12 pages) - Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE [draft-ietf-pce-stateful-sync-optimizations-10] (26 pages) - Inter Stateful Path Computation Element (PCE) Communication Procedures. [draft-ietf-pce-state-sync-07] (35 pages) - Definitions of Textual Conventions for Path Computation Element [draft-ietf-pce-tc-mib-05] (6 pages) - Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol [draft-ietf-pce-vendor-constraints-11] (12 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths and Virtual Networks [draft-ietf-pce-vn-association-11] (12 pages) - PCC-PCE Communication Requirements for VPNs [draft-ietf-pce-vpn-req-02] (16 pages) - Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment [draft-ietf-pce-wson-routing-wavelength-15] (12 pages) - The Path Computation Element Communication Protocol (PCEP) Extension for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment (RWA) [draft-ietf-pce-wson-rwa-ext-17] (26 pages) - PCEP Extensions for Signaling Multipath Information [draft-koldychev-pce-multipath-05] (19 pages) - Extensions to the Path Computation Element Protocol (PCEP) for residual path bandwidth support [draft-lazzeri-pce-residual-bw-01] (16 pages) - Path Computation Element communication Protocol (PCEP) extensions for Establishing Relationships between sets of LSPs and Virtual Networks [draft-leedhody-pce-vn-association-08] (14 pages) - PCEP Extension for Flexible Grid Networks [draft-lee-pce-flexible-grid-03] (20 pages) - Path Computation Element Communication Protocol (PCEP) extension to advertise the PCE Controlled Identifier Space [draft-li-pce-controlled-id-space-16] (18 pages) - PCEP Extension for L2 Flow Specification [draft-li-pce-pcep-l2-flowspec-00] (13 pages) - Support for Path MTU (PMTU) in the Path Computation Element (PCE) communication Protocol (PCEP). [draft-li-pce-pcep-pmtu-05] (11 pages) - PCEP Extensions for Associated Bidirectional Segment Routing (SR) Paths [draft-li-pce-sr-bidir-path-07] (16 pages) - Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR) [draft-li-pce-sr-path-segment-08] (26 pages) - Inter Stateful Path Computation Element (PCE) Communication Procedures. [draft-litkowski-pce-state-sync-10] (32 pages) - Secure Transport for PCEP [draft-lopez-pce-pceps-02] (12 pages) - Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE [draft-minei-pce-stateful-sync-optimizations-02] (19 pages) - PCEP Extensions for Segment Routing leveraging the IPv6 data plane [draft-negi-pce-segment-routing-ipv6-04] (20 pages) - Path Computation Element (PCE) Protocol Extensions for Stateful PCE usage for Point-to-Multipoint Traffic Engineering Label Switched Paths [draft-palle-pce-stateful-pce-p2mp-09] (32 pages) - Path Computation Element Communication Protocol (PCEP) Extension for SR-MPLS Entropy Label Positions [draft-peng-pce-entropy-label-position-11] (10 pages) - Path Computation Element Protocol(PCEP) Extension for Color [draft-rajagopalan-pce-pcep-color-03] (8 pages) - PCEP extensions for Circuit Style Policies [draft-sidor-pce-circuit-style-pcep-extensions-06] (11 pages) - Carrying Binding Label/Segment-ID in PCE-based Networks. [draft-sivabalan-pce-binding-label-sid-07] (16 pages) - Local Protection Enforcement in PCEP [draft-stone-pce-local-protection-enforcement-02] (11 pages) - Carrying SID Algorithm information in PCE-based Networks. [draft-tokar-pce-sid-algo-05] (12 pages) - LSP Object Flag Extension of Stateful PCE [draft-xiong-pce-lsp-flag-03] (6 pages) - PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) for Segment Routing (SR) MPLS Segment Identifier (SID) Allocation and Distribution. [draft-zhao-pce-pcep-extension-pce-controller-sr-09] (32 pages) Requests for Comments: RFC4655: A Path Computation Element (PCE)-Based Architecture (40 pages) RFC4657: Path Computation Element (PCE) Communication Protocol Generic Requirements (21 pages) RFC4674: Requirements for Path Computation Element (PCE) Discovery (19 pages) RFC4927: Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering (12 pages) RFC5088: OSPF Protocol Extensions for Path Computation Element (PCE) Discovery (20 pages) * Updates RFC9353 RFC5089: IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery (17 pages) * Updates RFC9353 RFC5376: Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) (14 pages) RFC5394: Policy-Enabled Path Computation Framework (36 pages) RFC5440: Path Computation Element (PCE) Communication Protocol (PCEP) (87 pages) * Updates RFC7896 * Updates RFC8253 * Updates RFC8356 * Updates RFC9488 RFC5441: A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths (18 pages) RFC5455: Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol (9 pages) RFC5520: Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism (19 pages) RFC5521: Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions (16 pages) RFC5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP) (23 pages) RFC5557: Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization (26 pages) RFC5623: Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering (34 pages) RFC5671: Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE) (15 pages) RFC5862: Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE (11 pages) RFC5886: A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture (26 pages) RFC6006: Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths (33 pages) * Obsoletes RFC8306 RFC6007: Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations (18 pages) RFC6123: Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts (13 pages) RFC6457: PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering (12 pages) RFC6805: The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS (33 pages) RFC7025: Requirements for GMPLS Applications of PCE (12 pages) RFC7150: Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol (12 pages) * Obsoletes RFC7470 RFC7334: PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths (25 pages) RFC7399: Unanswered Questions in the Path Computation Element Architecture (29 pages) RFC7420: Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module (65 pages) RFC7449: Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment (12 pages) RFC7470: Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol (14 pages) RFC7896: Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP) (5 pages) RFC7897: Domain Subobjects for the Path Computation Element Communication Protocol (PCEP) (35 pages) RFC8051: Applicability of a Stateful Path Computation Element (PCE) (24 pages) RFC8231: Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE (57 pages) * Updates RFC8786 * Updates RFC9353 RFC8232: Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE (26 pages) RFC8233: Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs) (31 pages) RFC8253: PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP) (26 pages) RFC8281: Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model (20 pages) RFC8282: Extensions to the Path Computation Element Communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering (22 pages) RFC8306: Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths (43 pages) * Updates RFC9353 RFC8356: Experimental Codepoint Allocation for the Path Computation Element Communication Protocol (PCEP) (7 pages) RFC8408: Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages (12 pages) * Updates RFC8664 RFC8623: Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs) (33 pages) RFC8637: Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN) (22 pages) RFC8664: Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (29 pages) RFC8685: Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture (27 pages) RFC8694: Applicability of the Path Computation Element to Inter-area and Inter-AS MPLS and GMPLS Traffic Engineering (24 pages) RFC8697: Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs) (28 pages) RFC8733: Path Computation Element Communication Protocol (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Stateful PCE (32 pages) RFC8741: Ability for a Stateful Path Computation Element (PCE) to Request and Obtain Control of a Label Switched Path (LSP) (11 pages) RFC8745: Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE (15 pages) RFC8751: Hierarchical Stateful Path Computation Element (PCE) (21 pages) RFC8779: Path Computation Element Communication Protocol (PCEP) Extensions for GMPLS (38 pages) RFC8780: The Path Computation Element Communication Protocol (PCEP) Extension for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment (RWA) (26 pages) RFC8786: Updated Rules for Processing Stateful PCE Request Parameters Flags (6 pages) RFC8800: Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling (21 pages) RFC8934: PCE Communication Protocol (PCEP) Extensions for Label Switched Path (LSP) Scheduling with Stateful PCE (23 pages) RFC9005: Path Computation Element Communication Protocol (PCEP) Extension for Associating Policies and Label Switched Paths (LSPs) (15 pages) RFC9050: Path Computation Element Communication Protocol (PCEP) Procedures and Extensions for Using the PCE as a Central Controller (PCECC) of LSPs (33 pages) RFC9059: Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs) (20 pages) RFC9168: Path Computation Element Communication Protocol (PCEP) Extension for Flow Specification (29 pages) RFC9357: Label Switched Path (LSP) Object Flag Extension for Stateful PCE (9 pages) RFC9358: Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths and Virtual Networks (12 pages) RFC9488: Local Protection Enforcement in the Path Computation Element Communication Protocol (PCEP) (9 pages) RFC9504: Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE Usage in GMPLS-Controlled Networks (22 pages) RFC9603: Path Computation Element Communication Protocol (PCEP) Extensions for IPv6 Segment Routing (23 pages) RFC9604: Carrying Binding Label/SID in PCE-Based Networks (19 pages) Protocols for IP Multicast (pim) -------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Mike McBride Stig Venaas Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Gunter Van de Velde Tech Advisor: Brian Haberman Mailing Lists: General Discussion: pim@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/pim/ Archive: https://mailarchive.ietf.org/arch/browse/pim/ Description of Working Group: The Protocols for IP Multicast (PIM) working group, is chartered to work on multiple IP multicast protocols. The Working Group is responsible for the maintenance of PIM, IGMP, and MLD. The Working Group will work on the following specific items: 1) Management: YANG models for PIM, IGMP, and MLD will be developed, for both configuration and operational states. If updates to existing MIB modules are necessary, the WG may work on those. 2) Improve PIM authentication. 3) Improve and Extend PIM Join Attributes to support different types of multicast applications. 4) Optimization approaches for IGMP and MLD to adapt to link conditions in wireless and mobile networks and be more robust to packet loss. Additional work items may be added with a recharter. The WG should discuss and develop new ideas related to multicast protocols and distribution of multicast related information. The WG is expected to use its extensive multicast knowledge to actively review and participate in WG Last Calls with multicast work that occurs in other WGs, such as MBONED, LISP, MPLS, BESS, ROLL, and BIER. The WG should investigate any extensions needed to support other work and, if additional work is required, the WG may be rechartered to accomplish the specific extensions. Goals and Milestones: Nov 2015 - mld yang model submitted to iesg Nov 2015 - igmp yang model submitted to iesg Nov 2015 - Resubmit explicit-rpf-vector draft to IESG Nov 2015 - Submit PIM Join Attributes for LISP Environments to IESG Apr 2016 - submit solutions for IGMP and MLD to adapt to wireless link conditions Apr 2016 - pim sm yang model submitted to iesg Jul 2016 - pim ssm yang model submitted to iesg Jul 2016 - Adopt a draft which provides improvements to pim authentication Internet-Drafts: - IANA Considerations for Internet Group Management Protocols [draft-ietf-pim-3228bis-07] (6 pages) - Internet Group Management Protocol, Version 3 [draft-ietf-pim-3376bis-12] (57 pages) - Multicast Listener Discovery Version 2 (MLDv2) for IPv6 [draft-ietf-pim-3810bis-12] (68 pages) - Anycast-RP Using Protocol Independent Multicast (PIM) [draft-ietf-pim-anycast-rp-07] (12 pages) - PIM Assert Message Packing [draft-ietf-pim-assert-packing-12] (20 pages) - PIM Backup Designated Router Procedure [draft-ietf-pim-bdr-01] (7 pages) - Fast Failover in Protocol Independent Multicast - Sparse Mode (PIM-SM) Using Bidirectional Forwarding Detection (BFD) for Multipoint Networks [draft-ietf-pim-bfd-p2mp-use-case-10] (7 pages) - Bidirectional Protocol Independent Multicast (BIDIR-PIM) [draft-ietf-pim-bidir-09] (43 pages) - Protocol Independent Multicast (PIM) Bootstrap Router MIB [draft-ietf-pim-bsr-mib-06] (23 pages) - Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) [draft-ietf-pim-dm-new-v2-05] (61 pages) - Protocol Independent Multicast - Sparse Mode (PIM-SM) Designated Router (DR) Improvement [draft-ietf-pim-dr-improvement-14] (13 pages) - PIM Designated Router Load Balancing [draft-ietf-pim-drlb-15] (18 pages) - Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect [draft-ietf-pim-ecmp-05] (12 pages) - Yang Data Model for EVPN multicast [draft-ietf-pim-evpn-multicast-yang-02] (12 pages) - Explicit Reverse Path Forwarding (RPF) Vector [draft-ietf-pim-explicit-rpf-vector-09] (9 pages) - IGMP/MLD-Based Explicit Membership Tracking Function for Multicast Routers [draft-ietf-pim-explicit-tracking-13] (11 pages) - Group Address Allocation Protocol (GAAP) [draft-ietf-pim-gaap-01] (16 pages) - PIM Group-to-Rendezvous-Point Mapping [draft-ietf-pim-group-rp-mapping-10] (11 pages) - PIM Neighbor Hello GenId Option [draft-ietf-pim-hello-genid-01] (3 pages) - An Interface Identifier (ID) Hello Option for PIM [draft-ietf-pim-hello-intid-01] (6 pages) - Hierarchical Join/Prune Attributes [draft-ietf-pim-hierarchicaljoinattr-08] (8 pages) - Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Message Extension [draft-ietf-pim-igmp-mld-extension-08] (12 pages) - A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxy Devices [draft-ietf-pim-igmp-mld-proxy-yang-10] (20 pages) - A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping [draft-ietf-pim-igmp-mld-snooping-yang-20] (37 pages) - IGMP and MLD Snooping Yang Module Extension for L2VPN [draft-ietf-pim-igmp-mld-snooping-yang-l2vpn-ext-04] (21 pages) - IGMP/MLD Optimizations in Wireless and Mobile Networks [draft-ietf-pim-igmp-mld-wireless-mobile-00] (13 pages) - A YANG Data Model for the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) [draft-ietf-pim-igmp-mld-yang-15] (45 pages) - Use of PIM Address List Hello across address families [draft-ietf-pim-ipv4-prefix-over-ipv6-nh-02] (5 pages) - Protocol Independent Multicast Routing in the Internet Protocol Version 6 (IPv6) [draft-ietf-pim-ipv6-04] (5 pages) - Zero-Configuration Assignment of IPv6 Multicast Addresses [draft-ietf-pim-ipv6-zeroconf-assignment-02] (7 pages) - The Protocol Independent Multicast (PIM) Join Attribute Format [draft-ietf-pim-join-attributes-06] (10 pages) - PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments [draft-ietf-pim-join-attributes-for-lisp-06] (9 pages) - PIM Join/Prune Attributes for LISP Environments using Underlay Multicast [draft-ietf-pim-jp-extensions-lisp-06] (6 pages) - Host Threats to Protocol Independent Multicast (PIM) [draft-ietf-pim-lasthop-threats-04] (12 pages) - PIM Light [draft-ietf-pim-light-07] (9 pages) - Protocol Independent Multicast MIB [draft-ietf-pim-mib-v2-10] (90 pages) - Multicast-only Fast Reroute Based on Topology Independent Loop-free Alternate Fast Reroute [draft-ietf-pim-mofrr-tilfa-05] (15 pages) - A YANG Data Model for the Multicast Source Discovery Protocol (MSDP) [draft-ietf-pim-msdp-yang-18] (37 pages) - PIM Multi-Topology ID (MT-ID) Join Attribute [draft-ietf-pim-mtid-10] (13 pages) - Multicast Lessons Learned from Decades of Deployment Experience [draft-ietf-pim-multicast-lessons-learned-04] (20 pages) - Multipath Support for IGMP/MLD Proxy [draft-ietf-pim-multipath-igmpmldproxy-00] (15 pages) - Requirements for the extension of the IGMP/MLD proxy functionality to support multiple upstream interfaces [draft-ietf-pim-multiple-upstreams-reqs-08] (14 pages) - PIM Null-Register Packing [draft-ietf-pim-null-register-packing-16] (9 pages) - P2MP Policy Ping [draft-ietf-pim-p2mp-policy-ping-08] (9 pages) - PIM Flooding Mechanism and Source Discovery Enhancements [draft-ietf-pim-pfm-forwarding-enhancements-00] (9 pages) - Population Count Extensions to Protocol Independent Multicast (PIM) [draft-ietf-pim-pop-count-07] (15 pages) - A Reliable Transport Mechanism for PIM [draft-ietf-pim-port-09] (29 pages) - Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis [draft-ietf-pim-proposed-req-02] (8 pages) - Format for using PIM proxies [draft-ietf-pim-proxy-00] (7 pages) - State Refresh in PIM-DM [draft-ietf-pim-refresh-02] (10 pages) - A Registry for PIM Message Types [draft-ietf-pim-registry-04] (4 pages) - PIM Message Type Space Extension and Reserved Bits [draft-ietf-pim-reserved-bits-04] (8 pages) - Host Extensions for "Any Source" IP Multicasting (ASM) [draft-ietf-pim-rfc1112bis-02] (24 pages) - Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) [draft-ietf-pim-rfc4601bis-06] (137 pages) - Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments [draft-ietf-pim-rfc4601-update-survey-report-03] (12 pages) - PIM Message Type Space Extension and Reserved Bits [draft-ietf-pim-rfc8736bis-04] (7 pages) - The Reverse Path Forwarding (RPF) Vector TLV [draft-ietf-pim-rpf-vector-08] (8 pages) - Simple Key Management Protocol for PIM [draft-ietf-pim-simplekmp-02] (8 pages) - Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM) [draft-ietf-pim-sm-bsr-12] (42 pages) - Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages [draft-ietf-pim-sm-linklocal-10] (21 pages) - Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) [draft-ietf-pim-sm-v2-new-12] (150 pages) - PIM Flooding Mechanism (PFM) and Source Discovery (SD) [draft-ietf-pim-source-discovery-bsr-12] (18 pages) - Segment Routing Point-to-Multipoint Policy [draft-ietf-pim-sr-p2mp-policy-09] (22 pages) - Updates to Dynamic IPv6 Multicast Address Group IDs [draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-02] (5 pages) - Authenticating PIM version 2 messages [draft-ietf-pim-v2-auth-01] (4 pages) - Protocol Independent Multicast Version 2 Dense Mode Specification [draft-ietf-pim-v2-dm-03] (18 pages) - Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification [draft-ietf-pim-v2-sm-01] (65 pages) - YANG Data Model for Protocol Independent Multicast (PIM) [draft-ietf-pim-yang-17] (92 pages) - Zeroconf Multicast Address Allocation Problem Statement and Requirements [draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-02] (7 pages) Requests for Comments: RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) (61 pages) * Updates RFC8736 * Updates RFC9436 RFC4601: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) (150 pages) * Updates RFC5059 * Updates RFC5796 * Updates RFC6226 * Obsoletes RFC7761 RFC4602: Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis (8 pages) RFC4610: Anycast-RP Using Protocol Independent Multicast (PIM) (12 pages) RFC5015: Bidirectional Protocol Independent Multicast (BIDIR-PIM) (43 pages) * Updates RFC8736 * Updates RFC9436 RFC5059: Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM) (42 pages) * Updates RFC8736 * Updates RFC9436 RFC5060: Protocol Independent Multicast MIB (90 pages) RFC5240: Protocol Independent Multicast (PIM) Bootstrap Router MIB (23 pages) RFC5294: Host Threats to Protocol Independent Multicast (PIM) (12 pages) RFC5384: The Protocol Independent Multicast (PIM) Join Attribute Format (10 pages) * Updates RFC7887 RFC5496: The Reverse Path Forwarding (RPF) Vector TLV (8 pages) RFC5796: Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages (21 pages) RFC6166: A Registry for PIM Message Types (4 pages) * Obsoletes RFC8736 RFC6226: PIM Group-to-Rendezvous-Point Mapping (11 pages) RFC6395: An Interface Identifier (ID) Hello Option for PIM (6 pages) RFC6420: PIM Multi-Topology ID (MT-ID) Join Attribute (13 pages) RFC6559: A Reliable Transport Mechanism for PIM (29 pages) RFC6754: Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect (12 pages) * Updates RFC8736 * Updates RFC9436 RFC6807: Population Count Extensions to Protocol Independent Multicast (PIM) (15 pages) RFC7063: Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments (12 pages) RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) (137 pages) * Updates RFC8736 * Updates RFC9436 RFC7887: Hierarchical Join/Prune Attributes (8 pages) RFC7891: Explicit Reverse Path Forwarding (RPF) Vector (9 pages) RFC8059: PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments (9 pages) RFC8364: PIM Flooding Mechanism (PFM) and Source Discovery (SD) (18 pages) * Updates RFC8736 * Updates RFC9436 RFC8652: A YANG Data Model for the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) (45 pages) RFC8736: PIM Message Type Space Extension and Reserved Bits (8 pages) * Obsoletes RFC9436 RFC8775: PIM Designated Router Load Balancing (18 pages) RFC8916: A YANG Data Model for the Multicast Source Discovery Protocol (MSDP) (37 pages) RFC9128: YANG Data Model for Protocol Independent Multicast (PIM) (92 pages) RFC9166: A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping (37 pages) RFC9186: Fast Failover in Protocol Independent Multicast - Sparse Mode (PIM-SM) Using Bidirectional Forwarding Detection (BFD) for Multipoint Networks (7 pages) RFC9279: Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Message Extension (12 pages) RFC9398: A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxy Devices (20 pages) RFC9436: PIM Message Type Space Extension and Reserved Bits (7 pages) RFC9465: PIM Null-Register Packing (9 pages) RFC9466: PIM Assert Message Packing (20 pages) Routing In Fat Trees (rift) --------------------------- Charter Last Modified: 2023-04-21 Current Status: Active Chairs: Jeff Tantsura Zhaohui (Jeffrey) Zhang Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Jim Guichard Mailing Lists: General Discussion: rift@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/rift Archive: https://mailarchive.ietf.org/arch/browse/rift Description of Working Group: Data Centers have been steadily growing to commonly host tens of thousands of end points, or more, in a single network. Because of their topologies (traditional and emerging), traffic patterns, need for fast restoration, and for low human intervention, data center networks have a unique set of requirements that is resulting in the design of routing solutions specific to them. Clos and Fat-Tree topologies have gained popularity in data center networks as a result of a trend towards centralized data center network architectures that may deliver computation and storage services. The Routing in Fat Trees (RIFT) protocol addresses the demands of routing in Clos and Fat-Tree networks via a mixture of both link-state and distance-vector techniques colloquially described as 'link-state towards the spine and distance vector towards the leafs'. RIFT uses this hybrid approach to focus on networks with regular topologies with a high degree of connectivity, a defined directionality, and large scale. The RIFT Working Group will work on a standards track specification of a specialized, dynamic routing protocol for Clos and fat-tree network topologies. The protocol will: - deal with automatic construction of fat-tree topologies based on detection of links, - minimize the amount of routing state held at each topology level, - automatically prune topology distribution exchanges to a sufficient subset of links, - support automatic disaggregation of prefixes on link and node failures to prevent black-holing and suboptimal routing, - allow traffic steering and re-routing policies, - and provide mechanisms to synchronize a limited key-value data-store that can be used after protocol convergence. It is important that nodes participating in the protocol should need only very light configuration and should be able to join a network as leaf nodes simply by connecting to the network using default configuration. The protocol must support IPv6 and should also support IPv4. The Working Group may establish additional requirements to constrain and inform their work. The RIFT Working Group is chartered for the following list of items: - A Standards Track specification that will include: - an Implementation Status section as described in RFC 7942 - an Operational Considerations section to explain how the protocol is configured, deployed, and diagnosed, security and privacy mitigations for the protocol as identified in the threat analysis document. (q.v.) - A YANG module focused on configuration and monitoring of protocol instances - An Applicability Statement that describes how to deploy and configure the protocol in networks with different topologies - A Security Threat Analysis document that describes the attack vectors, which shall be sent for publication at the same time as the protocol specification Goals and Milestones: Apr 2020 - Submit protocol specification to IESG for publication Aug 2020 - Submit YANG module to IESG for publication Aug 2020 - Submit Applicability Statement to IESG for publication Done - Adopt a protocol specification document Internet-Drafts: - RIFT Applicability and Operational Considerations [draft-ietf-rift-applicability-17] (37 pages) - RIFT Auto-EVPN [draft-ietf-rift-auto-evpn-06] (90 pages) - RIFT Key/Value Structure and Registry [draft-ietf-rift-kv-registry-07] (12 pages) - RIFT Key/Value TIE Structure and Processing [draft-ietf-rift-kv-tie-structure-and-processing-01] (13 pages) - RIFT: Routing in Fat Trees [draft-ietf-rift-rift-24] (190 pages) - SRIFT: Segment Routing in Fat Trees [draft-ietf-rift-sr-01] (8 pages) - YANG Data Model for Routing in Fat Trees (RIFT) [draft-ietf-rift-yang-17] (61 pages) - RIFT: Routing in Fat Trees [draft-przygienda-rift-05] (67 pages) - RIFT Applicability [draft-wei-rift-applicability-02] (23 pages) - RIFT YANG Model [draft-zhang-rift-yang-02] (22 pages) No Requests for Comments Routing Over Low power and Lossy networks (roll) ------------------------------------------------ Charter Last Modified: 2024-03-27 Current Status: Active Chairs: Dominique Barthel Ines Robles Remous-Aris Koutsiamanis Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: John Scudder Secretary: Michael Richardson Mailing Lists: General Discussion: roll@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/roll Archive: https://mailarchive.ietf.org/arch/browse/roll/ Description of Working Group: Low power and Lossy Networks (LLNs ) are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. LLNs are transitioning to an end-to-end IP-based solution to avoid the problem of non-interoperable networks interconnected by protocol translation gateways and proxies. RFC7102 discusses ROLL specific aspects of LLNs, and RFC7228 provides additional terminology for constrained devices. RFC 5548, 5673, 5826, and 5876 describe the requirements for LLNs from several application perspectives. The Working Group has focused on routing solutions for the areas: connected home, building, and urban sensor networks. It has developed a Framework that takes into consideration various aspects including high reliability in the presence of time varying loss characteristics and connectivity while permitting low-power operation with very modest memory and CPU pressure in networks potentially comprising a very large number (several thousands) of nodes. The Working Group continues to focus on routing issues for LLN and to maintain, improve and streamline the protocols already developed, including RPL and MPL. The focus is on IPv6 work only. The Working Group will pay particular attention to routing security and manageability (e.g., self-configuration) issues. The working group will consider the transport characteristics that routing protocol messages will experience. ROLL will coordinate closely with the working groups in other areas that focus on constrained networks and/or constrained nodes, such as 6lo, 6tisch, ipwave, lwig and CoRE. Other working groups such as pim, bier and manet will be consulted as needed. The Working group will align with the 6man WG when needed. Work Items are: - Guidance in using RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation. - Additional protocol elements to reduce packet size and the amount of required routing states - Automatic selection of MPL forwarders to reduce message replication. - Data models for RPL and MPL management. - Multicast enhancements algorithms. Goals and Milestones: Jan 2024 - Initial submission of Controlling Secure Network Enrollment in RPL networks draft to the IESG Feb 2024 - Initial submission of Mode of Operation extension for RPL to the IESG Mar 2024 - Initial submission of Fast Border Router Crash Detection in RPL to the IESG Jun 2024 - Initial submission of Capabilities for RPL to the IESG Nov 2024 - Initial submission of a proposal to augment DIS flags and options to the IESG Dec 2024 - Recharter WG or close Done - Initial submission of a solution to the problems due to the use of No-Path DAO Messages to the IESG Done - Initial submission of routing for RPL Leaves draft to the IESG Done - Initial submission of a reactive P2P route discovery mechanism based on AODV-RPL protocol to the IESG Done - Initial Submission of a proposal with uses cases for RPI, RH3 and IPv6-in-IPv6 encapsulation to the IESG Done - Initial submission of Common Ancestor Objective Functions and Parent Set DAG Metric Container Extension to the IESG Done - Initial submission to the IESG of mechanism to turn on RFC8138 compression feature within a RPL network Done - Initial submission of a root initiated routing state in RPL to the IESG Internet-Drafts: - MPL Parameter Configuration Option for DHCPv6 [draft-doi-roll-mpl-parameter-configuration-05] (10 pages) - Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL) [draft-ietf-roll-admin-local-policy-03] (15 pages) - Supporting Asymmetric Links in Low Power Networks: AODV-RPL [draft-ietf-roll-aodv-rpl-18] (44 pages) - Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks [draft-ietf-roll-applicability-ami-15] (24 pages) - Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control [draft-ietf-roll-applicability-home-building-12] (38 pages) - ROLL Applicability Statement Template [draft-ietf-roll-applicability-template-09] (10 pages) - Building Automation Routing Requirements in Low-Power and Lossy Networks [draft-ietf-roll-building-routing-reqs-09] (26 pages) - RPL Capabilities [draft-ietf-roll-capabilities-09] (17 pages) - Constrained-Cast: Source-Routed Multicast for RPL [draft-ietf-roll-ccast-01] (10 pages) - Root initiated routing state in RPL [draft-ietf-roll-dao-projection-34] (88 pages) - DIS Modifications [draft-ietf-roll-dis-modifications-01] (15 pages) - Efficient Route Invalidation [draft-ietf-roll-efficient-npdao-18] (21 pages) - Controlling Secure Network Enrollment in RPL networks [draft-ietf-roll-enrollment-priority-11] (10 pages) - Home Automation Routing Requirements in Low-Power and Lossy Networks [draft-ietf-roll-home-routing-reqs-11] (17 pages) - Industrial Routing Requirements in Low-Power and Lossy Networks [draft-ietf-roll-indus-routing-reqs-06] (27 pages) - The Minimum Rank with Hysteresis Objective Function [draft-ietf-roll-minrank-hysteresis-of-11] (13 pages) - Mode of Operation extension [draft-ietf-roll-mopex-07] (10 pages) - Mode of Operation extension and Capabilities [draft-ietf-roll-mopex-cap-01] (10 pages) - MPL Forwarder Select (MPLFS) [draft-ietf-roll-mpl-forw-select-00] (10 pages) - Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6 [draft-ietf-roll-mpl-parameter-configuration-08] (10 pages) - A YANG model for Multicast Protocol for Low power and lossy Networks (MPL) [draft-ietf-roll-mpl-yang-02] (30 pages) - Common Ancestor Objective Function and Parent Set DAG Metric Container Extension [draft-ietf-roll-nsa-extension-12] (18 pages) - Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL) [draft-ietf-roll-of0-20] (14 pages) - A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network [draft-ietf-roll-p2p-measurement-10] (29 pages) - Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks [draft-ietf-roll-p2p-rpl-17] (40 pages) - Overview of Existing Routing Protocols for Low Power and Lossy Networks [draft-ietf-roll-protocols-survey-07] (26 pages) - RNFD: Fast border router crash detection in RPL [draft-ietf-roll-rnfd-04] (26 pages) - IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header [draft-ietf-roll-routing-dispatch-05] (37 pages) - Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks [draft-ietf-roll-routing-metrics-19] (30 pages) - RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks [draft-ietf-roll-rpl-19] (157 pages) - RPL applicability in industrial networks [draft-ietf-roll-rpl-industrial-applicability-02] (31 pages) - RPL Observations [draft-ietf-roll-rpl-observations-07] (21 pages) - A Security Framework for Routing over Low Power and Lossy Networks [draft-ietf-roll-security-framework-07] (49 pages) - A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs) [draft-ietf-roll-security-threats-11] (40 pages) - Terms Used in Routing for Low-Power and Lossy Networks [draft-ietf-roll-terminology-13] (8 pages) - The Trickle Algorithm [draft-ietf-roll-trickle-08] (13 pages) - Multicast Protocol for Low-Power and Lossy Networks (MPL) [draft-ietf-roll-trickle-mcast-12] (29 pages) - A Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic Graph (DODAG) Configuration Option for the 6LoWPAN Routing Header [draft-ietf-roll-turnon-rfc8138-18] (9 pages) - Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves [draft-ietf-roll-unaware-leaves-30] (36 pages) - Routing Requirements for Urban Low-Power and Lossy Networks [draft-ietf-roll-urban-routing-reqs-05] (21 pages) - Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane [draft-ietf-roll-useofrplinfo-44] (49 pages) - ROLL Applicability Statement Template [draft-richardson-roll-applicability-template-02] (15 pages) - MPL forwarder policy for multicast with admin-local scope [draft-vanderstok-roll-admin-local-policy-00] (8 pages) Requests for Comments: RFC5548: Routing Requirements for Urban Low-Power and Lossy Networks (21 pages) RFC5673: Industrial Routing Requirements in Low-Power and Lossy Networks (27 pages) RFC5826: Home Automation Routing Requirements in Low-Power and Lossy Networks (17 pages) RFC5867: Building Automation Routing Requirements in Low-Power and Lossy Networks (26 pages) RFC6206: The Trickle Algorithm (13 pages) RFC6550: RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks (157 pages) * Updates RFC9008 * Updates RFC9010 RFC6551: Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks (30 pages) RFC6552: Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL) (14 pages) RFC6719: The Minimum Rank with Hysteresis Objective Function (13 pages) RFC6997: Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks (40 pages) RFC6998: A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network (29 pages) RFC7102: Terms Used in Routing for Low-Power and Lossy Networks (8 pages) RFC7416: A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs) (40 pages) RFC7731: Multicast Protocol for Low-Power and Lossy Networks (MPL) (29 pages) RFC7732: Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL) (15 pages) RFC7733: Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control (38 pages) RFC7774: Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6 (10 pages) RFC8036: Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks (24 pages) RFC8138: IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header (37 pages) * Updates RFC9008 * Updates RFC9035 RFC9008: Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane (49 pages) RFC9009: Efficient Route Invalidation (21 pages) RFC9010: Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves (36 pages) RFC9035: A Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic Graph (DODAG) Configuration Option for the 6LoWPAN Routing Header (9 pages) Routing Area Working Group (rtgwg) ---------------------------------- Charter Last Modified: 2023-03-29 Current Status: Active Chairs: Jeff Tantsura Yingzhen Qu Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Jim Guichard Mailing Lists: General Discussion: rtgwg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/rtgwg Archive: https://mailarchive.ietf.org/arch/browse/rtgwg/ Description of Working Group: The Routing Area working group (RTGWG) is chartered to provide a venue to discuss, evaluate, support and develop proposals for new work in the Routing Area and may work on specific small topics that do not fit with an existing working group. Options for handling new work include: - Directing the work to an existing WG (including RTGWG) - Developing a proposal for a BoF. - Developing a charter and establishing consensus for a new WG. This option will primarily be used with fairly mature and/or well-defined efforts. - Careful evaluation, leading to deferring or rejecting work. It is expected that the proposals for new work will only include items which are not aligned with the work of other WGs or that may span multiple WGs. The Area Directors and WG Chairs can provide guidance if there is any doubt whether a topic should be discussed in RTGWG. A major objective of the RTGWG is to provide timely, clear dispositions of new efforts. Where there is consensus to take on new work, the WG will strive to quickly find a home for it. Reconsideration of proposals which have failed to gather consensus will be prioritized behind proposals for new work which have not yet been considered. In general, requests for reconsideration should only be made once a proposal has been significantly revised. If RTGWG decides that a particular topic should be addressed by a new WG, the chairs will recommend the work to the Routing ADs with a summary of the evaluation. The Routing ADs may then choose to follow the normal IETF chartering process (potential BoF, IETF-wide review of the proposed charter, etc.). Guiding principles for evaluation of new work by RTGWG will include: 1. Providing a clear problem statement for proposed new work. 2. Prioritizing new efforts to manage the trade-offs between urgency, interest, and available resources in the Routing Area. 3. Looking for commonalities among ongoing efforts. Such commonalities may indicate the need to develop more general, reusable solutions. 4. Ensuring appropriate cross-WG and cross-area review. 5. Protecting the architectural integrity of the protocols developed in the Routing Area and ensuring that work has significant applicability. RTGWG may also work on specific small topics that do not fit with an existing working group. An example of a small topic is a draft that might otherwise be AD-sponsored but which could benefit from the review and consensus that RTGWG can provide. RTGWG may work on larger topics, but must be explicitly rechartered to add the topic. The specific larger topics that RTGWG is currently chartered to work on: * Enhancements to hop-by-hop distributed routing (e.g., multicast, LDP-MPLS, unicast routing) related to fast-reroute and loop-free convergence. A specific goal of fast-reroute mechanisms is to provide up to complete coverage when the potential failure would not partition the network. All work in this area should be specifically evaluated by the WG in terms of practicality and applicability to deployed networks. * Routing-related YANG models that are not appropriate for other RTG working groups. The working group milestones will be updated as needed to reflect the proposals currently being worked on and the target dates for their completion. Goals and Milestones: Feb 2024 - SUBMITTED: Topology Independent Fast Reroute using Segment Routing Internet-Drafts: - RIB YANG Data Model [draft-acee-rtgwg-yang-rib-extend-10] (21 pages) - YANG Model for QoS [draft-asechoud-rtgwg-qos-model-11] (89 pages) - Topology Independent Fast Reroute using Segment Routing [draft-bashandy-rtgwg-segment-routing-ti-lfa-05] (19 pages) - Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution [draft-bowbakova-rtgwg-enterprise-pa-multihoming-01] (45 pages) - Routing Timer Parameter Synchronization [draft-bryant-rtgwg-param-sync-03] (10 pages) - SRv6 Egress Protection in Multi-homed scenario [draft-cheng-rtgwg-srv6-multihome-egress-protection-06] (12 pages) - YANG Data Model for ARP [draft-ding-rtgwg-arp-yang-model-02] (15 pages) - Multi-segment SD-WAN via Cloud DCs [draft-dmk-rtgwg-multisegment-sdwan-07] (31 pages) - Calculating IGP routes over Traffic Engineering tunnels [draft-hsmit-mpls-igp-spf-01] (6 pages) - SRv6 Path Egress Protection [draft-hu-rtgwg-srv6-egress-protection-08] (16 pages) - A YANG Data Model for ARP [draft-ietf-rtgwg-arp-yang-model-04] (19 pages) - A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network [draft-ietf-rtgwg-atn-bgp-26] (28 pages) - Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs [draft-ietf-rtgwg-backoff-algo-10] (14 pages) - BGP Prefix Independent Convergence [draft-ietf-rtgwg-bgp-pic-21] (32 pages) - Use of BGP for Routing in Large-Scale Data Centers [draft-ietf-rtgwg-bgp-routing-large-dc-11] (35 pages) - Advanced Multipath Framework in MPLS [draft-ietf-rtgwg-cl-framework-04] (43 pages) - Requirements for Advanced Multipath in MPLS Networks [draft-ietf-rtgwg-cl-requirement-16] (17 pages) - Advanced Multipath Use Cases and Design Considerations [draft-ietf-rtgwg-cl-use-cases-06] (24 pages) - Network Device YANG Logical Organization [draft-ietf-rtgwg-device-model-02] (22 pages) - Destination/Source Routing [draft-ietf-rtgwg-dst-src-routing-07] (21 pages) - Destination/Source Routing [draft-ietf-rtgwg-dst-src-routing-revive-01] (23 pages) - Encapsulation Considerations [draft-ietf-rtgwg-dt-encap-02] (42 pages) - Enterprise Multihoming using Provider-Assigned IPv6 Addresses without Network Prefix Translation: Requirements and Solutions [draft-ietf-rtgwg-enterprise-pa-multihoming-12] (43 pages) - Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels [draft-ietf-rtgwg-igp-shortcut-01] (8 pages) - IP Fast Reroute Framework [draft-ietf-rtgwg-ipfrr-framework-13] (15 pages) - IP MIB for IP Fast-Reroute [draft-ietf-rtgwg-ipfrr-ip-mib-08] (28 pages) - A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses [draft-ietf-rtgwg-ipfrr-notvia-addresses-11] (34 pages) - Basic Specification for IP Fast Reroute: Loop-Free Alternates [draft-ietf-rtgwg-ipfrr-spec-base-12] (31 pages) - Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks [draft-ietf-rtgwg-lfa-applicability-06] (35 pages) - Operational Management of Loop-Free Alternates [draft-ietf-rtgwg-lfa-manageability-11] (31 pages) - A Framework for Loop-Free Convergence [draft-ietf-rtgwg-lf-conv-frmwk-07] (22 pages) - YANG Model for Logical Network Elements [draft-ietf-rtgwg-lne-model-10] (49 pages) - Analysis and Minimization of Microloops in Link-state Routing Protocols [draft-ietf-rtgwg-microloop-analysis-01] (17 pages) - Multicast-Only Fast Reroute [draft-ietf-rtgwg-mofrr-08] (14 pages) - An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR) [draft-ietf-rtgwg-mrt-frr-algorithm-09] (118 pages) - An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR) [draft-ietf-rtgwg-mrt-frr-architecture-10] (44 pages) - Selection of Loop-Free Alternates for Multi-Homed Prefixes [draft-ietf-rtgwg-multihomed-prefix-lfa-09] (20 pages) - Multi-segment SD-WAN via Cloud DCs [draft-ietf-rtgwg-multisegment-sdwan-01] (32 pages) - Networks Connecting to Hybrid Cloud DCs: Gap Analysis [draft-ietf-rtgwg-net2cloud-gap-analysis-09] (19 pages) - Dynamic Networks to Hybrid Cloud DCs: Problems and Mitigation Practices [draft-ietf-rtgwg-net2cloud-problem-statement-41] (24 pages) - YANG Data Model for Network Instances [draft-ietf-rtgwg-ni-model-12] (44 pages) - Node Potential Oriented Multi-NextHop Routing Protocol [draft-ietf-rtgwg-npmnrp-00] (25 pages) - Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach [draft-ietf-rtgwg-ordered-fib-12] (28 pages) - A YANG Data Model for Routing Policy [draft-ietf-rtgwg-policy-model-31] (38 pages) - YANG Models for Quality of Service (QoS) [draft-ietf-rtgwg-qos-model-12] (112 pages) - Remote Loop-Free Alternate (LFA) Fast Reroute (FRR) [draft-ietf-rtgwg-remote-lfa-11] (29 pages) - The Generalized TTL Security Mechanism (GTSM) [draft-ietf-rtgwg-rfc3682bis-10] (16 pages) - Remote-LFA Node Protection and Manageability [draft-ietf-rtgwg-rlfa-node-protection-13] (22 pages) - Routing Timer Parameter Synchronization [draft-ietf-rtgwg-routing-timer-param-sync-00] (10 pages) - Common YANG Data Types for the Routing Area [draft-ietf-rtgwg-routing-types-17] (43 pages) - Topology Independent Fast Reroute using Segment Routing [draft-ietf-rtgwg-segment-routing-ti-lfa-17] (26 pages) - Impact of Shortest Path First (SPF) Trigger and Delay Strategies on IGP Micro-loops [draft-ietf-rtgwg-spf-uloop-pb-statement-10] (15 pages) - SRv6 Path Egress Protection [draft-ietf-rtgwg-srv6-egress-protection-16] (21 pages) - Micro-loop Prevention by Introducing a Local Convergence Delay [draft-ietf-rtgwg-uloop-delay-09] (26 pages) - Fast failure detection in VRRP with Point to Point BFD [draft-ietf-rtgwg-vrrp-bfd-p2p-01] (21 pages) - Applicability of Bidirectional Forwarding Detection (BFD) for Multi-point Networks in Virtual Router Redundancy Protocol (VRRP) [draft-ietf-rtgwg-vrrp-p2mp-bfd-09] (7 pages) - Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 [draft-ietf-rtgwg-vrrp-rfc5798bis-18] (44 pages) - YANG Data Model for Key Chains [draft-ietf-rtgwg-yang-key-chain-24] (25 pages) - A YANG Data Model for RIB Extensions [draft-ietf-rtgwg-yang-rib-extend-24] (22 pages) - A YANG Data Model for the Routing Information Protocol (RIP) [draft-ietf-rtgwg-yang-rip-11] (40 pages) - A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP) [draft-ietf-rtgwg-yang-vrrp-11] (45 pages) - Destination/Source Routing [draft-lamparter-rtgwg-dst-src-routing-01] (8 pages) - Microloop prevention by introducing a local convergence delay [draft-litkowski-rtgwg-uloop-delay-04] (15 pages) - A YANG Data Model for Routing Information Protocol (RIP) [draft-liu-rtgwg-yang-rip-01] (30 pages) - A YANG Data Model for Virtual Router Redundancy Protocol (VRRP) [draft-liu-rtgwg-yang-vrrp-04] (30 pages) - LFA selection for Multi-Homed Prefixes [draft-psarkar-rtgwg-multihomed-prefix-lfa-04] (16 pages) - Remote-LFA Node Protection and Manageability [draft-psarkar-rtgwg-rlfa-node-protection-05] (16 pages) - Encapsulation Considerations [draft-rtg-dt-encap-02] (41 pages) - Network Device YANG Organizational Models [draft-rtgyangdt-rtgwg-device-model-05] (22 pages) - Logical Network Element Model [draft-rtgyangdt-rtgwg-lne-model-00] (13 pages) - Network Instance Model [draft-rtgyangdt-rtgwg-ni-model-00] (15 pages) - Routing Area Common YANG Data Types [draft-rtgyangdt-rtgwg-routing-types-00] (16 pages) - Routing Policy Configuration Model for Service Provider Networks [draft-shaikh-rtgwg-policy-model-01] (30 pages) - A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network [draft-templin-atn-bgp-08] (18 pages) Requests for Comments: RFC3906: Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels (8 pages) RFC5082: The Generalized TTL Security Mechanism (GTSM) (16 pages) RFC5286: Basic Specification for IP Fast Reroute: Loop-Free Alternates (31 pages) * Updates RFC8518 RFC5714: IP Fast Reroute Framework (15 pages) RFC5715: A Framework for Loop-Free Convergence (22 pages) RFC6571: Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks (35 pages) RFC6976: Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach (28 pages) RFC6981: A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses (34 pages) RFC7226: Requirements for Advanced Multipath in MPLS Networks (17 pages) RFC7431: Multicast-Only Fast Reroute (14 pages) RFC7490: Remote Loop-Free Alternate (LFA) Fast Reroute (FRR) (29 pages) RFC7811: An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR) (118 pages) RFC7812: An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR) (44 pages) RFC7916: Operational Management of Loop-Free Alternates (31 pages) RFC7938: Use of BGP for Routing in Large-Scale Data Centers (35 pages) RFC8102: Remote-LFA Node Protection and Manageability (22 pages) RFC8177: YANG Data Model for Key Chains (25 pages) RFC8294: Common YANG Data Types for the Routing Area (43 pages) RFC8333: Micro-loop Prevention by Introducing a Local Convergence Delay (26 pages) RFC8347: A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP) (45 pages) RFC8405: Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs (14 pages) RFC8518: Selection of Loop-Free Alternates for Multi-Homed Prefixes (20 pages) RFC8529: YANG Data Model for Network Instances (44 pages) RFC8530: YANG Model for Logical Network Elements (49 pages) RFC8541: Impact of Shortest Path First (SPF) Trigger and Delay Strategies on IGP Micro-loops (15 pages) RFC8678: Enterprise Multihoming using Provider-Assigned IPv6 Addresses without Network Prefix Translation: Requirements and Solutions (43 pages) RFC8695: A YANG Data Model for the Routing Information Protocol (RIP) (40 pages) RFC9067: A YANG Data Model for Routing Policy (38 pages) RFC9403: A YANG Data Model for RIB Extensions (22 pages) RFC9568: Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 (35 pages) Source Address Validation in Intra-domain and Inter-domain Networks (savnet) ---------------------------------------------------------------------------- Charter Last Modified: 2023-03-29 Current Status: Active Chairs: Aijun Wang Joel M. Halpern Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Jim Guichard Secretary: Haoyu Song Mailing Lists: General Discussion: savnet@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/savnet Archive: https://mailarchive.ietf.org/arch/browse/savnet/ Description of Working Group: Source address validation (SAV) is one important way to mitigate source address spoofing attacks in the data plane. Therefore, it is desirable to deploy SAV in intra-domain and inter-domain networks. However, existing SAV mechanisms like uRPF-related technologies may improperly permit spoofed traffic or block legitimate traffic. The "Source Address Validation in Intra-domain and Inter-domain Networks (SAVNET)" working group will define routing-protocol-independent architectures and procedures to accurately determine the valid incoming router interfaces for specific source prefixes. The accuracy of the new SAV mechanisms is expected to improve upon the current ones. The WG will not work on extending existing mechanisms. The scope of the SAVNET WG includes the SAV function for both intra-domain and inter-domain networks and the validation of both IPv4 and IPv6 addresses. The WG will address intra-domain solutions first and focus on routing protocol- based mechanisms. SAVNET should avoid packet modification in the data plane. Existing control and management plane protocols should be used within existing architectures to implement the SAV function. Any modification of or extension to existing architectures or control or management plane protocols must be carried out in the working groups responsible for them and in coordination with this working group. The SAVNET WG is chartered for the following list of items: (1) Problem Statement, Use Cases, and Requirements This document should include an analysis of the current solutions and their limitations. This item may require one document to address intra-domain SAV and another to address inter-domain SAV. This document may not necessarily be published as an IETF Stream RFC, but may be maintained in draft form or on a collaborative Working Group space to support the efforts of the Working Group and help newcomers. (2) SAVNET Architecture Documents This item requires one document to address intra-domain SAV and another to address inter-domain SAV. Each document must describe the conditions under which the architecture can improve accuracy or performance with respect to existing SAV mechanisms without assuming pervasive adoption. Each document must also include a privacy analysis, the threat model addressed by the proposed architecture, and a comparison to existing SAV mechanisms. (3) Definition of routing protocol-independent operation and management mechanisms to operate and manage SAV-related configurations. After the WG has reached consensus on each item, a discussion about whether it is appropriate to continue with further work must occur. The discussion can consider topics related to the accuracy of the mechanism and the types of attacks it can prevent. The WG Chairs will define the specific criteria and determine that rough consensus to work further has been reached. The WG may be rechartered or closed if rough consensus is not reached. The SAVNET WG will coordinate and collaborate with other WGs as needed. Specific interactions may include (but are not limited to): * lsr for OSPFv2, OSPFv3 and IS-IS extensions * idr for BGP extensions * lsvr for BGP SPF extensions * rift for RIFT extensions Each of these other WGs can independently determine the applicability and priority of SAV to their deployments. Goals and Milestones: Nov 2022 - Adopt the Problem Statement, Use Cases, and Requirements document Jul 2023 - Adopt the Intra-Domain Architecture document Mar 2024 - Submit the Intra-Domain Architecture document to the IESG for publication Mar 2024 - Adopt operations and management for Intra-domain networks document Mar 2024 - Adopt the Inter-Domain Architecture document Jul 2024 - Submit operations and management for Intra-domain networks document to the IESG for publication Nov 2024 - Submit the Inter-Domain Architecture document to the IESG for publication Nov 2024 - Adopt operations and management for Inter-domain networks document Mar 2025 - Submit operations and management for Inter-domain networks document to the IESG for publication Internet-Drafts: - Source Address Validation in Inter-domain Networks Gap Analysis, Problem Statement, and Requirements [draft-ietf-savnet-inter-domain-problem-statement-05] (29 pages) - Intra-domain Source Address Validation (SAVNET) Architecture [draft-ietf-savnet-intra-domain-architecture-00] (20 pages) - Source Address Validation in Intra-domain Networks Gap Analysis, Problem Statement, and Requirements [draft-ietf-savnet-intra-domain-problem-statement-06] (17 pages) - Source Address Validation Using BGP UPDATEs, ASPA, and ROA (BAR-SAV) [draft-ietf-sidrops-bar-sav-04] (15 pages) - Intra-domain Source Address Validation (SAVNET) Architecture [draft-li-savnet-intra-domain-architecture-07] (20 pages) - Source Address Validation in Intra-domain Networks Gap Analysis, Problem Statement, and Requirements [draft-li-savnet-intra-domain-problem-statement-07] (13 pages) - Source Address Validation in Inter-domain Networks Gap Analysis, Problem Statement, and Requirements [draft-wu-savnet-inter-domain-problem-statement-09] (29 pages) No Requests for Comments Source Packet Routing in Networking (spring) -------------------------------------------- Charter Last Modified: 2023-04-21 Current Status: Active Chairs: Alvaro Retana Bruno Decraene Joel M. Halpern Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Jim Guichard Secretary: Shuping Peng Mailing Lists: General Discussion: spring@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/spring Archive: https://mailarchive.ietf.org/arch/browse/spring/ Description of Working Group: The Source Packet Routing in NetworkinG (SPRING) Working Group is the home of Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6). SPRING WG serves as a forum to discuss SPRING networks operations, define new applications of, and specify extensions of Segment Routing technologies. SPRING WG should avoid modification to existing data planes that would make them incompatible with existing deployments. Where possible, existing control and management plane protocols must be used within existing architectures to implement the SPRING function. Any modification of -or extension to- existing architectures, data planes, or control or management plane protocols should be carried out in the WGs responsible for the architecture, data plane, or control or management plane protocol being modified and in coordination with the SPRING WG, but may be done in SPRING WG after agreement with all the relevant WG chairs and responsible Area Directors. The SPRING WG defines procedures that allow a node to steer a packet through an SR Policy instantiated as an ordered list of instructions called segments and without the need for per-path state information to be held at transit nodes. Full explicit control (through loose or strict path specification) can be achieved in a network comprising only SPRING nodes, however SPRING nodes must inter-operate through loose routing in existing networks and may find it advantageous to use loose routing for other network applications. The scope of the SPRING WG work includes both single Autonomous System (AS) and multi-AS environments. Segment Routing typically operates within a single trust domain which requires the enforcement of a strict boundary and preventing Segment Routing packets from entering the trusted domain from the untrusted exterior. Certain deployments may however involve multiple trust domains which in turn may imply the use of cross/inter domain segments. Risk models associated with these various scenarios may necessitate the use of a cryptographic integrity checks to validate that the segment list is provided by an authorised entity. As is customary in the Routing Area, the SPRING WG will also identify and address any other security considerations introduced by the technologies it defines; addressing such considerations may require the introduction of new functionality in protocols leveraged for Source Routing, in which case the SPRING WG will formulate requirements to be considered by the appropriate WG for that work. The SPRING WG is however not expected to wait on the development of a solution to these requirements before progressing its own documents. SPRING technologies may be deployed in environments spanning a range of risk and threat models, which may impact both the security considerations and the requirements placed on other protocols in order to support Source Routing protocols. The technologies SPRING WG defines may be applicable to both centralised and distributed path computation. The SPRING WG will manage its specific work items by milestones agreed with the responsible Area Director. The work-items of the SPRING WG include functional specifications for: o Segment Routing policies and the associated steering, signalling and traffic engineering mechanisms. o Source-routed stateless service chaining using SR-MPLS and SRv6 dataplanes. o SRv6 network programming for the underlay networks and overlay services, and including data plane behavior and functions associated with SIDs o Operation, Administration and Management (OAM), and traffic accounting in networks with SR-MPLS and SRv6 data planes in the case where SR introduces specificities compared to MPLS or IPv6 technologies. o Performance Management (PM) and monitoring in networks with SR-MPLS and SRv6 data planes in the case where SR introduces specificities compared to MPLS or IPv6 technologies. o Inter-working between SRv6 and SR-MPLS and between SR and existing routing solutions to allow for seamless deployment and co-existence. o New types of segments mapping to forwarding behaviour (e.g., local ingress replication, local forwarding resources, a pre-existing replication structure) if needed for new usages. Any of the above may require architectural extensions. The work-items of SPRING WG also include: o Specification of management models (YANG) for Segment Routing applications, services and networks with SR-MPLS and SRv6 dataplanes. The SPRING WG will coordinate and collaborate with other WGs as needed. Specific expected interactions include (but may not be limited to): * mpls on the MPLS dataplane and OAM extensions, * 6man on the IPv6 dataplane for SR and associated OAM extensions * lsr on OSPF and IS-IS extensions to flood SPRING-related information * idr for BGP extensions * bess for VPN control plane * pce on extensions to communicate with an external entity to compute and program SPRING paths * teas on generic traffic engineering architecture * sfc on service chaining applications * rtgwg on fast-reroute technologies Goals and Milestones: Oct 2018 - MPLS anycast sent to IESG Dec 2019 - Stateless service chaining with SR sent to IESG Dec 2019 - SR policies YANG model sent to IESG RFC8660 - SR-MPLS sent to IESG RFC8986 - SRv6 Network Programming to IESG RFC9020 - SR-MPLS configuration YANG model sent to IESG RFC9256 - SR-TE policy sent to IESG Internet-Drafts: - SRv6 and MPLS interworking [draft-agrawal-spring-srv6-mpls-interworking-15] (24 pages) - SRv6 Security Considerations [draft-bdmgct-spring-srv6-security-02] (21 pages) - Path Segment in MPLS Based Segment Routing Network [draft-cheng-spring-mpls-path-segment-03] (11 pages) - Segment Routing Architecture [draft-filsfils-spring-segment-routing-04] (18 pages) - Segment Routing with MPLS data plane [draft-filsfils-spring-segment-routing-mpls-03] (14 pages) - Segment Routing Policy Architecture [draft-filsfils-spring-segment-routing-policy-06] (34 pages) - Segment Routing Recursive Information [draft-filsfils-spring-sr-recursing-info-05] (8 pages) - SRv6 Network Programming [draft-filsfils-spring-srv6-network-programming-07] (42 pages) - Use-cases for Resiliency in SPRING [draft-francois-spring-resiliency-use-case-02] (8 pages) - Performance Measurement Using Simple TWAMP (STAMP) for Segment Routing Networks [draft-gandhi-spring-stamp-srpm-07] (23 pages) - Performance Measurement Using TWAMP Light for Segment Routing Networks [draft-gandhi-spring-twamp-srpm-11] (21 pages) - Segment Routing Conflict Resolution [draft-ginsberg-spring-conflict-resolution-01] (15 pages) - NSH and Segment Routing Integration for Service Function Chaining (SFC) [draft-guichard-spring-nsh-sr-01] (16 pages) - Node Protection for SR-TE Paths [draft-hegde-spring-node-protection-for-sr-te-paths-07] (14 pages) - SR-TE Path Midpoint Restoration [draft-hu-spring-segment-routing-proxy-forwarding-24] (14 pages) - Bidirectional Forwarding Detection (BFD) in Segment Routing Networks Using MPLS Dataplane [draft-ietf-spring-bfd-12] (16 pages) - Compressed SRv6 SID List Analysis [draft-ietf-spring-compression-analysis-03] (32 pages) - Compressed SRv6 SID List Requirements [draft-ietf-spring-compression-requirement-03] (16 pages) - Segment Routing MPLS Conflict Resolution [draft-ietf-spring-conflict-resolution-05] (22 pages) - Circuit Style Segment Routing Policies [draft-ietf-spring-cs-sr-policy-02] (26 pages) - Distribute SRv6 Locator by DHCP [draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-03] (18 pages) - Use Cases for IPv6 Source Packet Routing in Networking (SPRING) [draft-ietf-spring-ipv6-use-cases-12] (9 pages) - Anycast Segments in MPLS based Segment Routing [draft-ietf-spring-mpls-anycast-segments-03] (19 pages) - Path Segment Identifier in MPLS Based Segment Routing Network [draft-ietf-spring-mpls-path-segment-22] (17 pages) - Node Protection for SR-TE Paths [draft-ietf-spring-node-protection-for-sr-te-paths-00] (13 pages) - Integration of the Network Service Header (NSH) and Segment Routing for Service Function Chaining (SFC) [draft-ietf-spring-nsh-sr-15] (17 pages) - A Scalable and Topology-Aware MPLS Data-Plane Monitoring System [draft-ietf-spring-oam-usecase-10] (19 pages) - Path MTU (PMTU) for Segment Routing (SR) Policy [draft-ietf-spring-pmtu-sr-policy-01] (12 pages) - Source Packet Routing in Networking (SPRING) Problem Statement and Requirements [draft-ietf-spring-problem-statement-08] (19 pages) - Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks [draft-ietf-spring-resiliency-use-cases-12] (13 pages) - Introducing Resource Awareness to SR Segments [draft-ietf-spring-resource-aware-segments-09] (13 pages) - Segment Protection for SR-TE Paths [draft-ietf-spring-segment-protection-sr-te-paths-06] (20 pages) - Segment Routing Architecture [draft-ietf-spring-segment-routing-15] (32 pages) - Segment Routing Centralized BGP Egress Peer Engineering [draft-ietf-spring-segment-routing-central-epe-10] (17 pages) - Segment Routing MPLS Interworking with LDP [draft-ietf-spring-segment-routing-ldp-interop-15] (21 pages) - Segment Routing with the MPLS Data Plane [draft-ietf-spring-segment-routing-mpls-22] (29 pages) - BGP Prefix Segment in Large-Scale Data Centers [draft-ietf-spring-segment-routing-msdc-11] (18 pages) - Segment Routing Policy Architecture [draft-ietf-spring-segment-routing-policy-22] (35 pages) - Segment Routing based Network Resource Partition (NRP) for Enhanced VPN [draft-ietf-spring-sr-for-enhanced-vpn-07] (20 pages) - OAM Requirements for Segment Routing Network [draft-ietf-spring-sr-oam-requirement-03] (7 pages) - YANG Data Model for Segment Routing Policy [draft-ietf-spring-sr-policy-yang-03] (65 pages) - SRv6 for Redundancy Protection [draft-ietf-spring-sr-redundancy-protection-03] (10 pages) - SR Replication segment for Multi-point Service Delivery [draft-ietf-spring-sr-replication-segment-19] (27 pages) - Service Programming with Segment Routing [draft-ietf-spring-sr-service-programming-10] (37 pages) - Segment Routing over IPv6 (SRv6) Network Programming [draft-ietf-spring-srv6-network-programming-28] (40 pages) - Path Segment for SRv6 (Segment Routing in IPv6) [draft-ietf-spring-srv6-path-segment-10] (15 pages) - Segment Routing IPv6 Security Considerations [draft-ietf-spring-srv6-security-00] (21 pages) - Compressed SRv6 Segment List Encoding [draft-ietf-spring-srv6-srh-compression-18] (78 pages) - YANG Data Model for SRv6 Base and Static [draft-ietf-spring-srv6-yang-03] (76 pages) - YANG Data Model for Segment Routing [draft-ietf-spring-sr-yang-30] (39 pages) - Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing Networks [draft-ietf-spring-stamp-srpm-15] (52 pages) - OAM Requirements for Segment Routing Network [draft-kumar-spring-sr-oam-requirement-03] (6 pages) - Path Segment for SRv6 (Segment Routing in IPv6) [draft-li-spring-srv6-path-segment-07] (11 pages) - YANG Data Model for Segment Routing [draft-litkowski-spring-sr-yang-01] (21 pages) - IPv6 SPRING Use Cases [draft-martin-spring-segment-routing-ipv6-use-cases-01] (12 pages) - Bidirectional Forwarding Detection (BFD) in Segment Routing Networks Using MPLS Dataplane [draft-mirsky-spring-bfd-10] (14 pages) - Path MTU (PMTU) for Segment Routing (SR) Policy [draft-peng-spring-pmtu-sr-policy-03] (13 pages) - SPRING Problem Statement and Requirements [draft-previdi-spring-problem-statement-04] (18 pages) - Anycast Segments in MPLS based Segment Routing [draft-psarkar-spring-mpls-anycast-segments-02] (19 pages) - Circuit Style Segment Routing Policies [draft-schmutzer-spring-cs-sr-policy-02] (20 pages) - Compressed SRv6 SID List Analysis [draft-srcompdt-spring-compression-analysis-02] (28 pages) - Compressed SRv6 SID List Requirements [draft-srcompdt-spring-compression-requirement-07] (16 pages) - SR Replication Segment for Multi-point Service Delivery [draft-voyer-spring-sr-replication-segment-04] (10 pages) - Service Programming with Segment Routing [draft-xuclad-spring-sr-service-programming-02] (31 pages) Requests for Comments: RFC7855: Source Packet Routing in Networking (SPRING) Problem Statement and Requirements (19 pages) RFC8354: Use Cases for IPv6 Source Packet Routing in Networking (SPRING) (9 pages) RFC8355: Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks (13 pages) RFC8402: Segment Routing Architecture (32 pages) * Updates RFC9256 RFC8403: A Scalable and Topology-Aware MPLS Data-Plane Monitoring System (19 pages) RFC8660: Segment Routing with the MPLS Data Plane (29 pages) RFC8661: Segment Routing MPLS Interworking with LDP (21 pages) RFC8670: BGP Prefix Segment in Large-Scale Data Centers (18 pages) RFC8986: Segment Routing over IPv6 (SRv6) Network Programming (40 pages) RFC9020: YANG Data Model for Segment Routing (39 pages) RFC9087: Segment Routing Centralized BGP Egress Peer Engineering (17 pages) RFC9256: Segment Routing Policy Architecture (35 pages) RFC9491: Integration of the Network Service Header (NSH) and Segment Routing for Service Function Chaining (SFC) (17 pages) RFC9524: Segment Routing Replication for Multipoint Service Delivery (22 pages) RFC9545: Path Segment Identifier in MPLS-Based Segment Routing Networks (11 pages) Traffic Engineering Architecture and Signaling (teas) ----------------------------------------------------- Charter Last Modified: 2024-07-25 Current Status: Active Chairs: Oscar Gonzalez de Dios Vishnu Pavan Beeram Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Jim Guichard Tech Advisors: Adrian Farrel Lou Berger Mailing Lists: General Discussion: teas@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/teas Archive: https://mailarchive.ietf.org/arch/browse/teas/ Description of Working Group: The Traffic Engineering Architecture and Signaling (TEAS) Working Group is responsible for defining IP, MPLS and GMPLS traffic engineering architecture and identifying required related control-protocol functions, i.e., routing and path computation element functions. The TEAS group is also responsible for standardizing RSVP-TE signaling protocol mechanisms that are not related to a specific switching technology. Traffic Engineering (TE) is the term used to refer to techniques that enable operators to control how specific traffic flows are treated within their networks. TE is applied to packet networks via MPLS TE tunnels and LSPs, but may also be provided by other mechanisms such as forwarding rules similar to policy-based routing. The MPLS-TE control plane was generalized to additionally support non-packet technologies via GMPLS. RSVP-TE is the signaling protocol used for both MPLS-TE and GMPLS. Centralized and logically centralized control models are also supported, e.g., via Abstraction and Control of Traffic Engineered Networks (ACTN) and stateful-PCE. The TEAS WG is responsible for: a) Traffic-engineering architectures for generic applicability across packet and non-packet networks. This includes, for example, networks that perform centralized computation and control, distributed computation and control, or even a hybrid approach. b) Definition of protocol-independent metrics and parameters (measurement and/or service attributes) for describing links and tunnels/paths required for traffic engineering (and related routing, signaling and path computation). These will be developed in conjunction with requests and requirements from other WGs to ensure overall usefulness. c) Functional specification of extensions for routing (OSPF, ISIS) and for path computation (PCEP), including those that provide general enablers of traffic-engineering systems that may also use RSVP-TE. Protocol formats and procedures that embody these extensions will be done in coordination with the WGs supervising those protocols. d) Functional specification of generic (i.e., not data plane technology-specific) extensions for RSVP-TE, and the associated protocol formats and procedures that embody these extensions. e) Definition of control plane mechanisms and extensions to allow the setup and maintenance of TE paths and TE tunnels that span multiple domains and/or switching technologies, where a domain may be an IGP area, an Autonomous System, or any other region of topological visibility. f) Definition and extension of management and security techniques for TE path and tunnel control. This includes configuring and monitoring RSVP-TE as well as mechanisms used to configure, control, and report OAM within TE networks. YANG and MIB modules may be considered. The TEAS working group is chartered to deliver the following: 1. Definition of additional abstract service, link, and path properties such as jitter, delay, and diversity. Extensions to IGPs to advertise these properties, and extensions to RSVP-TE to request and to accumulate these properties. Work with PCE WG to include these properties in computation requests. 2. Specification of terminology, architecture, and protocol requirements for abstraction and distribution of TE information between interconnected TE domains/layers. 3. Specification and protocol extensions for a GMPLS External Network-to-Network Interface (E-NNI), i.e., multi-domain GMPLS support. 4. Protocol mechanisms to signal associated LSPs in particular with different source nodes. 5. Requirements and protocol extensions for additional protection mechanisms including, for example, end-point protection, protection of P2MP LSPs, and inter-domain protection. 6. YANG models in support of Traffic Engineering, in coordination with working groups working on YANG models for network topology and for technology-specific network attributes. Requirements may be documented in stand-alone RFCs, may be folded into architecture or solutions RFCs, may be recorded on a wiki, or may be documented in an Internet-Draft that is not progressed to RFC. The TEAS WG will coordinate with the following working groups: - With the MPLS WG to maintain and extend MPLS-TE protocol mechanisms and to determine whether they should be generalized. - With the CCAMP WG to maintain and extend non-packet, data plane technology-specific TE protocol mechanisms and to determine whether they should be generalized. - With the LSR (OSPF and ISIS) WG to maintain or extend TE routing mechanisms. - With the PCE WG on uses of a PCE in the traffic-engineering architecture, on PCE extensions per the above, and on RSVP-TE extensions to support PCE WG identified requirements. - With the IDR WG on the use of BGP-LS in TE environments. - With the DetNet WG on mechanisms (YANG models and protocols) to support DetNets. - With the SPRING WG on TE architecture and, where appropriate, TE-related protocol extensions. - With the SFC WG on mechanisms (YANG models and protocols) to support SFCs In doing this work, the WG will cooperate with external SDOs (such as the ITU-T and the IEEE 802.1) as necessary. Goals and Milestones: Dec 2018 - Revisit WG status (close if no milestones/deliverables) Apr 2019 - Submit metric recording to IESG for publication Apr 2019 - Submit TE LSP Yang Models to IESG for publication Sep 2019 - Submit RSVP(-TE) Yang Models to (base and MPLS) IESG for publication Oct 2019 - Submit SR&L3 TE Topology Yang Models to IESG for publication Nov 2019 - Submit TE Yang Models informational document to IESG for publication Nov 2019 - Submit PCECC and Native IP documents to IESG for publication Dec 2019 - Submit ACTN YANG Models to IESG for publication Dec 2019 - Submit RMR specific RSVP document(s) to IESG for publication Jan 2020 - Submit SF Aware TE Topology YANG Model to IESG for publication Internet-Drafts: - Implementation Recommendations to Improve the Scalability of RSVP-TE Deployments [draft-beeram-teas-rsvp-te-scaling-rec-00] (11 pages) - Realizing Network Slices in IP/MPLS Networks [draft-bestbar-teas-ns-packet-10] (31 pages) - YANG Data Model for Topology Filter [draft-bestbar-teas-yang-topology-filter-05] (17 pages) - SF Aware TE Topology YANG Model [draft-bryskin-teas-sf-aware-topo-model-01] (27 pages) - TE Topology and Tunnel Modeling for Transport Networks [draft-bryskin-teas-te-topo-and-tunnel-modeling-01] (105 pages) - Use Cases for SF Aware Topology Models [draft-bryskin-teas-use-cases-sf-aware-topo-model-03] (18 pages) - Yang model for requesting Path Computation [draft-busibel-teas-yang-path-computation-03] (44 pages) - Profiles for Traffic Engineering (TE) Topology Data Model and Applicability to non-TE Use Cases [draft-busi-teas-te-topology-profiles-08] (15 pages) - Updated Common YANG Data Types for Traffic Engineering [draft-busi-teas-te-types-update-02] (78 pages) - A YANG Data Model for MPLS-TE Topology [draft-busizheng-teas-yang-te-mpls-topology-06] (18 pages) - IETF Network Slice Controller and its associated data models [draft-contreras-teas-slice-controller-models-05] (12 pages) - IETF Network Slice Use Cases and Attributes for Northbound Interface of IETF Network Slice Controllers [draft-contreras-teas-slice-nbi-06] (28 pages) - RSVP Extensions for RMR [draft-deshmukh-teas-rsvp-rmr-extension-00] (15 pages) - A Framework for Enhanced Virtual Private Networks (VPN+) Service [draft-dong-teas-enhanced-vpn-03] (36 pages) - Scalability Considerations for Network Resource Partition [draft-dong-teas-nrp-scalability-02] (18 pages) - Overview and Principles of Internet Traffic Engineering [draft-dt-teas-rfc3272bis-11] (77 pages) - IETF Network Slice Application in 3GPP 5G End-to-End Network Slice [draft-gcdrb-teas-5g-network-slice-application-02] (44 pages) - GMPLS Signaling Extensions for Shared Mesh Protection [draft-he-teas-gmpls-signaling-smp-00] (9 pages) - RSVP-TE Signaling Procedure for GMPLS Restoration and Resource Sharing- based LSP Setup and Teardown [draft-ietf-ccamp-gmpls-resource-sharing-proc-00] (19 pages) - Problem Statement and Architecture for Information Exchange Between Interconnected Traffic Engineered Networks [draft-ietf-ccamp-interconnected-te-info-exchange-01] (56 pages) - LSP Attribute in ERO [draft-ietf-ccamp-lsp-attribute-ro-05] (12 pages) - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Route [draft-ietf-ccamp-lsp-diversity-05] (27 pages) - RSVP-TE Extensions for Associated Bidirectional LSPs [draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-11] (18 pages) - Network Assigned Upstream-Label [draft-ietf-ccamp-network-assigned-upstream-label-00] (9 pages) - Domain Subobjects for Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) [draft-ietf-ccamp-rsvp-te-domain-subobjects-02] (17 pages) - GMPLS RSVP-TE Extensions for Lock Instruct and Loopback [draft-ietf-ccamp-rsvp-te-li-lb-06] (9 pages) - RSVP-TE Extensions for Collecting SRLG Information [draft-ietf-ccamp-rsvp-te-srlg-collect-09] (13 pages) - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extension for recording TE Metric of a Label Switched Path [draft-ietf-ccamp-te-metric-recording-04] (15 pages) - Extensions to Resource Reservation Protocol For Re-optimization of Loosely Routed Point-to-Multipoint Traffic Engineering LSPs [draft-ietf-mpls-p2mp-loose-path-reopt-01] (15 pages) - Extensions to RSVP-TE for LSP Egress Local Protection [draft-ietf-mpls-rsvp-egress-protection-02] (16 pages) - Extensions to RSVP-TE for LSP Ingress Local Protection [draft-ietf-mpls-rsvp-ingress-protection-02] (23 pages) - IETF Network Slice Application in 3GPP 5G End-to-End Network Slice [draft-ietf-teas-5g-network-slice-application-03] (68 pages) - A Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies [draft-ietf-teas-5g-ns-ip-mpls-10] (73 pages) - Framework for Abstraction and Control of TE Networks (ACTN) [draft-ietf-teas-actn-framework-15] (42 pages) - Information Model for Abstraction and Control of TE Networks (ACTN) [draft-ietf-teas-actn-info-model-10] (23 pages) - YANG models for Virtual Network (VN)/TE Performance Monitoring Telemetry and Scaling Intent Autonomics [draft-ietf-teas-actn-pm-telemetry-autonomics-12] (40 pages) - Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI) [draft-ietf-teas-actn-poi-applicability-12] (72 pages) - Requirements for Abstraction and Control of TE Networks [draft-ietf-teas-actn-requirements-09] (12 pages) - A YANG Data Model for Virtual Network (VN) Operations [draft-ietf-teas-actn-vn-yang-29] (56 pages) - Applicability of YANG models for Abstraction and Control of Traffic Engineered Networks [draft-ietf-teas-actn-yang-11] (19 pages) - Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to IETF Network Slicing [draft-ietf-teas-applicability-actn-slicing-10] (25 pages) - Updates to the Fast Reroute Procedures for Co-routed Associated Bidirectional Label Switched Paths (LSPs) [draft-ietf-teas-assoc-corouted-bidir-frr-07] (16 pages) - A Framework for Network Resource Partition (NRP) based Enhanced Virtual Private Networks [draft-ietf-teas-enhanced-vpn-20] (44 pages) - Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs) [draft-ietf-teas-fast-lsps-requirements-02] (9 pages) - Interworking of GMPLS Control and Centralized Controller Systems [draft-ietf-teas-gmpls-controller-inter-work-17] (33 pages) - Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs) [draft-ietf-teas-gmpls-lsp-fastreroute-12] (24 pages) - RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing [draft-ietf-teas-gmpls-resource-sharing-proc-08] (15 pages) - Generalized SCSI: A Generic Structure for Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI) [draft-ietf-teas-gmpls-scsi-04] (7 pages) - GMPLS Signaling Extensions for Shared Mesh Protection [draft-ietf-teas-gmpls-signaling-smp-12] (13 pages) - Definition of IETF Network Slices [draft-ietf-teas-ietf-network-slice-definition-01] (17 pages) - Framework for IETF Network Slices [draft-ietf-teas-ietf-network-slice-framework-00] (18 pages) - A YANG Data Model for the RFC 9543 Network Slice Service [draft-ietf-teas-ietf-network-slice-nbi-yang-16] (120 pages) - A Framework for Network Slices in Networks Built from IETF Technologies [draft-ietf-teas-ietf-network-slices-25] (54 pages) - IETF Network Slice Use Cases and Attributes for the Slice Service Interface of IETF Network Slice Controllers [draft-ietf-teas-ietf-network-slice-use-cases-01] (29 pages) - Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks [draft-ietf-teas-interconnected-te-info-exchange-07] (67 pages) - Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO) [draft-ietf-teas-lsp-attribute-ro-05] (15 pages) - RSVP-TE Path Diversity Using Exclude Route [draft-ietf-teas-lsp-diversity-10] (26 pages) - RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs) [draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07] (20 pages) - Scenarios and Simulation Results of PCE in a Native IP Network [draft-ietf-teas-native-ip-scenarios-12] (16 pages) - Network-Assigned Upstream Label [draft-ietf-teas-network-assigned-upstream-label-12] (10 pages) - Scalability Considerations for Network Resource Partition [draft-ietf-teas-nrp-scalability-05] (26 pages) - YANG Data Models for Network Resource Partitions (NRPs) [draft-ietf-teas-nrp-yang-02] (47 pages) - IETF Network Slice Controller and its associated data models [draft-ietf-teas-ns-controller-models-02] (13 pages) - Realizing Network Slices in IP/MPLS Networks [draft-ietf-teas-ns-ip-mpls-04] (32 pages) - RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs) [draft-ietf-teas-p2mp-loose-path-reopt-09] (17 pages) - Use Cases for a PCE as a Central Controller (PCECC) [draft-ietf-teas-pcecc-use-cases-18] (45 pages) - An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control [draft-ietf-teas-pce-central-control-05] (25 pages) - PCE-Based Traffic Engineering (TE) in Native IP Networks [draft-ietf-teas-pce-native-ip-17] (12 pages) - Overview and Principles of Internet Traffic Engineering [draft-ietf-teas-rfc3272bis-27] (95 pages) - Common YANG Data Types for Traffic Engineering [draft-ietf-teas-rfc8776-update-12] (193 pages) - Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection [draft-ietf-teas-rsvp-egress-protection-16] (21 pages) - Extensions to RSVP-TE for Label Switched Path (LSP) Ingress Fast Reroute (FRR) Protection [draft-ietf-teas-rsvp-ingress-protection-17] (28 pages) - RSVP Extensions for RMR [draft-ietf-teas-rsvp-rmr-extension-03] (15 pages) - Domain Subobjects for Resource Reservation Protocol - Traffic Engineering (RSVP-TE) [draft-ietf-teas-rsvp-te-domain-subobjects-05] (18 pages) - GMPLS RSVP-TE Extensions for Lock Instruct and Loopback [draft-ietf-teas-rsvp-te-li-lb-05] (9 pages) - Techniques to Improve the Scalability of RSVP-TE Deployments [draft-ietf-teas-rsvp-te-scaling-rec-09] (11 pages) - RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information [draft-ietf-teas-rsvp-te-srlg-collect-08] (16 pages) - Framework for Scheduled Use of Resources [draft-ietf-teas-scheduled-resources-07] (22 pages) - SF Aware TE Topology YANG Model [draft-ietf-teas-sf-aware-topo-model-13] (57 pages) - Recommendations for RSVP-TE and Segment Routing (SR) Label Switched Path (LSP) Coexistence [draft-ietf-teas-sr-rsvp-coexistence-rec-04] (12 pages) - Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions [draft-ietf-teas-te-express-path-05] (10 pages) - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extension for recording TE Metric of a Label Switched Path [draft-ietf-teas-te-metric-recording-09] (17 pages) - Traffic Engineering (TE) and Service Mapping YANG Data Model [draft-ietf-teas-te-service-mapping-yang-15] (56 pages) - TE Topology and Tunnel Modeling for Transport Networks [draft-ietf-teas-te-topo-and-tunnel-modeling-06] (109 pages) - Profiles for Traffic Engineering (TE) Topology Data Model and Applicability to non-TE Use Cases [draft-ietf-teas-te-topology-profiles-01] (17 pages) - Use Cases for SF Aware Topology Models [draft-ietf-teas-use-cases-sf-aware-topo-model-00] (18 pages) - YANG Data Model for Layer 3 TE Topologies [draft-ietf-teas-yang-l3-te-topo-18] (79 pages) - A YANG Data Model for requesting path computation [draft-ietf-teas-yang-path-computation-23] (95 pages) - A YANG Data Model for Resource Reservation Protocol (RSVP) [draft-ietf-teas-yang-rsvp-19] (54 pages) - A YANG Data Model for RSVP-TE Protocol [draft-ietf-teas-yang-rsvp-te-09] (41 pages) - YANG Data Model for SR and SR TE Topologies on MPLS Data Plane [draft-ietf-teas-yang-sr-te-topo-19] (54 pages) - A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths and Interfaces [draft-ietf-teas-yang-te-36] (100 pages) - A YANG Data Model for MPLS Traffic Engineering Tunnels [draft-ietf-teas-yang-te-mpls-04] (21 pages) - A YANG Data Model for MPLS-TE Topology [draft-ietf-teas-yang-te-mpls-topology-00] (18 pages) - YANG Data Model for Traffic Engineering (TE) Topologies [draft-ietf-teas-yang-te-topo-22] (170 pages) - Common YANG Data Types for Traffic Engineering [draft-ietf-teas-yang-te-types-13] (84 pages) - Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Network Slicing [draft-king-teas-applicability-actn-slicing-10] (22 pages) - YANG models for VN & TE Performance Monitoring Telemetry and Scaling Intent Autonomics [draft-lee-teas-actn-pm-telemetry-autonomics-17] (30 pages) - Requirements for Abstraction and Control of Transport Networks [draft-lee-teas-actn-requirements-01] (22 pages) - A Yang Data Model for ACTN VN Operation [draft-lee-teas-actn-vn-yang-13] (53 pages) - Traffic Engineering and Service Mapping Yang Model [draft-lee-teas-te-service-mapping-yang-13] (28 pages) - YANG Data Model for Layer 3 TE Topologies [draft-liu-teas-yang-l3-te-topo-05] (37 pages) - YANG Data Model for SR and SR TE Topologies [draft-liu-teas-yang-sr-te-topo-04] (16 pages) - YANG Data Model for TE Topologies [draft-liu-teas-yang-te-topo-01] (50 pages) - Framework for IETF Network Slices [draft-nsdt-teas-ns-framework-05] (18 pages) - IETF Definition of Transport Slice [draft-nsdt-teas-transport-slice-definition-04] (19 pages) - Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI) [draft-peru-teas-actn-poi-applicability-05] (36 pages) - A YANG Data Model for Resource Reservation Protocol (RSVP) [draft-saad-teas-yang-rsvp-02] (66 pages) - A YANG Data Model for Traffic Engineering Tunnels and Interfaces [draft-saad-teas-yang-te-02] (84 pages) - Recommendations for RSVP-TE and Segment Routing LSP co-existence [draft-sitaraman-sr-rsvp-coexistence-rec-02] (10 pages) - A Realization of IETF Network Slices for 5G Networks Using Current IP/ MPLS Technologies [draft-srld-teas-5g-slicing-09] (72 pages) - CCDR Scenario, Simulation and Suggestion [draft-wang-teas-ccdr-05] (12 pages) - PCE in Native IP Network [draft-wang-teas-pce-native-ip-07] (11 pages) - A YANG Data Model for Network Resource Partitions (NRPs) [draft-wdbsp-teas-nrp-yang-04] (41 pages) - IETF Network Slice Service YANG Model [draft-wd-teas-ietf-network-slice-nbi-yang-05] (49 pages) - Applicability of YANG models for Abstraction and Control of Traffic Engineered Networks [draft-zhang-teas-actn-yang-05] (17 pages) - An Architecture for Use of PCE and PCEP in a Network with Central Control [draft-zhao-teas-pce-control-function-01] (21 pages) - Interworking of GMPLS Control and Centralized Controller System [draft-zheng-teas-gmpls-controller-inter-work-03] (14 pages) Requests for Comments: RFC7551: RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs) (20 pages) * Updates RFC8537 RFC7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO) (15 pages) RFC7571: GMPLS RSVP-TE Extensions for Lock Instruct and Loopback (9 pages) RFC7709: Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs) (9 pages) RFC7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions (10 pages) RFC7898: Domain Subobjects for Resource Reservation Protocol - Traffic Engineering (RSVP-TE) (18 pages) RFC7926: Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks (67 pages) RFC8001: RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information (16 pages) RFC8131: RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing (15 pages) RFC8149: RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs) (17 pages) RFC8258: Generalized SCSI: A Generic Structure for Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI) (7 pages) RFC8271: Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs) (24 pages) RFC8283: An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control (25 pages) RFC8359: Network-Assigned Upstream Label (10 pages) RFC8370: Techniques to Improve the Scalability of RSVP-TE Deployments (11 pages) RFC8390: RSVP-TE Path Diversity Using Exclude Route (26 pages) RFC8400: Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection (21 pages) RFC8413: Framework for Scheduled Use of Resources (22 pages) RFC8424: Extensions to RSVP-TE for Label Switched Path (LSP) Ingress Fast Reroute (FRR) Protection (28 pages) RFC8426: Recommendations for RSVP-TE and Segment Routing (SR) Label Switched Path (LSP) Coexistence (12 pages) RFC8453: Framework for Abstraction and Control of TE Networks (ACTN) (42 pages) RFC8454: Information Model for Abstraction and Control of TE Networks (ACTN) (23 pages) RFC8537: Updates to the Fast Reroute Procedures for Co-routed Associated Bidirectional Label Switched Paths (LSPs) (16 pages) RFC8735: Scenarios and Simulation Results of PCE in a Native IP Network (16 pages) RFC8776: Common YANG Data Types for Traffic Engineering (84 pages) RFC8795: YANG Data Model for Traffic Engineering (TE) Topologies (170 pages) RFC8821: PCE-Based Traffic Engineering (TE) in Native IP Networks (12 pages) RFC9270: GMPLS Signaling Extensions for Shared Mesh Protection (13 pages) RFC9522: Overview and Principles of Internet Traffic Engineering (73 pages) RFC9543: A Framework for Network Slices in Networks Built from IETF Technologies (44 pages) Time-Variant Routing (tvr) -------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Edward J. Birrane Tony Li Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Gunter Van de Velde Secretary: Adam Wiethuechter Mailing Lists: General Discussion: tvr@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tvr Archive: https://mailarchive.ietf.org/arch/browse/tvr/ Description of Working Group: Existing IETF routing protocols expect to maintain contemporaneous, end-to-end connected paths across a network. Changes to that connectivity, such as the loss of an adjacent peer, need the routing protocols to react to reduce the impact on the network traffic. However, a growing number of use cases exist where predicted variations (restoration, activation, or loss) to the topology are an expected part of normal network operations. For example, in networks with mobile nodes, such as aerial vehicles and some orbiting spacecraft constellations, links can be lost and re-established, or neighbors may change as a function of their mobility. Similarly, network traffic might be routed based on energy costs or expected user data volumes, which may vary predictably over time in networks prioritizing green computing and energy efficiency. In these cases, the predicted loss and restoration of an adjacency, or formation of an alternate adjacency, should be seen as non-disruptive events. Support for such use cases and expected changes in a routing system is called Time-Variant Routing (TVR). The Time-Variant Routing Working Group (TVR WG) is chartered to define information and data models that address time-based, scheduled changes to a network. Time-based changes may include changes to links, adjacencies, cost, and - in some cases - traffic volumes. The models are expected to satisfy the non-terrestrial networks' requirements as their main driver. Still, they should be general enough to encompass other types of networks and use cases. They should also be agnostic with respect to other control plane elements. The WG may also define terminology and concepts where needed, as well as address the impacts of a continually changing topology on the hierarchical structure of the network. The TVR WG will collaborate with groups working on non-terrestrial networks, including DTN, CCAMP, DETNET, RAW, and DRIP. In addition, the outputs from the WG will be provided to other working groups for consideration, which may use the material to incorporate time-variant attributes and behaviors into individual protocols. Specifically, the TVR WG will work on these items: (1) Problem Statement and Use cases This document (or set of documents) should include a description of the problem statement and related use cases to guide the remaining work. It exists to support the efforts of the Working Group and help newcomers, and it might not be published as an IETF Stream RFC. (2) Requirements This document should include definitions, requirements, notes, rationales, and examples. (3) Information Model This document (or set of documents) should describe the attributes needed, and the relationship between them, to enable routing and forwarding decisions in the presence of time-variant network parameters. (4) Data Model This document (or set of documents) should specify a YANG Data Model (or multiple modules), based on the Information Model, for configuration and monitoring. (5) Applicability Statement This document should provide an applicability statement on how the information and data models may be used, along with required ancillary IETF technology, to solve the use cases and requirements. (6) Implementation and Operational Considerations This document should provide advice and guidance to implementors and operators. Goals and Milestones: Feb 2024 - Use cases Oct 2024 - Requirements Mar 2025 - Data Model Nov 2025 - Applicability Statement Mar 2026 - Implementation and Operational Considerations Internet-Drafts: - TVR (Time-Variant Routing) Requirements [draft-ietf-tvr-requirements-04] (23 pages) - YANG Data Model for Scheduled Attributes [draft-ietf-tvr-schedule-yang-02] (22 pages) - TVR (Time-Variant Routing) Use Cases [draft-ietf-tvr-use-cases-09] (18 pages) No Requests for Comments Authentication and Authorization for Constrained Environments (ace) ------------------------------------------------------------------- Charter Last Modified: 2023-11-10 Current Status: Active Chairs: Loganaden Velvindron Tim Hollebeek Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Paul Wouters Mailing Lists: General Discussion: ace@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ace Archive: https://mailarchive.ietf.org/arch/browse/ace/ Description of Working Group: The Authentication and Authorization for Constrained Environments (ace) WG has defined a standardized solution framework for authentication and authorization to enable authorized access to resources identified by a URI and hosted on a resource server in constrained environments. The access to the resource is mediated by an authorization server, which is not considered to be constrained. Profiles of this framework for application to security protocols commonly used in constrained environments, including CoAP+DTLS and CoAP+OSCORE, have also been standardized. The Working Group is charged with maintenance of the framework and existing profiles thereof, and may undertake work to specify profiles of the framework for additional secure communications protocols and for additional support services providing authorized access to crypto keys (that are not necessarily limited to constrained endpoints, though the focus remains on deployment in ecosystems with a substantial portion of constrained devices). In addition to the ongoing maintenance work, the Working Group will extend the framework (originally designed to protect the exchange between single client and single RS) as needed for applicability to group communications. The initial focus will be on using (D)TLS and (Group) OSCORE as the underlying communication security protocols. The Working Group will standardize procedures for requesting and distributing group keying material using the ACE framework as well as appropriated management interfaces. The Working Group will standardize a format for expressing authorization information for a given authenticated principal as received from an authorization manager. The Working Group will examine how to use Constrained Application Protocol (CoAP) as a transport medium for certificate enrollment protocols, such as EST and CMPv2, as well as a transport for authentication protocols such as EAP (in coordination with the EMU WG), and standardize as needed. Goals and Milestones: Feb 2021 - Call for adoption of "Protecting EST Payloads with OSCORE" Jun 2021 - Submission to IESG of "CoAP Transport for CMPV2" (if adopted) Jul 2021 - Submission to the IESG of "An Authorization Information Format (AIF) for ACE" Jul 2021 - Submission to the IESG of "Protecting EST Payloads with OSCORE" Jul 2021 - Submission to the IESG of Pub-Sub Profile for Authentication and Authorization for Constrained Environments (ACE) Jul 2021 - Submission to the IESG of "Key Provisioning for Group Communication using ACE" Aug 2021 - Submission to the IESG of "EAP-based Authentication Service for CoAP" Sep 2021 - Submission to the IESG of "Key Management for OSCORE Groups in ACE" Dec 2021 - Submission to the IESG of "Admin Interface for the OSCORE Group Manager" Done - Adoption call for "CoAP Transport for CMPV2" Done - Submission to the IESG of "OSCORE Profile of the Authentication and Authorization for Constrained Environments Framework" Done - Adoption call of "EAP-based Authentication Service for CoAP" Done - Submit DTLS Profile for ACE to the IESG for publication as a proposed standard Internet-Drafts: - An Authorization Information Format (AIF) for ACE [draft-bormann-core-ace-aif-09] (11 pages) - An architecture for authorization in constrained environments [draft-ietf-ace-actors-07] (31 pages) - An Authorization Information Format (AIF) for Authentication and Authorization for Constrained Environments (ACE) [draft-ietf-ace-aif-07] (14 pages) - CBOR Web Token (CWT) [draft-ietf-ace-cbor-web-token-15] (25 pages) - Constrained Application Protocol (CoAP) Transfer for the Certificate Management Protocol [draft-ietf-ace-cmpv2-coap-transport-10] (9 pages) - EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol [draft-ietf-ace-coap-est-18] (41 pages) - Protecting EST Payloads with OSCORE [draft-ietf-ace-coap-est-oscore-05] (24 pages) - Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) [draft-ietf-ace-cwt-proof-of-possession-11] (14 pages) - Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) [draft-ietf-ace-dtls-authorize-18] (23 pages) - Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE) [draft-ietf-ace-edhoc-oscore-profile-05] (64 pages) - Extension of the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) to Transport Layer Security (TLS) [draft-ietf-ace-extend-dtls-authorize-07] (6 pages) - The Group Object Security for Constrained RESTful Environments (Group OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework [draft-ietf-ace-group-oscore-profile-02] (48 pages) - Key Provisioning for Group Communication using ACE [draft-ietf-ace-key-groupcomm-19] (124 pages) - Key Management for OSCORE Groups in ACE [draft-ietf-ace-key-groupcomm-oscore-16] (104 pages) - Message Queuing Telemetry Transport (MQTT) and Transport Layer Security (TLS) Profile of Authentication and Authorization for Constrained Environments (ACE) Framework [draft-ietf-ace-mqtt-tls-profile-17] (33 pages) - Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth) [draft-ietf-ace-oauth-authz-46] (72 pages) - Additional OAuth Parameters for Authentication and Authorization for Constrained Environments (ACE) [draft-ietf-ace-oauth-params-16] (11 pages) - Admin Interface for the OSCORE Group Manager [draft-ietf-ace-oscore-gm-admin-12] (84 pages) - Using the Constrained RESTful Application Language (CoRAL) with the Admin Interface for the OSCORE Group Manager [draft-ietf-ace-oscore-gm-admin-coral-02] (30 pages) - The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework [draft-ietf-ace-oscore-profile-19] (28 pages) - Publish-Subscribe Profile for Authentication and Authorization for Constrained Environments (ACE) [draft-ietf-ace-pubsub-profile-10] (56 pages) - Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework [draft-ietf-ace-revoked-token-notification-08] (75 pages) - Use Cases for Authentication and Authorization in Constrained Environments [draft-ietf-ace-usecases-10] (30 pages) - EAP-based Authentication Service for CoAP [draft-ietf-ace-wg-coap-eap-10] (38 pages) - Alternative Workflow and OAuth Parameters for the Authentication and Authorization for Constrained Environments (ACE) Framework [draft-ietf-ace-workflow-and-params-02] (52 pages) - CoAP Pub-Sub Profile for Authentication and Authorization for Constrained Environments (ACE) [draft-palombini-ace-coap-pubsub-profile-06] (19 pages) - Key Provisioning for Group Communication using ACE [draft-palombini-ace-key-groupcomm-02] (17 pages) - MQTT-TLS profile of ACE [draft-sengul-ace-mqtt-tls-profile-04] (23 pages) - Key Management for OSCORE Groups in ACE [draft-tiloca-ace-oscoap-joining-05] (17 pages) - Admin Interface for the OSCORE Group Manager [draft-tiloca-ace-oscore-gm-admin-02] (29 pages) - EST over secure CoAP (EST-coaps) [draft-vanderstok-ace-coap-est-04] (30 pages) Requests for Comments: RFC7744: Use Cases for Authentication and Authorization in Constrained Environments (30 pages) RFC8392: CBOR Web Token (CWT) (25 pages) RFC8747: Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) (14 pages) RFC9148: EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol (41 pages) RFC9200: Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth) (72 pages) RFC9201: Additional OAuth Parameters for Authentication and Authorization for Constrained Environments (ACE) (11 pages) RFC9202: Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) (23 pages) * Updates RFC9430 RFC9203: The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework (28 pages) RFC9237: An Authorization Information Format (AIF) for Authentication and Authorization for Constrained Environments (ACE) (14 pages) RFC9430: Extension of the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) to Transport Layer Security (TLS) (6 pages) RFC9431: Message Queuing Telemetry Transport (MQTT) and Transport Layer Security (TLS) Profile of Authentication and Authorization for Constrained Environments (ACE) Framework (33 pages) RFC9482: Constrained Application Protocol (CoAP) Transfer for the Certificate Management Protocol (9 pages) RFC9594: Key Provisioning for Group Communication Using Authentication and Authorization for Constrained Environments (ACE) (97 pages) Automated Certificate Management Environment (acme) --------------------------------------------------- Charter Last Modified: 2024-03-21 Current Status: Active Chairs: Tomofumi Okubo Yoav Nir Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Deb Cooley Mailing Lists: General Discussion: acme@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/acme Archive: https://mailarchive.ietf.org/arch/browse/acme/ Description of Working Group: Historically, issuance of certificates for Internet applications (e.g., web servers) has involved many manual identity validation steps by the certification authority (CA). The ACME WG will specify conventions for automated X.509 certificate management, including validation of control over an identifier, certificate issuance, certificate renewal, and certificate revocation. The initial focus of the ACME WG will be on domain name certificates (as used by web servers), but other uses of certificates can be considered as work progresses. ACME certificate management must allow the CA to verify, in an automated manner, that the party requesting a certificate has authority over the requested identifiers, including the subject and subject alternative names. The processing must also confirm that the requesting party has access to the private key that corresponds to the public key that will appear in the certificate. All of the processing must be done in a manner that is compatible with common service deployment environments, such as hosting environments. ACME certificate management must, in an automated manner, allow an authorized party to request revocation of a certificate. The ACME working group is specifying ways to automate certificate issuance, validation, revocation and renewal. The ACME working group is not reviewing or producing certificate policies or practices. The starting point for ACME WG discussions shall be draft-barnes-acme. Goals and Milestones: Apr 2024 - Delay-Tolerant Networking (DTN) extensions submitted to IESG Jul 2024 - End user client and code signing certificates extension submitted to IESG or abandoned Nov 2024 - Send draft-ietf-acme-dns-account-challenge to the IESG for standards track publication Nov 2024 - Send draft-ietf-acme-onion the IESG for standards track publication Nov 2024 - Send Renewal Information Extension to the IESG for standards track publication Done - Initial working group draft Done - Submit working group draft to IESG as Proposed Standard Done - TNAuthlist extension submitted to IESG Done - S/MIME extension submitted to IESG Done - Profile for delegated STAR certificates submitted to IESG Done - ACME integration with with EST, BRSKI and TEAP use cases submitted to IESG Internet-Drafts: - Automated Certificate Management Environment (ACME) Device Attestation Extension [draft-acme-device-attest-03] (13 pages) - Automatic Certificate Management Environment (ACME) [draft-ietf-acme-acme-18] (95 pages) - Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension [draft-ietf-acme-ari-05] (11 pages) - Automated Certificate Management Environment (ACME) Challenges Using an Authority Token [draft-ietf-acme-authority-token-09] (11 pages) - TNAuthList Profile of Automated Certificate Management Environment (ACME) Authority Token [draft-ietf-acme-authority-token-tnauthlist-13] (15 pages) - Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding [draft-ietf-acme-caa-10] (11 pages) - ACME End User Client and Code Signing Certificates [draft-ietf-acme-client-07] (14 pages) - Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge [draft-ietf-acme-dns-account-01-01] (8 pages) - Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge [draft-ietf-acme-dns-account-challenge-01] (8 pages) - Automated Certificate Management Environment (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension [draft-ietf-acme-dtnnodeid-14] (31 pages) - Extensions to Automatic Certificate Management Environment for End-User S/MIME Certificates [draft-ietf-acme-email-smime-14] (12 pages) - Extensions to Automatic Certificate Management Environment for email TLS [draft-ietf-acme-email-tls-05] (8 pages) - ACME Integrations for Device Certificate Enrollment [draft-ietf-acme-integrations-17] (23 pages) - Automated Certificate Management Environment (ACME) IP Identifier Validation Extension [draft-ietf-acme-ip-08] (5 pages) - Automated Certificate Management Environment (ACME) Extensions for ".onion" Special-Use Domain Names [draft-ietf-acme-onion-03] (20 pages) - Automated Certificate Management Environment (ACME) Scoped DNS Challenges [draft-ietf-acme-scoped-dns-challenges-01] (12 pages) - ACME Identifiers and Challenges for VoIP Service Providers [draft-ietf-acme-service-provider-02] (9 pages) - Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME) [draft-ietf-acme-star-11] (22 pages) - An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates [draft-ietf-acme-star-delegation-09] (42 pages) - Automated Certificate Management Environment (ACME) for Subdomains [draft-ietf-acme-subdomains-07] (20 pages) - ACME Identifiers and Challenges for Telephone Numbers [draft-ietf-acme-telephone-01] (8 pages) - Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension [draft-ietf-acme-tls-alpn-07] (8 pages) - CA Account URI Binding for CAA Records [draft-landau-acme-caa-01] (8 pages) - ACME End User Client and Code Signing Certificates [draft-moriarty-acme-client-05] (14 pages) - Automated Certificate Management Environment (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension [draft-sipos-acme-dtnnodeid-01] (16 pages) Requests for Comments: RFC8555: Automatic Certificate Management Environment (ACME) (95 pages) RFC8657: Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding (11 pages) RFC8737: Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension (8 pages) RFC8738: Automated Certificate Management Environment (ACME) IP Identifier Validation Extension (5 pages) RFC8739: Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME) (22 pages) RFC8823: Extensions to Automatic Certificate Management Environment for End-User S/MIME Certificates (12 pages) RFC9115: An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates (42 pages) RFC9444: Automated Certificate Management Environment (ACME) for Subdomains (20 pages) RFC9447: Automated Certificate Management Environment (ACME) Challenges Using an Authority Token (11 pages) RFC9448: TNAuthList Profile of Automated Certificate Management Environment (ACME) Authority Token (15 pages) CBOR Object Signing and Encryption (cose) ----------------------------------------- Charter Last Modified: 2022-03-23 Current Status: Active Chairs: Ivaylo Petrov Matthew A. Miller Michael B. Jones Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Paul Wouters Mailing Lists: General Discussion: cose@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cose Archive: https://mailarchive.ietf.org/arch/browse/cose/ Description of Working Group: CBOR Object Signing and Encryption (COSE, RFC 8152) describes how to create and process signatures, message authentication codes, and encryption using Concise Binary Object Representation (CBOR, RFC 7049) for serialization. COSE additionally describes a representation for cryptographic keys. COSE has been picked up and is being used both by a number of groups within the IETF (i.e., ACE, CORE, ANIMA, 6TiSCH and SUIT) and outside the IETF (i.e., W3C and FIDO). There are a number of implementations, both open source and private, now in existence. The specification has advanced to STD status. The COSE working group will deal with two types of documents going forward: 1. Documents that describe the use of cryptographic algorithms in COSE. 2. Documents which describe additional attributes for COSE. The WG will evaluate, and potentially adopt, documents dealing with algorithms that would fit the criteria of being IETF consensus algorithms. Potential candidates would include those algorithms that have been evaluated by the CFRG and algorithms which have gone through a public review and evaluation process such as was done for the NIST SHA-3 algorithms. Potential candidates would not include national-standards-based algorithms that have not gone through a similar public review process. The WG will produce documents for new attributes only if they are in the list of deliverables below. A re-charter will be required to expand that list. The WG is expected as part of normal processing to review and comment on attributes that are not in charter but are of general public interest. Key management and binding of keys to identities are out of scope for the working group. The COSE WG will not innovate in terms of cryptography. The specification of algorithms in COSE is limited to those in RFCs, active CFRG or IETF WG documents, or algorithms which have been positively reviewed by the CFRG. The working group will coordinate its progress with the ACE, SUIT and CORE working groups to ensure that it is fulfilling the needs of these constituencies to the extent relevant to their work. Other groups may be added to this list as the set of use cases is expanded, in consultation with the responsible Area Director. The WG currently has two work items: 1. One or more documents describing the proper use of algorithms. These algorithms must meet the requirements outlined above. 2. A CBOR encoding of the certificate profile defined in RFC 5280. It is expected that the encoding works with RFC 7925 and takes into consideration any updates in draft-ietf-uta-tls13-iot-profile-00. The encoding may also include other important IoT certificate profiles like IEEE 802.1AR. The main objective is to define a method of encoding current X.509 certificates that meet a specific profile into a smaller format. This encoding is invertible, so they can be expanded and normal X.509 certificate processing can be used. The data structures used for such encoding of X.509 certificates are expected to produce a compact encoding for certificate information, and are not necessarily tied specifically to X.509 certificates. Accordingly, a secondary objective is to reuse these data structures to produce a natively signed CBOR certificate encoding; such a structure is relevant in situations where DER parsing and the machinery to convert between CBOR and DER encodings are unnecessary overhead, such as embedded implementations. The possibility of a joint certificate artifact, conveyed in CBOR encoding but including signatures over both the CBOR and DER encodings, may be explored. CBOR encoding of other X.509 certificate related data structures may also be specified to support relevant functions such as revocation: Certificate Revocation List (RFC 5280) or OSCP Request/Response (RFC 6960); or certificate enrollment: Certificate Signing Request (RFC 2986). draft-mattsson-cose-cbor-cert-compress is expected to be a good starting point for this work. The working group will collaborate and coordinate with other IETF WGs such as TLS, UTA, LAKE to understand and validate the requirements and solution. Goals and Milestones: Jun 2021 - Adopt draft for compressed certificate encoding as a Working Group item Dec 2021 - Submit draft for compressed certificate encoding to the IESG for publication Internet-Drafts: - CBOR Object Signing and Encryption (COSE): AES-CTR and AES-CBC [draft-ietf-cose-aes-ctr-and-cbc-06] (10 pages) - Barreto-Lynn-Scott Elliptic Curve Key Representations for JOSE and COSE [draft-ietf-cose-bls-key-representations-05] (22 pages) - CBOR Encoded X.509 Certificates (C509 Certificates) [draft-ietf-cose-cbor-encoded-cert-11] (73 pages) - CBOR Object Signing and Encryption (COSE): Countersignatures [draft-ietf-cose-countersign-10] (18 pages) - CBOR Web Token (CWT) Claims in COSE Headers [draft-ietf-cose-cwt-claims-in-headers-10] (8 pages) - ML-DSA for JOSE and COSE [draft-ietf-cose-dilithium-03] (13 pages) - JOSE and COSE Encoding for Falcon [draft-ietf-cose-falcon-01] (15 pages) - CBOR Object Signing and Encryption (COSE): Hash Algorithms [draft-ietf-cose-hash-algs-09] (9 pages) - COSE Hash Envelope [draft-ietf-cose-hash-envelope-00] (8 pages) - Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE) [draft-ietf-cose-hash-sig-09] (15 pages) - Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE) [draft-ietf-cose-hpke-09] (24 pages) - CBOR Object Signing and Encryption (COSE) Key Thumbprint [draft-ietf-cose-key-thumbprint-06] (13 pages) - COSE Receipts [draft-ietf-cose-merkle-tree-proofs-05] (24 pages) - CBOR Object Signing and Encryption (COSE) [draft-ietf-cose-msg-24] (121 pages) - JOSE and COSE Encoding for Post-Quantum Signatures [draft-ietf-cose-post-quantum-signatures-01] (60 pages) - CBOR Object Signing and Encryption (COSE): Initial Algorithms [draft-ietf-cose-rfc8152bis-algs-12] (41 pages) - CBOR Object Signing and Encryption (COSE): Structures and Process [draft-ietf-cose-rfc8152bis-struct-15] (66 pages) - SLH-DSA for JOSE and COSE [draft-ietf-cose-sphincs-plus-04] (13 pages) - COSE Header parameter for RFC 3161 Time-Stamp Tokens [draft-ietf-cose-tsa-tst-header-parameter-03] (10 pages) - COSE "typ" (type) Header Parameter [draft-ietf-cose-typ-header-parameter-05] (6 pages) - CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms [draft-ietf-cose-webauthn-algorithms-08] (10 pages) - CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates [draft-ietf-cose-x509-09] (12 pages) - CBOR Encoded Message Syntax [draft-schaad-cose-msg-01] (48 pages) Requests for Comments: RFC8152: CBOR Object Signing and Encryption (COSE) (121 pages) * Obsoletes RFC9052 * Obsoletes RFC9053 RFC8778: Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE) (15 pages) RFC8812: CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms (10 pages) RFC9052: CBOR Object Signing and Encryption (COSE): Structures and Process (66 pages) * Updates RFC9338 RFC9053: CBOR Object Signing and Encryption (COSE): Initial Algorithms (41 pages) RFC9054: CBOR Object Signing and Encryption (COSE): Hash Algorithms (9 pages) RFC9338: CBOR Object Signing and Encryption (COSE): Countersignatures (18 pages) RFC9360: CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates (12 pages) RFC9459: CBOR Object Signing and Encryption (COSE): AES-CTR and AES-CBC (10 pages) RFC9596: CBOR Object Signing and Encryption (COSE) "typ" (type) Header Parameter (5 pages) RFC9597: CBOR Web Token (CWT) Claims in COSE Headers (6 pages) DANE Authentication for Network Clients Everywhere (dance) ---------------------------------------------------------- Charter Last Modified: 2023-03-28 Current Status: Active Chairs: Joey Salazar Wes Hardaker Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Paul Wouters Mailing Lists: General Discussion: dance@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dance Archive: https://mailarchive.ietf.org/arch/browse/dance/ Description of Working Group: # Objective The DANE Authentication for Network Clients Everywhere (DANCE) WG seeks to extend DANE (RFC 6698) to encompass TLS client authentication using certificates or Raw Public Keys (RPK). # Problem Statement The process of establishing trust in public-key-authenticated identity typically involves the use of a Public Key Infrastructure (PKI), and a shared PKI root of trust between the parties exchanging public keys. A Certification Authority (CA) is one example of a root of trust for a PKI, which can be then used for establishing trust in certified public keys. The DNS namespace, together with DNSSEC, forms the most widely-recognized namespace and authenticated lookup mechanism on the Internet. DANE built on this authenticated lookup mechanism to enable public key-based TLS authentication which is resilient to impersonation, but only for TLS server identities. However, the DANE WG did not define authentication for TLS client identities. In response to the challenges related to ambiguity between identically named identities issued by different CAs, application owners frequently choose to onboard client identities to a single private PKI with a limited CA set that is specific to that vertical. This creates a silo effect where different parts of large deployments can not communicate. Examples of where DANCE could be useful includes SMTP transport client authentication, authentication of DNS authoritative server to server zone file transfers over TLS, authentication to DNS recursive servers, and Internet of Things (IoT) device identification. # Scope of work DANCE will specify the DANE-enabled TLS client authentication use cases and an architecture describing the primary components and interaction patterns. DANCE will define how DNS DANE records will represent client identities for TLS connections. DANCE will coordinate with the TLS working group to define any TLS protocol updates required to support client authentication using DANE. The DANCE scope of work will be initially limited to just TLS client authentication. Future work may include using client identifiers for other tasks including object security, or authenticating to other protocols. # Deliverables: * DANCE architecture and use cases (e.g., IoT, SMTP client, authentication to DNS services) document (9 months) * DANE client authentication and publication practices (6 months after architecture) * A TLS extension to indicate DANE identification capability and the client's DANE identity name (6 months after architecture) Goals and Milestones: Jul 2022 - DANCE architecture and use cases to WGLC (informational) Jan 2023 - DANE client authentication and publication practice to WGLC (PS) Jan 2023 - TLS extension to indicate DANE identification capability and the client's DANE identity name to WGLC (PS) Internet-Drafts: - TLS Client Authentication via DANE TLSA records [draft-huque-dane-client-cert-08] (9 pages) - TLS Extension for DANE Client Identity [draft-huque-tls-dane-clientid-06] (5 pages) - An Architecture for DNS-Bound Client and Sender Identities [draft-ietf-dance-architecture-06] (20 pages) - TLS Client Authentication via DANE TLSA records [draft-ietf-dance-client-auth-05] (10 pages) - TLS Extension for DANE Client Identity [draft-ietf-dance-tls-clientid-03] (5 pages) - An Architecture for DNS-Bound Client and Sender Identities [draft-wilson-dance-architecture-02] (14 pages) No Requests for Comments Detecting Unwanted Location Trackers (dult) ------------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Erica Olsen Sean Turner Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Deb Cooley Mailing Lists: General Discussion: unwanted-trackers@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/unwanted-trackers Archive: https://mailarchive.ietf.org/arch/browse/unwanted-trackers/ Description of Working Group: ## Background Location-tracking accessories provide numerous benefits to users (e.g., such as being able to find where they left their keys), but can also have security and privacy implications if used for malicious purposes. These accessories can be misused to track another person’s location without their knowledge. Three major subsystems of an accessory tracking system, i) crowd-sourcing network, ii) unwanted tracker detection, and iii) alerting, providing information about the accessory, and enabling the non-owner to find it, have interfaces that are relevant to unwanted tracking. These interfaces include: enrolling in the network, broadcasting an accessory’s presence, non-owner interface for querying information from the accessory, performing non-owner actions such as play sound, querying assets and disablement instructions, querying limited owner information, disabling the accessory, and detection and exclusion of nonconformant accessories. To address the threat of unwanted tracking, accessory manufacturers have developed independent solutions for protecting users from unwanted tracking. However, this requires users to know about the threat of unwanted tracking, download multiple apps, and constantly be checking for the threat of unwanted tracking. In order to build a scalable solution for detecting unwanted tracking, trackers require a consistent protocol and set of behaviors that will enable protection from unwanted tracking using any tracker. ## Goals The goal of the DULT WG is to standardize an application protocol for information exchange between location-tracking accessories and nearby devices, along with actions that these accessories and devices should take once unwanted tracking is detected. This protocol is intended to protect people against being unknowingly tracked. The intent of this WG is to make it easier for arbitrary devices to detect unwanted tracking by these accessories. The protocols and interactions between devices may be limited to certain states or modes, such as the accessory being separated from a paired/owner device. The working group will define privacy and security properties of its solution, including privacy and security protections for accessory owners when accessories are used appropriately, and evaluate the tradeoffs. The mechanisms specified by the WG will be designed to not create new vectors for user tracking. The WG's specified mechanisms and protocol design will be guided by an intent to: * Minimize hardware changes needed in tracking accessories to implement this protocol; and * Not preclude adoption by manufacturers of larger devices whose primary purpose is not location tracking, but have location tracking capabilities (e.g., headphones, bicycle, smartphone) ## Program of Work The WG is expected to: 1. Document the current state of the tracker accessory platforms and how these technologies work (with informational document(s)) 2. Develop a standards-track protocol ("DULT protocol") between tracking accessories and nearby devices, which will: * Specify requirements and a baseline algorithm for determination of unwanted tracking * Specify complete message formats for accessories to advertise their presence to nearby devices, for one or more underlying transports (e.g., Bluetooth, Near Field Communication, etc.) * Allow nearby devices to trigger behavior on an unwanted tracking accessory to aid in determining its physical location * Allow nearby devices to fetch additional information about a tracker accessory, including such things as tracker image asset(s) and physical disablement instructions * Define privacy and security requirements for all messages used for advertisement, interactions with crowdsourcing networks, and owners of accessories 3. Develop standards-track guidance that accessory manufacturers can implement to deter malicious use of tracking accessories and support the implementation of the WG-specified protocol which will * Include physical security considerations, such as user impact when device has been physically modified to diminish detectability and/or findability * Include considerations for protecting people that don't have a device capable of running a platform-based unwanted tracking detection system 4. Develop standards-track guidance for non-owner device platforms necessary to support implementation of the DULT protocol. The standards-track guidance described above will include mechanisms to ensure that devices that do not correctly implement or adhere to the DULT protocol can be detected and excluded from being trackable via crowdsourced location networks. These mechanisms will include considerations for addressing legacy trackers that cannot update to the DULT protocol. The WG will work with gender-based violence experts throughout development of the protocol. Additionally, before publishing the protocol the WG will: * Carry out a threat analysis and security analysis * Gather implementation experience The WG will not define requirements for interactions between accessory manufacturers and law enforcement. The focus of the WG will be on solving the use case of detecting small and not easily-discoverable accessories, supporting any functionality that is necessary for identifying and recognizing such accessories. Since most of the existing tracking accessories use Bluetooth, the DULT WG will coordinate as needed with the Bluetooth SIG and IETF 6lo WG. ### Milestones * By July 2025 submit an informational document about the state of tracker accessory platforms and how they work for publication * By July 2025 submit a standards document defining the protocol to detect and interact with unwanted tracker accessories for publication Goals and Milestones: Jul 2025 - Submit an informational document about the state of tracker accessory platforms and how they work for publication Jul 2025 - Submit a standards document defining the protocol to detect and interact with unwanted tracker accessories for publication Internet-Drafts: - Draft DULT Threat Model [draft-delano-dult-threat-model-00] (14 pages) - Detecting Unwanted Location Trackers Accessory Protocol [draft-ledvina-dult-accessory-protocol-00] (37 pages) No Requests for Comments EAP Method Update (emu) ----------------------- Charter Last Modified: 2022-07-25 Current Status: Active Chairs: Joseph A. Salowey Peter E. Yee Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Paul Wouters Mailing Lists: General Discussion: emu@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/emu Archive: https://mailarchive.ietf.org/arch/browse/emu Description of Working Group: The Extensible Authentication Protocol (EAP) [RFC3748] is a network access authentication framework used, for instance, in VPN and mobile networks. EAP itself is a simple protocol and actual authentication happens in EAP methods. Several EAP methods have been developed at the IETF and support for EAP exists in a broad set of devices. Previous larger EAP-related efforts at the IETF included rewriting the base EAP protocol specification and the development of several standards track EAP methods. EAP methods are generally based on existing security technologies such as Transport Layer Security (TLS) and mobile network Authentication and Key Agreement (AKA). Our understanding of security threats is continuously evolving. This has driven the evolution of several of these underlying technologies. As an example, IETF has standardized a new and improved version of TLS in RFC 8446. The group will therefore provide guidance and update EAP method specifications where necessary to enable the use of new versions of these underlying technologies. Out-of-band (OOB) refers to a separate communication channel independent of the primary in-band channel over which the actual network communication takes place. OOB channels are now used for authentication in a variety of protocols and devices (draft-ietf-oauth-device-flow-13, WhatsApp Web, etc.). Many users are accustomed to tapping NFC or scanning QR codes. However, EAP currently does not have any standard methods that support authentication based on OOB channels. The group will therefore work on an EAP method where authentication is based on an out-of-band channel between the peer and the server. EAP authentication is based on credentials available on the peer and the server. However, some EAP methods use credentials that are time or domain limited (such as EAP-POTP), and there may be a need for creating long term credentials for re-authenticating the peer in a more general context. The group will investigate minimal mechanisms with which limited-use EAP authentication credentials can be used for creating general-use long-term credentials. EDHOC (Ephemeral Diffie-Hellman Over COSE) is a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys that is suitable in constrained environments in which many of the existing EAP methods are not a good fit. EDHOC offers the useful properties of mutual authentication, forward secrecy, and identity protection. The group will accordingly produce a specification for an EAP method incorporating the EDHOC mechanism (RFC9628). While TLS-based EAP mechanisms provide strong channel protections, if the client does not authenticate and validate the server's credentials properly (possibly owing to a lack of provisioned information necessary to undertake that validation), an EAP mechanism running over TLS that relies on passwords is vulnerable to client credential theft, much the same as password authentication over plain TLS is. The FIDO Alliance and the W3C have developed a passwordless authentication scheme known as FIDO2, which combines elements of the W3C's WebAuthn and FIDO's CTAP standards. The group will devise an EAP method suitable for use with passwordless authentication schemes such as the CTAP2 version of FIDO2. In summary, the working group shall produce the following documents: * An update to enable the use of TLS 1.3 in the context of EAP-TLS (RFC 5216). This document will update the security considerations relating to EAP-TLS, document the implications of using new vs. old TLS versions. It will add any recently gained new knowledge on vulnerabilities and discuss the possible implications of pervasive surveillance. * Several EAP methods such EAP-TTLS and EAP-FAST use an outer TLS tunnel. Provide guidance or update the relevant specifications explaining how those EAP methods (PEAP/TTLS/TEAP) will work with TLS 1.3. This will also involve maintenance work based on errata found in published specifications (such as EAP-TEAP). * Define session identifiers for fast re-authentication for EAP-SIM, EAP-AKA, EAP-PEAP and EAP-AKA’. The lack of this definition is a recently discovered shortcoming in the original RFCs. * Update the EAP-AKA' specification (RFC 5448) to ensure that its capability to provide a cryptographic binding to network context stays in sync with updates to the referenced 3GPP specifications. The document will also contain any recently gained new knowledge on vulnerabilities or the possible implications of pervasive surveillance. * Gather experience regarding the use of large certificates and long certificate chains in the context of TLS based EAP methods, as some implementations and access networks may limit the number of EAP packet exchanges that can be handled. Document operational recommendations or other mitigation strategies to avoid issues. * Define a standard EAP method for mutual authentication between a peer and a server that is based on an out-of-band channel. The method itself should be independent of the underlying OOB channel and shall support a variety of OOB channels such as NFC, dynamically generated QR codes, audio, and visible light. * Define mechanisms by which EAP methods can support creation of long-term credentials for the peer based on initial limited-use credentials. * Develop an EAP method for use in constrained environments that wish to leverage the EDHOC key exchange mechanism. * Devise a passwordless EAP method that can incorporate use of CTAP2 or other similar authentication mechanism. The working group is expected to stay in close collaboration with the EAP deployment community, the TLS working group (for work on TLS based EAP methods), the FIDO Alliance, and the 3GPP security architecture group (for EAP-AKA' work). Goals and Milestones: May 2024 - WG adopts initial draft on an EAP method for use of EDHOC May 2024 - WG adopts initial draft on an EAP method for using FIDO CTAP2 May 2024 - WG adopts an ancillary draft on use of the eap.arpa domain for use in other EAP methods Internet-Drafts: - Perfect-Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' PFS) [draft-arkko-eap-aka-pfs-04] (25 pages) - Nimble out-of-band authentication for EAP (EAP-NOOB) [draft-aura-eap-noob-08] (62 pages) - The eap.arpa domain and EAP provisioning [draft-dekok-emu-eap-arpa-01] (14 pages) - EAP Session-Id Derivation [draft-dekok-emu-eap-session-id-01] (9 pages) - TLS-based EAP types and TLS 1.3 [draft-dekok-emu-tls-eap-types-02] (10 pages) - Bootstrapped TLS Authentication [draft-friel-tls-eap-dpp-05] (10 pages) - Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) [draft-ietf-emu-aka-pfs-12] (34 pages) - Bootstrapped TLS Authentication with Proof of Knowledge (TLS-POK) [draft-ietf-emu-bootstrapped-tls-06] (13 pages) - Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods [draft-ietf-emu-chbind-16] (31 pages) - Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding [draft-ietf-emu-crypto-bind-04] (19 pages) - The eap.arpa domain and EAP provisioning [draft-ietf-emu-eap-arpa-02] (18 pages) - Using the Extensible Authentication Protocol with Ephemeral Diffie-Hellman over COSE (EDHOC) [draft-ietf-emu-eap-edhoc-01] (23 pages) - EAP-FIDO [draft-ietf-emu-eap-fido-00] (38 pages) - Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method [draft-ietf-emu-eap-gpsk-17] (38 pages) - Nimble Out-of-Band Authentication for EAP (EAP-NOOB) [draft-ietf-emu-eap-noob-06] (51 pages) - Extensible Authentication Protocol (EAP) Session-Id Derivation for EAP Subscriber Identity Module (EAP-SIM), EAP Authentication and Key Agreement (EAP-AKA), and Protected EAP (PEAP) [draft-ietf-emu-eap-session-id-07] (7 pages) - EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3 [draft-ietf-emu-eap-tls13-21] (31 pages) - Handling Large Certificates and Long Certificate Chains in TLS-Based EAP Methods [draft-ietf-emu-eaptlscert-08] (12 pages) - Tunnel Extensible Authentication Protocol (TEAP) Version 1 [draft-ietf-emu-eap-tunnel-method-10] (101 pages) - Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method [draft-ietf-emu-eaptunnel-req-09] (23 pages) - Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA') [draft-ietf-emu-rfc5448bis-10] (40 pages) - Tunnel Extensible Authentication Protocol (TEAP) Version 1 [draft-ietf-emu-rfc7170bis-19] (110 pages) - TLS-Based Extensible Authentication Protocol (EAP) Types for Use with TLS 1.3 [draft-ietf-emu-tls-eap-types-13] (19 pages) - Using the Extensible Authentication Protocol with Ephemeral Diffie-Hellman over COSE (EDHOC) [draft-ingles-eap-edhoc-05] (22 pages) - EAP-FIDO [draft-janfred-eap-fido-02] (36 pages) - Handling Large Certificates and Long Certificate Chains in TLS-based EAP Methods [draft-ms-emu-eaptlscert-03] (10 pages) - The EAP-TLS Authentication Protocol [draft-simon-emu-rfc2716bis-13] (34 pages) Requests for Comments: RFC5216: The EAP-TLS Authentication Protocol (34 pages) * Updates RFC8996 * Updates RFC9190 RFC5433: Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method (38 pages) RFC6677: Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods (31 pages) RFC6678: Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method (23 pages) RFC7029: Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding (19 pages) RFC7170: Tunnel Extensible Authentication Protocol (TEAP) Version 1 (101 pages) * Updates RFC9427 RFC8940: Extensible Authentication Protocol (EAP) Session-Id Derivation for EAP Subscriber Identity Module (EAP-SIM), EAP Authentication and Key Agreement (EAP-AKA), and Protected EAP (PEAP) (7 pages) RFC9048: Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA') (40 pages) RFC9140: Nimble Out-of-Band Authentication for EAP (EAP-NOOB) (51 pages) RFC9190: EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3 (31 pages) RFC9191: Handling Large Certificates and Long Certificate Chains in TLS-Based EAP Methods (12 pages) RFC9427: TLS-Based Extensible Authentication Protocol (EAP) Types for Use with TLS 1.3 (19 pages) Grant Negotiation and Authorization Protocol (gnap) --------------------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Leif Johansson Yaron Sheffer Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Deb Cooley Mailing Lists: General Discussion: txauth@ietf.org To Subscribe: ​https://www.ietf.org/mailman/listinfo/txauth Archive: https://mailarchive.ietf.org/arch/browse/txauth/ Description of Working Group: This group is chartered to develop a fine-grained delegation protocol for authorization, API access, user identifiers, and identity assertions. The protocol will also allow the client to present unverified identifiers and verifiable assertions to the Authorization Server (AS) as part of its request. This protocol enables an authorizing party to delegate access to client software to use a Resource Server (RS) with this token. It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support authorizations scoped as narrowly as a single transaction, provide a clear framework for interaction among all parties involved in the protocol flow, and remove unnecessary dependence on a browser or user-agent for coordinating interactions. The delegation process will be acted upon by multiple parties in the protocol, each performing a specific role. The protocol will decouple the channels used by the protocol participants to communicate from the delegation channel, which happens directly between the client and the authorization server (in contrast with OAuth 2.0, which is initiated by the client redirecting the user’s browser). The protocol will include a means of specifying how the user can potentially be involved in an interactive fashion during the delegation process. The client and AS will use these interaction mechanisms to involve the user, as necessary, to make authorization decisions. This decoupling avoids many of the security concerns and technical challenges of OAuth 2.0 and provides a non-invasive path for supporting future types of clients and interaction channels. The group will define interoperability for this protocol between different parties, including - client and authorization server; - client and resource server; and - authorization server and resource server. The group will seek to minimize assumptions about the form of client applications, allowing for: - Fine-grained specification of access - Approval of AS attestation to identifiers and other identity claims - Approval of access to multiple resources and APIs in a single interaction - Multiple access tokens in a single request and response - AS-directed dispatch of access tokens to the appropriate RS - Separation between the party authorizing access and the party operating the client requesting access The group will define extension points for this protocol to allow for flexibility in areas including: - Cryptographic agility for keys, message signatures, and proof of possession - User interaction mechanisms including web and non-web methods - Mechanisms for conveying user, software, organization, and other information used in authorization decisions - Mechanisms for presenting tokens to resource