6lo 6man ace acme add anima asap asdf avtcore babel bess bfd bier bmwg bpf calext cats cbor ccamp ccwg cdni cellar core cose dance deleg detnet dhc dispatch dmarc dmm dnsop dnssd dprive drip dtn dult ecrit emailcore emu extra gendispatch green grow httpapi httpbis idr intarea iotops ippm ipsecme ivy jmap jose keytrans kitten lake lamps lisp lsr lsvr madinas mailmaint manet masque mboned mediaman mimi mlcodec mls modpod mops moq mpls netconf netmod nfsv4 nmop ntp nvo3 oauth ohai openpgp opsawg pals pce pim ppm pquip privacypass quic radext rats regext rift roll rtgwg satp savnet schc scim scitt scone secdispatch sidrops sipcore sml snac spice spring srv6ops sshm stir suit taps tcpm teas teep tictoc tls tsvwg tvr uta v6ops vcon webtrans wimse wish 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: 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 for draft-schoenw-6lo-lowpan-mib Done - WG decision on adoption of draft-mariager-6lowpan-v6over-dect-ule Done - WG LC for draft-ietf-6lo-btle Done - WG adoption call for draft-hong-6lo-ipv6-over-nfc 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) - Generic Address Assignment Option for 6LowPAN Neighbor Discovery [draft-ietf-6lo-nd-gaao-00] (17 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-02] (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-08] (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-06] (25 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-07] (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) - The IPv6 VPN Service Destination Option [draft-bonica-6man-vpn-dest-opt-26] (12 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-6man-rfc8504-bis-01] (41 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-03] (8 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-16] (17 pages) - Enhanced Duplicate Address Detection [draft-ietf-6man-enhanced-dad-15] (11 pages) - Carrying Network Resource (NR) related Information in IPv6 Extension Header [draft-ietf-6man-enhanced-vpn-vtn-id-09] (13 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) - Signaling DHCPv6 Prefix per Client Availability to Hosts [draft-ietf-6man-pio-pflag-12] (15 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-15] (19 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-08] (18 pages) - SNAC Router Flag in ICMPv6 Router Advertisement Messages [draft-ietf-6man-snac-router-ra-flag-02] (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) - The IPv6 VPN Service Destination Option [draft-ietf-6man-vpn-dest-opt-01] (12 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-04] (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) - 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) * Updates RFC9673 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) RFC9602: Segment Routing over IPv6 (SRv6) Segment Identifiers in the IPv6 Addressing Architecture (7 pages) RFC9631: The IPv6 Compact Routing Header (CRH) (14 pages) RFC9673: IPv6 Hop-by-Hop Options Processing Procedures (16 pages) 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-06] (23 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-06] (66 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-03] (54 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-09] (82 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-11] (38 pages) - Alternative Workflow and OAuth Parameters for the Authentication and Authorization for Constrained Environments (ACE) Framework [draft-ietf-ace-workflow-and-params-03] (58 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-06] (12 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) DNS Labeled With ACME Account ID Challenge [draft-ietf-acme-dns-account-label-00] (9 pages) - Automated Certificate Management Environment (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension [draft-ietf-acme-dtnnodeid-16] (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-04] (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) 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-01] (14 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) 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-13] (43 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-11] (27 pages) - BRSKI discovery and variations [draft-ietf-anima-brski-discovery-05] (59 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-13] (15 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) 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-07] (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-03] (109 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-04] (13 pages) - Semantic Definition Format (SDF) for Data and Interactions of Things [draft-onedm-t2trg-sdf-00] (51 pages) No Requests for Comments Audio/Video Transport Core Maintenance (avtcore) ------------------------------------------------ Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Dr. Bernard D. Aboba Jonathan Lennox Web and Internet Transport Directors: Francesca Palombini Zaheduzzaman Sarker Web and Internet Transport Advisor: Zaheduzzaman Sarker Mailing Lists: General Discussion: avt@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/avt Archive: https://mailarchive.ietf.org/arch/browse/avt/ Description of Working Group: The Real-time Transport Protocol (RTP) along with its associated profiles and payload formats provides for real-time transmission of audio and video over unicast and multicast transports. RTP is widely implemented and deployed for a broad range of applications, from telephony to television over IP. RTP itself is now an Internet Standard. Its associated profiles, extensions, and payload formats are currently at various levels of standards maturity. As new applications emerge, there is a need for guidelines for the use of the RTP/RTCP protocols and extensions specific to those applications. The AVTCORE working group is chartered for the following tasks: 1. To maintain the core RTP/RTCP specifications and the AVP, SAVP, AVPF, and SAVPF profiles. The group will provide architectural guidance for extending the protocols and guidelines for their proper use. 2. To develop application-specific guidelines for the use of RTP/RTCP protocols with the AVP, SAVP, AVPF, and SAVPF profiles, and extensions to those protocols that are driven by application-specific needs. 3. To specify and maintain payload formats for use with RTP. The working group will develop RTP payload formats for new media codecs, review and revise existing payload formats to advance those that are especially useful to Internet Standard, and declare others Historic. The group will follow the guidelines established in "Guidelines for Writers of RTP Payload Format Specifications" [BCP 36] and "How to Write an RTP Payload Format" (RFC 8088), and is responsible for maintaining those guidelines. 4. To evaluate and process proposals for RTP eXtended Report Block (XRBLOCK) definitions containing new metrics. The group will work within the framework defined by RFC 3611, "RTP Control Protocol Extended Reports (RTCP XR)" along with other RTP monitoring architecture being developed in the working group. It will follow the guidelines established in RFC 5968, "Guidelines for Extending the RTP Control Protocol (RTCP)" and RFC 6390, "Guidelines for Considering New Performance Metric Development". The AVTCORE working group will coordinate closely with the Security Area while working on maintenance and enhancements to the SRTP Profile (SAVP). Goals and Milestones: Apr 2019 - Submit RTP Header Extension for Video Frame Information for Proposed Standard Jun 2019 - Submit Feedback Mechanism for RTP Congestion Control for Proposed Standard Nov 2019 - Submit RTP Payload Format for VP9 Video for Proposed Standard Mar 2020 - Submit RTP Payload Format for ISO/IEC 21122 (JPEG XS) for Proposed Standard Feb 2021 - Submit RTP Payload format for Versatile Video Coding (VVC) Feb 2021 - Submit RTP Mixer Formatting of Multi-party Real-time Text Jul 2021 - Submit RTP Payload format for Essential Video Coding (EVC) Done - Submit Guidelines for using the Multiplexing Features of RTP for Informational Done - Submit RTP Payload Format for TTML Timed Text for Proposed Standard Internet-Drafts: - H.265 Profile for WebRTC [draft-aboba-avtcore-hevc-webrtc-02] (6 pages) - Multiplexing Scheme Updates for QUIC [draft-aboba-avtcore-rfc7983bis-01] (8 pages) - SDP Offer/Answer for RTP using QUIC as Transport - Design Issues [draft-dawkins-avtcore-sdp-rtp-quic-issues-00] (8 pages) - RTP over QUIC [draft-engelbart-rtp-over-quic-04] (21 pages) - RTP Control Protocol (RTCP) Messages for Green Metadata [draft-he-avtcore-rtcp-green-metadata-01] (10 pages) - Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows [draft-ietf-avt-app-rtp-keepalive-10] (12 pages) - Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing [draft-ietf-avtcore-5761-update-06] (7 pages) - Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) [draft-ietf-avtcore-6222bis-06] (10 pages) - The Addition of SRTP crypto suites based on the ARIA algorithms to the SDP Security Descriptions [draft-ietf-avtcore-aria-sdes-02] (9 pages) - The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP) [draft-ietf-avtcore-aria-srtp-11] (19 pages) - Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) [draft-ietf-avtcore-avp-codecs-03] (4 pages) - RTP Control Protocol (RTCP) Feedback for Congestion Control [draft-ietf-avtcore-cc-feedback-message-09] (13 pages) - RTP Clock Source Signalling [draft-ietf-avtcore-clksrc-11] (30 pages) - Completely Encrypting RTP Header Extensions and Contributing Sources [draft-ietf-avtcore-cryptex-08] (21 pages) - Explicit Congestion Notification (ECN) for RTP over UDP [draft-ietf-avtcore-ecn-for-rtp-08] (58 pages) - RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report [draft-ietf-avtcore-feedback-supression-rtp-17] (13 pages) - H.265 Profile for WebRTC [draft-ietf-avtcore-hevc-webrtc-05] (7 pages) - Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP) [draft-ietf-avtcore-idms-13] (23 pages) - RTP and Leap Seconds [draft-ietf-avtcore-leap-second-08] (9 pages) - Guidelines for Use of the RTP Monitoring Framework [draft-ietf-avtcore-monarch-22] (17 pages) - Multipath RTP (MPRTP) [draft-ietf-avtcore-mprtp-03] (41 pages) - Sending Multiple Types of Media in a Single RTP Session [draft-ietf-avtcore-multi-media-rtp-session-13] (15 pages) - RTP-Mixer Formatting of Multiparty Real-Time Text [draft-ietf-avtcore-multi-party-rtt-mix-20] (35 pages) - Guidelines for Using the Multiplexing Features of RTP to Support Multiple Media Streams [draft-ietf-avtcore-multiplex-guidelines-12] (36 pages) - Port Mapping between Unicast and Multicast RTP Sessions [draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02] (30 pages) - A General Mechanism for RTP Header Extensions [draft-ietf-avtcore-rfc5285-bis-14] (25 pages) - Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS) [draft-ietf-avtcore-rfc5764-mux-fixes-11] (13 pages) - Multiplexing Scheme Updates for QUIC [draft-ietf-avtcore-rfc7983bis-09] (8 pages) - RTP Control Protocol (RTCP) Messages for Temporal-Spatial Resolution [draft-ietf-avtcore-rtcp-green-metadata-04] (12 pages) - Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions [draft-ietf-avtcore-rtp-circuit-breakers-18] (25 pages) - RTP Payload Format for Essential Video Coding (EVC) [draft-ietf-avtcore-rtp-evc-07] (50 pages) - RTP Payload for Haptics [draft-ietf-avtcore-rtp-haptics-01] (21 pages) - RTP Payload Format for sub-codestream latency JPEG 2000 streaming [draft-ietf-avtcore-rtp-j2k-scl-04] (33 pages) - Sending Multiple RTP Streams in a Single RTP Session [draft-ietf-avtcore-rtp-multi-stream-11] (29 pages) - Sending Multiple RTP Streams in a Single RTP Session: Grouping RTP Control Protocol (RTCP) Reception Statistics and Other Feedback [draft-ietf-avtcore-rtp-multi-stream-optimisation-12] (16 pages) - RTP over QUIC (RoQ) [draft-ietf-avtcore-rtp-over-quic-12] (78 pages) - Closing the RTP Payload Format Media Types IANA Registry [draft-ietf-avtcore-rtp-payload-registry-05] (6 pages) - RTP Payload Format for the Secure Communication Interoperability Protocol (SCIP) Codec [draft-ietf-avtcore-rtp-scip-09] (18 pages) - Options for Securing RTP Sessions [draft-ietf-avtcore-rtp-security-options-10] (37 pages) - RTP Payload Format for SFrame [draft-ietf-avtcore-rtp-sframe-00] (5 pages) - RTP Topologies [draft-ietf-avtcore-rtp-topologies-update-10] (48 pages) - RTP Payload Format for Visual Volumetric Video-based Coding (V3C) [draft-ietf-avtcore-rtp-v3c-07] (44 pages) - RTP Payload Format for Versatile Video Coding (VVC) [draft-ietf-avtcore-rtp-vvc-18] (54 pages) - AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP) [draft-ietf-avtcore-srtp-aes-gcm-17] (48 pages) - Encrypted Key Transport for Secure RTP [draft-ietf-avtcore-srtp-ekt-03] (45 pages) - Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP) [draft-ietf-avtcore-srtp-encrypted-header-ext-05] (15 pages) - Guidelines for the Use of Variable Bit Rate Audio with Secure RTP [draft-ietf-avtcore-srtp-vbr-audio-04] (6 pages) - Explicit Congestion Notification (ECN) for RTP over UDP [draft-ietf-avt-ecn-for-rtp-03] (44 pages) - Video Frame Marking RTP Header Extension [draft-ietf-avtext-framemarking-16] (16 pages) - Forward-Shifted RTP Redundancy Payload Support [draft-ietf-avt-forward-shifted-red-08] (13 pages) - Port Mapping Between Unicast and Multicast RTP Sessions [draft-ietf-avt-ports-for-ucast-mcast-rtp-11] (35 pages) - AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) [draft-ietf-avt-srtp-aes-gcm-02] (19 pages) - Encrypted Key Transport for Secure RTP [draft-ietf-avt-srtp-ekt-03] (53 pages) - Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution [draft-ietf-avt-srtp-not-mandatory-16] (10 pages) - RTP Payload Format for ISO/IEC 21122 (JPEG XS) [draft-ietf-payload-rtp-jpegxs-18] (27 pages) - RTP Payload for Timed Text Markup Language (TTML) [draft-ietf-payload-rtp-ttml-06] (15 pages) - RTP Payload Format for the TETRA Audio Codec [draft-ietf-payload-tetra-03] (15 pages) - RTP Payload Format for Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) Codec [draft-ietf-payload-tsvcis-05] (20 pages) - RTP Payload Format for VP9 Video [draft-ietf-payload-vp9-16] (25 pages) - RTP Payload Format for Visual Volumetric Video-based Coding (V3C) [draft-ilola-avtcore-rtp-v3c-02] (41 pages) - Game State over Real Time Protocol [draft-jennings-dispatch-game-state-over-rtp-01] (24 pages) - RTP Congestion Control: Circuit Breakers for Unicast Sessions [draft-perkins-avtcore-rtp-circuit-breakers-01] (15 pages) - Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) [draft-rescorla-avtcore-6222bis-00] (10 pages) - Completely Encrypting RTP Header Extensions and Contributing Sources [draft-uberti-avtcore-cryptex-01] (10 pages) Requests for Comments: RFC6263: Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows (12 pages) RFC6284: Port Mapping between Unicast and Multicast RTP Sessions (30 pages) RFC6354: Forward-Shifted RTP Redundancy Payload Support (13 pages) RFC6562: Guidelines for the Use of Variable Bit Rate Audio with Secure RTP (6 pages) RFC6642: RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report (13 pages) RFC6679: Explicit Congestion Notification (ECN) for RTP over UDP (58 pages) * Updates RFC8311 RFC6792: Guidelines for Use of the RTP Monitoring Framework (17 pages) RFC6904: Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP) (15 pages) RFC7007: Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) (4 pages) RFC7022: Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) (10 pages) RFC7164: RTP and Leap Seconds (9 pages) RFC7201: Options for Securing RTP Sessions (37 pages) RFC7202: Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution (10 pages) RFC7272: Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP) (23 pages) RFC7273: RTP Clock Source Signalling (30 pages) RFC7667: RTP Topologies (48 pages) RFC7714: AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP) (48 pages) RFC7983: Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS) (13 pages) * Updates RFC9443 RFC8035: Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing (7 pages) RFC8083: Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions (25 pages) RFC8108: Sending Multiple RTP Streams in a Single RTP Session (29 pages) RFC8269: The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP) (19 pages) RFC8285: A General Mechanism for RTP Header Extensions (25 pages) RFC8759: RTP Payload for Timed Text Markup Language (TTML) (15 pages) RFC8817: RTP Payload Format for Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) Codec (20 pages) RFC8860: Sending Multiple Types of Media in a Single RTP Session (15 pages) RFC8861: Sending Multiple RTP Streams in a Single RTP Session: Grouping RTP Control Protocol (RTCP) Reception Statistics and Other Feedback (16 pages) RFC8872: Guidelines for Using the Multiplexing Features of RTP to Support Multiple Media Streams (36 pages) RFC8888: RTP Control Protocol (RTCP) Feedback for Congestion Control (13 pages) RFC9071: RTP-Mixer Formatting of Multiparty Real-Time Text (35 pages) RFC9134: RTP Payload Format for ISO/IEC 21122 (JPEG XS) (27 pages) RFC9328: RTP Payload Format for Versatile Video Coding (VVC) (54 pages) RFC9335: Completely Encrypting RTP Header Extensions and Contributing Sources (21 pages) RFC9443: Multiplexing Scheme Updates for QUIC (8 pages) RFC9584: RTP Payload Format for Essential Video Coding (EVC) (42 pages) RFC9607: RTP Payload Format for the Secure Communication Interoperability Protocol (SCIP) Codec (15 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) RFC9647: A YANG Data Model for Babel (39 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-02] (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-08] (18 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-11] (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-02] (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-18] (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-11] (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-11] (34 pages) - Weighted Multi-Path Procedures for EVPN Multi-Homing [draft-ietf-bess-evpn-unequal-lb-24] (23 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-16] (25 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-09] (18 pages) - EVPN-VPWS Seamless Integration with L2VPN VPWS [draft-ietf-bess-evpn-vpws-seamless-01] (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-07] (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-11] (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-02] (38 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-02] (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-01] (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. 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. 2. Extend BFD to allow it to detect whether a path between two systems is capable of carrying a payload of a particular size. 3. Define a use of the BFD Echo where the local system supports BFD but the adjacent system does not support BFD. 4. Provide an optimization to BFD authentication to reduce computational demand while still providing desirable security properties. 5. Provide a Meticulous Keyed mode for BFD authentication. 6. Define experimental extensions to measure BFD stability. The working group will maintain a relationship with the MPLS working group. Goals and Milestones: Dec 2024 - Extend BFD to allow it to detect whether a path between two systems is capable of carrying a payload of a particular size. Dec 2024 - Define a use of the BFD Echo where the local system supports BFD but the adjacent system does not support BFD. Jun 2025 - Provide an optimization to BFD authentication to reduce computational demand while still providing desirable security properties. Jun 2025 - Provide a Meticulous Keyed mode for BFD authentication. Jun 2025 - Define experimental extensions to measure BFD stability. 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-12] (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-21] (25 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-18] (20 pages) - BFD Stability [draft-ietf-bfd-stability-16] (21 pages) - Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management [draft-ietf-bfd-tc-mib-08] (11 pages) - Unaffiliated Bidirectional Forwarding Detection (BFD) Echo [draft-ietf-bfd-unaffiliated-echo-12] (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-19] (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-14] (14 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-16] (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-12] (9 pages) - PIM Signaling Through BIER Core [draft-ietf-bier-pim-signaling-12] (13 pages) - BIER Ping and Trace [draft-ietf-bier-ping-15] (30 pages) - Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer [draft-ietf-bier-pmmm-oam-16] (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-07] (12 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-07] (12 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) 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 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 Mar 2025 - Draft on Selecting and Applying Model(s) for Benchmarking 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-03] (30 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-08] (67 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-05] (27 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-02] (28 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) 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) Requests for Comments: RFC9669: BPF Instruction Set Architecture (ISA) (37 pages) 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: Nov 2024 - Adopt a draft for Participant mapping in iTip Dec 2024 - Submit task draft to IESG Dec 2024 - Submit subscription upgrade document to IESG Mar 2025 - Submit JSCalendar mapping document to IESG for publication Jun 2025 - Submit vpoll document to IESG for publication Dec 2025 - 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) - iTip using PARTICIPANT only [draft-douglass-itip-participants-02] (20 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-09] (112 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-07] (51 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) Computing-Aware Traffic Steering (cats) --------------------------------------- Charter Last Modified: 2024-10-25 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-04] (25 pages) - Computing-Aware Traffic Steering (CATS) Problem Statement, Use Cases, and Requirements [draft-ietf-cats-usecases-requirements-04] (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) - CATS Metrics Definition [draft-ysl-cats-metric-definition-02] (14 pages) No Requests for Comments Concise Binary Object Representation Maintenance and Extensions (cbor) ---------------------------------------------------------------------- Charter Last Modified: 2024-09-18 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-07] (14 pages) - CBOR Common Deterministic Encoding (CDE) [draft-ietf-cbor-cde-06] (16 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-13] (44 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) 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) - Use cases, Network Scenarios and gap analysis for Packet Optical Integration (POI) with coherent plugables under ACTN Framework [draft-ietf-ccamp-actn-poi-pluggable-usecases-gaps-00] (17 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-07] (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-17] (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-04] (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-20] (92 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-03] (89 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) - Use cases, Network Scenarios and gap analysis for Packet Optical Integration (POI) with coherent plugables under ACTN Framework [draft-poidt-ccamp-actn-poi-pluggable-usecases-gaps-01] (22 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) RFC9656: A YANG Data Model for Microwave Topology (39 pages) Congestion Control Working Group (ccwg) --------------------------------------- Charter Last Modified: 2024-01-17 Current Status: Active Chairs: Eric Kinnear Reese Enghardt Web and Internet Transport Directors: Francesca Palombini Zaheduzzaman Sarker Web and Internet Transport Advisor: Zaheduzzaman Sarker Mailing Lists: General Discussion: ccwg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ccwg Archive: https://mailarchive.ietf.org/arch/browse/ccwg/ Description of Working Group: RFC 5033 describes a Best Current Practice to evaluate new congestion control algorithms as Experimental or Proposed Standard RFCs. TCP was the dominant consumer of this work, and proposals were typically discussed in research groups, for example the Internet Congestion Control Research Group (ICCRG). Since RFC 5033 was published, many conditions have changed. Congestion control algorithm proponents now often have the opportunity to test and deploy at scale without IETF review. The set of protocols using these algorithms has spread beyond TCP and SCTP to include DCCP, QUIC, and beyond. There is more interest in specialized use cases such as data centers and real-time protocols. Finally, the community has gained much more experience with indications of congestion beyond packet loss. The Congestion Control Working Group will analyze some of the impediments to congestion control work occurring in the IETF and can generalize transports from TCP to all of the relevant transport protocols. This will inform a revision of RFC 5033 (5033bis) that encourages IETF review of congestion control proposals and standardization of mature congestion control algorithms. The congestion control expertise in the working group also makes it a natural venue to take on other work related to indications of congestion such as delay, queuing algorithms, rate pacing, multipath, interaction with other layers, among others. In particular, it can address congestion control algorithms with empirical evidence of safety (for example - avoiding congestion collapse) and stated intent to deploy by major implementations. The working group is intended to be a home for such work, and it is chartered to adopt proposals in this space if such congestion control algorithms are presented before or after the completion of the primary deliverable i.e. 5033bis. The group will coordinate closely with other relevant working and research groups, including ICCRG, TCPM, QUIC, and TSVWG. Documents in CCWG will remain as transport protocol agnostic as possible, but they may have short specific instructions, such as header options or parameter formats, for one or more protocols. Documents that are wholly specific to mechanisms in a single protocol will remain in the maintenance working group for that protocol. Algorithms proposed for Experimental status, in consultation with ICCRG, based on an assessment of their maturity and likelihood of near-term wide-scale deployment, are in scope. Publication of Informational RFCs analyzing the published standard congestion control algorithms is within CCWG scope. However, it is not chartered to document the state of congestion control in the Internet, including assessments of whether any particular implementation complies with existing standards. Other venues, such as the IRTF, may be more appropriate for publishing such documents. Goals and Milestones: Jun 2024 - Submit 5033bis to IESG for publication. Dec 2024 - Submit an Informational RFC analyzing the published standard congestion controllers Internet-Drafts: - BBR Congestion Control [draft-ietf-ccwg-bbr-01] (79 pages) - Specifying New Congestion Control Algorithms [draft-ietf-ccwg-rfc5033bis-08] (28 pages) No Requests for Comments Content Delivery Networks Interconnection (cdni) ------------------------------------------------ Charter Last Modified: 2024-03-11 Current Status: Active Chairs: Chris Lemmons Kevin J. Ma Sanjay Mishra Web and Internet Transport Directors: Francesca Palombini Zaheduzzaman Sarker Web and Internet Transport Advisor: Francesca Palombini Mailing Lists: General Discussion: cdni@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cdni Archive: https://mailarchive.ietf.org/arch/browse/cdni/ Description of Working Group: A Content Delivery Network (CDN) is an infrastructure of network elements operating at layer 4 through layer 7, arranged for the efficient distribution and delivery of digital content. Such content includes, but is not limited to, web pages and images delivered via HTTP, and streaming of continuous media delivered via HTTP, RTSP, RTMP, etc. CDNs typically provide services to multiple Content Service Providers (CSPs). CDNs provide numerous benefits: a shared platform for multi-service content delivery, reduced transmission costs for cacheable content, improved quality of experience for end users and increased robustness of delivery. For these reasons they are frequently used for large-scale content delivery. As a result of the significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure and many Network Service Providers and Enterprise Service Providers are deploying their own CDNs. Subject to the policy of the CSP, it is generally desirable that a given item of content can be delivered to an end user regardless of that end user's location or attachment network. This creates a need for interconnecting (previously) standalone CDNs so they can interoperate and collectively behave as a single delivery infrastructure. The goal of the CDNI Working Group is to allow the interconnection of separately administered CDNs in support of the end-to-end delivery of content from CSPs through multiple CDNs and ultimately to end users (via their respective User Agents). The CDNI WG aims at delivering a targeted, deployable solution in a short timeframe as needed by the industry. It is expected that the CDNI interfaces will be realized using existing IETF protocols for transport and message exchange, and using existing object notation grammars/languages for the definition of CDNI objects and semantics. In the event that protocol extensions or new protocols are deemed necessary by the WG, the WG will recharter. The working group will focus on the following items: - A "requirements" document. This document lists the requirements for the CDNI architecture and the CDNI interfaces. In particular, this document will focus on identifying a reasonable set of more urgent and important requirements that will be addressed in the initial set of CDNI protocols and solutions produced by the working group. This document will list the requirements stemming from the threat analysis and to be met by each of the CDNI interfaces. - A "framework" document providing a description of the different components of the CDNI architecture and how they interact with one another. This document will also include a "threat analysis" discussing the security concerns and threats, the trust model and privacy issues specific to CDNI. - A specification of the "CDNI Request Routing Redirection interface". This interface will allow an upstream CDN Request Routing system to obtain from the downstream CDN the information necessary to perform request redirection. It is actually a logical bundling of two separate but related interfaces: * Footprint & Capability Advertisement interface: Asynchronous operations to exchange routing information (e.g., the network footprint and capabilities served by a given CDN) that enables CDN selection for subsequent user requests; and * Request Routing Redirection interface: Synchronous operations to select a delivery CDN (surrogate) for a given user request. - A specification of the "CDNI Metadata interface". This interface will allow the CDNs to exchange content distribution metadata of inter-CDN scope. Content distribution metadata refers to the subset of content metadata that is relevant to the distribution of the content and therefore is to be processed by CDNs (for example, this may include information enabling: content acquisition, geo-blocking, enforcement of availability windows or access control). - A specification of the "CDNI Logging interface". This interface will allow CDN logging systems to exchange logging information associated with actions that are relevant across CDNs (such as content distribution, content delivery and content routing actions) for purposes of accounting, analytics, monitoring, etc. - A specification of the "CDNI Control interface". In particular, this interface will allow an upstream CDN to remove or invalidate content in a downstream CDN. - A specification for "CDNI URI Signing". This document will specify a mechanism that allows interconnected CDNs to support access control by signing content URIs. This may involve extensions to the CDNI interfaces (e.g. CDNI Metadata interface, CDNI Logging interface). The WG will discuss and address the security, management and operational issues specific to CDNI, inside the above documents and specifications. The working group will only define solutions for aspects of the CDN Interconnection problem space that require direct communication or interoperation between CDNs. In particular, the WG will not define: - New session, transport or network protocols. - New protocols for delivering content from a CDN to an End User/User Agent. - New protocols for ingestion of content or metadata between a CSP and a CDN. - New protocols for acquiring content across CDNs. - Protocols and algorithms for intra-CDN operations. - Support for Transparent Caching across CDNs. - New applications consuming CDNI logs. - Digital Right Management (DRM) mechanisms. The CDNI WG will work with other IETF WGs to assess, and where appropriate, leverage protocols developed by those WGs, in order to realize the CDNI requirements and CDNI interfaces. For example, the WG may assess the suitability of the ALTO protocol as a protocol to enable downstream CDNs to exchange information which may aid an upstream CDN with making CDNI request routing decisions. The CDNI WG will also coordinate with relevant groups outside the IETF, if and where appropriate. Goals and Milestones: Dec 2024 - Submit specification of CDNI Control Triggers Interface Extensions to IESG as Proposed Standard Dec 2024 - Submit specification of CDNI Edge Control Metadata to IESG as Proposed Standard Dec 2024 - Submit specification of CDNI Protected Secrets Metadata to IESG as Proposed Standard Dec 2024 - Submit specification of CDNI Cache Control Metadata to IESG as Proposed Standard Apr 2025 - Recharter or dissolve Done - Submit CDNI problem statement to IESG as Informational Done - Submit CDNI use cases to IESG as Informational Done - Submit CDNI requirements to IESG as Informational Done - Submit CDNI framework to IESG as Informational Done - Submit specification of the CDNI Logging interface to IESG as Proposed Standard Done - Submit specification of the CDNI Control interface to IESG as proposed Standard Done - Submit specification of the CDNI Request Routing Redirection interface to IESG as Proposed Standard Done - Submit specification of the CDNI Metadata interface to IESG as Proposed Standard Done - Submit specification of the CDNI Footprint & Capabilities Advertisement interface to IESG as Proposed Standard Done - Submit specification of CDNI Request Routing Extensions to IESG as Proposed Standard Done - Submit specification of URI Signing for CDNI to IESG as Proposed Standard Done - Submit specification of CDNI Footprint Type Extensions to IESG as Proposed Standard Done - Submit specification of CDNI Extensions for HTTPS ACME STAR Delegation to IESG as Proposed Standard Done - Submit specification of CDNI Extensions for HTTPS TLS Subcert Delegation to IESG as Proposed Standard Done - Submit specification of CDNI Extensions for Capacity Capability Advertisement Internet-Drafts: - CDNI SVA Request Routing Extensions [draft-finkelman-cdni-rr-sva-extensions-01] (11 pages) - Content Delivery Network Interconnection (CDNI) Footprint Types: Country Subdivision Code and Footprint Union [draft-ietf-cdni-additional-footprint-types-12] (11 pages) - CDNI Cache Control Metadata [draft-ietf-cdni-cache-control-metadata-02] (15 pages) - CDNI Capacity Capability Advertisement Extensions [draft-ietf-cdni-capacity-insights-extensions-10] (18 pages) - Content Delivery Network Interconnection (CDNI) Control Interface / Triggers 2nd Edition [draft-ietf-cdni-ci-triggers-rfc8007bis-15] (100 pages) - CDNI Client Access Control Metadata [draft-ietf-cdni-client-access-control-metadata-00] (16 pages) - Content Delivery Network Interconnection (CDNI) Control Interface / Triggers [draft-ietf-cdni-control-triggers-15] (49 pages) - CDNI delegation using Automated Certificate Management Environment [draft-ietf-cdni-delegation-acme-05] (11 pages) - CDNI Edge Control Metadata [draft-ietf-cdni-edge-control-metadata-02] (14 pages) - Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics [draft-ietf-cdni-footprint-capabilities-semantics-20] (31 pages) - Framework for Content Distribution Network Interconnection (CDNI) [draft-ietf-cdni-framework-14] (58 pages) - CDNI Metadata for Delegated Credentials [draft-ietf-cdni-https-delegation-subcerts-12] (13 pages) - CDNI extensions for HTTPS delegation [draft-ietf-cdni-interfaces-https-delegation-13] (10 pages) - Content Distribution Network Interconnection (CDNI) Logging Interface [draft-ietf-cdni-logging-27] (63 pages) - CDNI Logging Extensions [draft-ietf-cdni-logging-extensions-00] (54 pages) - Content Delivery Network Interconnection (CDNI) Media Type Registration [draft-ietf-cdni-media-type-06] (7 pages) - Content Delivery Network Interconnection (CDNI) Metadata [draft-ietf-cdni-metadata-21] (66 pages) - Content Delivery Network Interconnection (CDNI) Named Footprints [draft-ietf-cdni-named-footprints-00] (19 pages) - Content Distribution Network Interconnection (CDNI) Problem Statement [draft-ietf-cdni-problem-statement-08] (32 pages) - CDNI Protected Secrets Metadata [draft-ietf-cdni-protected-secrets-metadata-02] (18 pages) - Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection [draft-ietf-cdni-redirection-20] (35 pages) - Content Delivery Network Interconnection (CDNI) Request Routing Extensions [draft-ietf-cdni-request-routing-extensions-08] (17 pages) - Content Distribution Network Interconnection (CDNI) Requirements [draft-ietf-cdni-requirements-17] (23 pages) - CDNI Control Triggers Interface Extensions [draft-ietf-cdni-triggers-extensions-09] (45 pages) - URI Signing for Content Delivery Network Interconnection (CDNI) [draft-ietf-cdni-uri-signing-26] (37 pages) - Use Cases for Content Delivery Network Interconnection [draft-ietf-cdni-use-cases-10] (16 pages) Requests for Comments: RFC6707: Content Distribution Network Interconnection (CDNI) Problem Statement (32 pages) RFC6770: Use Cases for Content Delivery Network Interconnection (16 pages) RFC7336: Framework for Content Distribution Network Interconnection (CDNI) (58 pages) RFC7337: Content Distribution Network Interconnection (CDNI) Requirements (23 pages) RFC7736: Content Delivery Network Interconnection (CDNI) Media Type Registration (7 pages) RFC7937: Content Distribution Network Interconnection (CDNI) Logging Interface (63 pages) RFC7975: Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection (35 pages) RFC8006: Content Delivery Network Interconnection (CDNI) Metadata (66 pages) RFC8007: Content Delivery Network Interconnection (CDNI) Control Interface / Triggers (49 pages) RFC8008: Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics (31 pages) * Updates RFC9388 RFC8804: Content Delivery Network Interconnection (CDNI) Request Routing Extensions (17 pages) RFC9246: URI Signing for Content Delivery Network Interconnection (CDNI) (37 pages) RFC9388: Content Delivery Network Interconnection (CDNI) Footprint Types: Country Subdivision Code and Footprint Union (11 pages) RFC9538: Content Delivery Network Interconnection (CDNI) Delegation Using the Automated Certificate Management Environment (10 pages) RFC9677: Content Delivery Network Interconnection (CDNI) Metadata for Delegated Credentials (11 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-14] (33 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) * Updates RFC9559 RFC9043: FFV1 Video Coding Format Versions 0, 1, and 3 (51 pages) RFC9559: Matroska Media Container Format Specification (157 pages) Constrained RESTful Environments (core) --------------------------------------- Charter Last Modified: 2024-11-05 Current Status: Active Chairs: Carsten Bormann Jaime Jimenez Marco Tiloca Web and Internet Transport Directors: Francesca Palombini Zaheduzzaman Sarker Web and Internet Transport Advisor: Francesca Palombini Mailing Lists: General Discussion: core@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/core Archive: https://mailarchive.ietf.org/arch/browse/core/ Description of Working Group: CoRE provides a framework for resource-oriented applications intended to run on constrained IP networks. A constrained IP network has limited packet sizes, may exhibit a high degree of packet loss, and may have a substantial number of devices that may be powered off at any point in time but periodically "wake up" for brief periods of time. These networks and the nodes within them are characterized by severe limits on throughput, available power, and particularly on the complexity that can be supported with limited code size and limited RAM per node [RFC 7228]. More generally, we speak of constrained node networks whenever at least some of the nodes and networks involved exhibit these characteristics. Low-Power Wireless Personal Area Networks (LoWPANs) are an example of this type of network. Constrained networks can occur as part of home and building automation, energy management, and the Internet of Things. The CoRE working group will define a framework for a limited class of applications: those that deal with the manipulation of simple resources on constrained networks. This includes applications to monitor simple sensors (e.g. temperature sensors, light switches, and power meters), to control actuators (e.g. light switches, heating controllers, and door locks), and to manage devices. The general architecture consists of nodes on the constrained network, called Devices, that are responsible for one or more Resources that may represent sensors, actuators, combinations of values, and/or other information. Devices send messages to change and query resources on other Devices. Devices can send notifications about changed resource values to Devices that have expressed their interest to receive notification about changes. A Device can also publish or be queried about its resources. (Typically a single physical host on the network would have just one Device but a host might represent multiple logical Devices. The specific terminology to be used here is to be decided by the working group.) As part of the framework for building these applications, the working group has defined a Constrained Application Protocol (CoAP) for the manipulation of Resources on a Device. CoAP is designed for use between Devices on the same constrained network, between Devices and general nodes on the Internet, and between Devices on different constrained networks both joined by an internet. (CoAP is also being used via other mechanisms, such as SMS on mobile communication networks.) CoAP targets the type of operating environments defined in the ROLL and 6Lo working groups which have additional constraints compared to normal IP networks, but the CoAP protocol also operates over traditional IP networks. There also may be proxies that interconnect between other Internet protocols and the Devices using the CoAP protocol. It is worth noting that proxy does not have to occur at the boundary between the constrained network and the more general network, but can be deployed at various locations in the less-constrained network. CoAP supports various forms of "caching". Beyond the benefits of caching already well known from REST, caching can be used to increase energy savings of low-power nodes by allowing them to be normally-off [RFC 7228]. For example, a temperature sensor might wake up every five minutes and send the current temperature to a proxy that has expressed interest in notifications; when the proxy receives a request over CoAP or HTTP for that temperature resource, it can respond with the last notified value (instead of trying to query the Device which may not be reachable at this time). The working group will continue to evolve this model to increase its practical applicability. The working group will perform maintenance on its first four standards-track specifications: - RFC 6690 - RFC 7252 - RFC 7641 - draft-ietf-core-block and will continue to evolve the experimental group communications support (RFC 7390). The working group will not develop a reliable multicast solution. CoAP today works over UDP and DTLS. The working group will define transport mappings for alternative transports as required, both IP (starting with TCP and a secure version over TLS) and non-IP (e.g., SMS, working with the security area on potentially addressing the security gap); this includes defining appropriate URI schemes. Continued compatibility with CoAP over SMS as defined in OMA LWM2M will be considered. CoRE will continue and complete its work on draft-ietf-core-resource-directory, as already partially adopted by OMA LWM2M. Interoperability with DNS-SD (and the work of the dnssd working group) will be a primary consideration. The working group will also work on a specification enabling broker-based publish-subscribe-style communication over CoAP. CoRE will work on related data formats, such as alternative representations of RFC 6690 link format and RFC 7390 group communication information. The working group will complete the SenML specification, again with consideration to its adoption in OMA LWM2M. RFC 7252 defines a basic HTTP mapping for CoAP, with further discussion in draft-ietf-core-http-mapping. This mapping will be evolved and supported by further documents. Besides continuing to examine operational and manageability aspects of the CoAP protocol itself, CoRE will also develop a way to make RESTCONF-style management functions available via CoAP that is appropriate for constrained node networks. This will require very close coordination with NETCONF and other operations and management working groups. YANG data models will be used for manageability. Note that the YANG modeling language is not a target for change in this process, though additional mechanisms that support YANG modules may be employed in specific cases where significant performance gains are both attainable and required. The working group will continue to consider the OMA LWM2M management functions as a well-accepted alternative form of management and provide support at the CoAP protocol level where required. The working group has selected DTLS as the basis for the communications security in CoAP. CoRE will work with the TLS working group on the efficiency of this solution. The preferred cipher suites will evolve in cooperation with the TLS working group and CFRG. The ACE working group is expected to provide solutions to authorization that may need complementary elements on the CoRE side. Object security as defined in JOSE and being adapted to the constrained node network requirements in COSE also may need additions on the CoRE side. The working group will coordinate on requirements from many organizations and SDO. The working group will closely coordinate with other IETF working groups, particularly of the constrained node networks cluster (6Lo, 6TiSCH, LWIG, ROLL, ACE, COSE), and appropriate groups in the IETF OPS and Security areas. Work on these subjects, as well as on interaction models and design patterns (including follow-up work around the CoRE Interfaces draft) may benefit from close cooperation with the proposed Thing-to-Thing Research Group. Goals and Milestones: Aug 2024 - Secure group communication for CoAP submitted to IESG for PS Aug 2024 - Group communication for CoAP bis submitted to IESG for PS Sep 2024 - DNS over CoAP (DoC) submitted to IESG for PS Nov 2024 - Constrained Resource Identifiers submitted to IESG for PS Nov 2024 - Conditional Attributes for Constrained RESTful Environments submitted to IESG for PS Mar 2025 - Publish-subscribe architecture for CoAP submitted to IESG for PS Mar 2025 - Management over CoAP (COMI) submitted to IESG for PS Nov 2025 - Dynamic Resource Linking for Constrained RESTful Environments submitted to IESG as Informational Nov 2025 - Management over CoAP (YANG Library) submitted to IESG for PS Mar 2026 - Constrained RESTful Application Language (CoRAL) submitted to IESG for PS Dec 2026 - CoRE Interfaces submitted to IESG as Informational Done - Blockwise transfers in CoAP submitted to IESG Done - Best Practices for HTTP-CoAP Mapping Implementation submitted to IESG Done - WG adoption for Management over CoAP Done - Patch and Fetch Methods for CoAP submitted to IESG for PS Done - Representing CoRE Link Collections in JSON submitted to IESG Done - CoAP over TCP, TLS, and WebSockets submitted to IESG for PS Done - CBOR Encoding of Data Modeled with YANG submitted to IESG for PS Done - Media Types for Sensor Measurement Lists (SenML) submitted to IESG for PS Done - Object Security for Constrained RESTful Environments (OSCORE) Done - CoRE Resource Directory submitted to IESG for PS Done - Concise Problem Details For CoAP APIs submitted to IESG for PS Done - Creation of IANA registry for CoRE target attributes submitted to IESG as Informational RFC Done - Using EDHOC with CoAP and OSCORE submitted to IESG for PS Internet-Drafts: - CoAP Protocol Indication [draft-amsuess-core-transport-indication-03] (25 pages) - Constrained Application Protocol (CoAP): Corrections and Clarifications [draft-bormann-core-corr-clar-05] (20 pages) - SenML Features and Versions [draft-bormann-core-senml-versions-01] (5 pages) - CoRE Target Attribute Registry [draft-bormann-core-target-attr-01] (10 pages) - Constrained Application Protocol (CoAP) Block-Wise Transfer Options for Faster Transmission [draft-bosh-core-new-block-04] (23 pages) - Problem Details For CoAP APIs [draft-fossati-core-coap-problem-02] (12 pages) - Constrained Application Protocol (CoAP) Performance Measurement Option [draft-fz-core-coap-pm-04] (16 pages) - Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP) [draft-hartke-core-stateless-02] (16 pages) - Attacks on the Constrained Application Protocol (CoAP) [draft-ietf-core-attacks-on-coap-04] (21 pages) - Block-Wise Transfers in the Constrained Application Protocol (CoAP) [draft-ietf-core-block-21] (37 pages) - The Constrained Application Protocol (CoAP) [draft-ietf-core-coap-18] (112 pages) - ALPN ID Specification for CoAP over DTLS [draft-ietf-core-coap-dtls-alpn-00] (5 pages) - Constrained Application Protocol (CoAP) Performance Measurement Option [draft-ietf-core-coap-pm-03] (16 pages) - A publish-subscribe architecture for the Constrained Application Protocol (CoAP) [draft-ietf-core-coap-pubsub-15] (37 pages) - CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets [draft-ietf-core-coap-tcp-tls-11] (54 pages) - CoAP Simple Congestion Control/Advanced [draft-ietf-core-cocoa-03] (18 pages) - CoAP Management Interface (CORECONF) [draft-ietf-core-comi-19] (48 pages) - Conditional Attributes for Constrained RESTful Environments [draft-ietf-core-conditional-attributes-08] (25 pages) - The Constrained RESTful Application Language (CoRAL) [draft-ietf-core-coral-06] (47 pages) - Constrained Application Protocol (CoAP): Corrections and Clarifications [draft-ietf-core-corr-clar-00] (20 pages) - Uniform Resource Names for Device Identifiers [draft-ietf-core-dev-urn-11] (15 pages) - DNS over CoAP (DoC) [draft-ietf-core-dns-over-coap-09] (21 pages) - Dynamic Resource Linking for Constrained RESTful Environments [draft-ietf-core-dynlink-14] (14 pages) - Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing [draft-ietf-core-echo-request-tag-14] (27 pages) - PATCH and FETCH Methods for the Constrained Application Protocol (CoAP) [draft-ietf-core-etch-04] (21 pages) - Fast-Slow Retransmission Timeout and Congestion Control Algorithm for CoAP [draft-ietf-core-fasor-02] (15 pages) - Group Communication for the Constrained Application Protocol (CoAP) [draft-ietf-core-groupcomm-25] (46 pages) - Group Communication for the Constrained Application Protocol (CoAP) [draft-ietf-core-groupcomm-bis-12] (91 pages) - Proxy Operations for CoAP Group Communication [draft-ietf-core-groupcomm-proxy-03] (62 pages) - Constrained Application Protocol (CoAP) Hop-Limit Option [draft-ietf-core-hop-limit-07] (8 pages) - Constrained Resource Identifiers [draft-ietf-core-href-16] (59 pages) - Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP) [draft-ietf-core-http-mapping-17] (40 pages) - Reusable Interface Definitions for Constrained RESTful Environments [draft-ietf-core-interfaces-14] (25 pages) - Constrained RESTful Environments (CoRE) Link Format [draft-ietf-core-link-format-14] (22 pages) - Representing Constrained RESTful Environments (CoRE) Link Format in JSON and CBOR [draft-ietf-core-links-json-10] (20 pages) - Multipart Content-Format for the Constrained Application Protocol (CoAP) [draft-ietf-core-multipart-ct-04] (9 pages) - Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission [draft-ietf-core-new-block-14] (41 pages) - Object Security for Constrained RESTful Environments (OSCORE) [draft-ietf-core-object-security-16] (94 pages) - Observing Resources in the Constrained Application Protocol (CoAP) [draft-ietf-core-observe-16] (30 pages) - Observe Notifications as CoAP Multicast Responses [draft-ietf-core-observe-multicast-notifications-10] (96 pages) - OSCORE-capable Proxies [draft-ietf-core-oscore-capable-proxies-03] (57 pages) - Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the Constrained Application Protocol (CoAP) and Object Security for Constrained RESTful Environments (OSCORE) [draft-ietf-core-oscore-edhoc-11] (33 pages) - Group Object Security for Constrained RESTful Environments (Group OSCORE) [draft-ietf-core-oscore-groupcomm-23] (117 pages) - Identifier Update for OSCORE [draft-ietf-core-oscore-id-update-01] (25 pages) - Key Usage Limits for OSCORE [draft-ietf-core-oscore-key-limits-03] (14 pages) - Key Update for OSCORE (KUDOS) [draft-ietf-core-oscore-key-update-09] (68 pages) - Concise Problem Details for Constrained Application Protocol (CoAP) APIs [draft-ietf-core-problem-details-08] (21 pages) - CoRE Resource Directory: DNS-SD mapping [draft-ietf-core-rd-dns-sd-05] (14 pages) - Constrained RESTful Environments (CoRE) Resource Directory [draft-ietf-core-resource-directory-28] (60 pages) - Sensor Measurement Lists (SenML) [draft-ietf-core-senml-16] (54 pages) - Sensor Measurement Lists (SenML) Fields for Indicating Data Value Content-Format [draft-ietf-core-senml-data-ct-07] (10 pages) - FETCH and PATCH with Sensor Measurement Lists (SenML) [draft-ietf-core-senml-etch-07] (11 pages) - Additional Units for Sensor Measurement Lists (SenML) [draft-ietf-core-senml-more-units-06] (9 pages) - Sensor Measurement Lists (SenML) Features and Versions [draft-ietf-core-senml-versions-05] (7 pages) - YANG Schema Item iDentifier (YANG SID) [draft-ietf-core-sid-24] (50 pages) - Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP) [draft-ietf-core-stateless-08] (20 pages) - CoRE Target Attributes Registry [draft-ietf-core-target-attr-06] (8 pages) - "Too Many Requests" Response Code for the Constrained Application Protocol [draft-ietf-core-too-many-reqs-06] (6 pages) - CoAP Transport Indication [draft-ietf-core-transport-indication-07] (47 pages) - Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR) [draft-ietf-core-yang-cbor-20] (45 pages) - Constrained YANG Module Library [draft-ietf-core-yang-library-03] (17 pages) - Fast-Slow Retransmission Timeout and Congestion Control Algorithm for CoAP [draft-jarvinen-core-fasor-02] (15 pages) - SenML Data Value Content-Format Indication [draft-keranen-core-senml-data-ct-02] (6 pages) - ALPN ID Specification for CoAP over DTLS [draft-lenders-core-coap-dtls-svcb-01] (5 pages) - Attacks on the Constrained Application Protocol (CoAP) [draft-mattsson-core-coap-attacks-03] (20 pages) - Combining EDHOC and OSCORE [draft-palombini-core-oscore-edhoc-02] (12 pages) - Observe Notifications as CoAP Multicast Responses [draft-tiloca-core-observe-multicast-notifications-05] (67 pages) - Constrained YANG Module Library [draft-veillette-core-yang-library-05] (15 pages) Requests for Comments: RFC6690: Constrained RESTful Environments (CoRE) Link Format (22 pages) RFC7252: The Constrained Application Protocol (CoAP) (112 pages) * Updates RFC7959 * Updates RFC8613 * Updates RFC8974 * Updates RFC9175 RFC7390: Group Communication for the Constrained Application Protocol (CoAP) (46 pages) RFC7641: Observing Resources in the Constrained Application Protocol (CoAP) (30 pages) * Updates RFC8323 RFC7959: Block-Wise Transfers in the Constrained Application Protocol (CoAP) (37 pages) * Updates RFC8323 * Updates RFC8323 RFC8075: Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP) (40 pages) RFC8132: PATCH and FETCH Methods for the Constrained Application Protocol (CoAP) (21 pages) RFC8323: CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets (54 pages) * Updates RFC8974 RFC8428: Sensor Measurement Lists (SenML) (54 pages) * Updates RFC9100 RFC8516: "Too Many Requests" Response Code for the Constrained Application Protocol (6 pages) RFC8613: Object Security for Constrained RESTful Environments (OSCORE) (94 pages) RFC8710: Multipart Content-Format for the Constrained Application Protocol (CoAP) (9 pages) RFC8768: Constrained Application Protocol (CoAP) Hop-Limit Option (8 pages) RFC8790: FETCH and PATCH with Sensor Measurement Lists (SenML) (11 pages) RFC8798: Additional Units for Sensor Measurement Lists (SenML) (9 pages) RFC8974: Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP) (20 pages) RFC9039: Uniform Resource Names for Device Identifiers (15 pages) RFC9100: Sensor Measurement Lists (SenML) Features and Versions (7 pages) RFC9175: Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing (27 pages) RFC9176: Constrained RESTful Environments (CoRE) Resource Directory (60 pages) RFC9177: Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission (41 pages) RFC9193: Sensor Measurement Lists (SenML) Fields for Indicating Data Value Content-Format (10 pages) RFC9254: Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR) (45 pages) RFC9290: Concise Problem Details for Constrained Application Protocol (CoAP) APIs (21 pages) RFC9423: Constrained RESTful Environments (CoRE) Target Attributes Registry (8 pages) RFC9595: YANG Schema Item iDentifier (YANG SID) (44 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-04] (15 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-01] (11 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-07] (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-05] (11 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-07] (22 pages) - TLS Client Authentication via DANE TLSA records [draft-ietf-dance-client-auth-06] (10 pages) - TLS Extension for DANE Client Identity [draft-ietf-dance-tls-clientid-04] (5 pages) - An Architecture for DNS-Bound Client and Sender Identities [draft-wilson-dance-architecture-02] (14 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-02] (7 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 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-02] (23 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-22] (41 pages) - Reliable and Available Wireless Framework [draft-ietf-raw-framework-02] (18 pages) - Reliable and Available Wireless Technologies [draft-ietf-raw-technologies-13] (65 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) RFC9633: Deterministic Networking (DetNet) YANG Data Model (126 pages) RFC9634: Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet) with the IP Data Plane (8 pages) 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-06] (142 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) - DHCPv4 over DHCPv6 with Relay Agent Support [draft-porfiri-dhc-dhcpv4-over-dhcpv6-ra-02] (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) 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-21] (28 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-35] (79 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) 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-13] (23 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) 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) - Deprecation of DNS64 for Discovery of IPv6 Prefix Used for IPv6 Address Synthesis [draft-buraglio-deprecate7050-00] (8 pages) - DNS Scoped Data Through '_Underscore' Attribute Leaves [draft-crocker-dns-attrleaf-07] (13 pages) - Documenting and Managing DNSSEC Algorithm Lifecycles [draft-crocker-dnsop-dnssec-algorithm-lifecycle-01] (6 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-20] (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) - Clarifications on CDS/CDNSKEY and CSYNC Consistency [draft-ietf-dnsop-cds-consistency-05] (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-05] (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-03] (12 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-06] (26 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-03] (17 pages) - DNS Glue Requirements in Referral Responses [draft-ietf-dnsop-glue-is-not-optional-09] (9 pages) - Greasing Protocol Extension Points in the DNS [draft-ietf-dnsop-grease-00] (8 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-01] (5 pages) - Remove SHA-1 from active use within DNSSEC [draft-ietf-dnsop-must-not-sha1-01] (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-02] (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) RFC9660: The DNS Zone Version (ZONEVERSION) Option (12 pages) Extensions for Scalable DNS Service Discovery (dnssd) ----------------------------------------------------- Charter Last Modified: 2024-10-29 Current Status: Active Chairs: Chris Box David Schinazi Florian Obser 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-05] (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-02] (38 pages) - DRIP Entity Tags (DET) in the Domain Name System (DNS) [draft-ietf-drip-registries-19] (18 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 Asynchronous Management Protocol (AMP) [draft-ietf-dtn-amp-00] (12 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-04] (5 pages) - DTN Management Architecture [draft-ietf-dtn-dtnma-14] (59 pages) - Bundle Protocol Endpoint ID Patterns [draft-ietf-dtn-eid-pattern-00] (21 pages) - Update to the ipn URI scheme [draft-ietf-dtn-ipn-update-14] (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) - Delay-Tolerant Networking UDP Convergence Layer Protocol Version 2 [draft-ietf-dtn-udpcl-00] (49 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) RFC9675: Delay-Tolerant Networking Management Architecture (DTNMA) (49 pages) 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) - Finding Tracking Tags [draft-fossaceca-dult-finding-00] (18 pages) - Detecting Unwanted Location Trackers Accessory Protocol [draft-ietf-dult-accessory-protocol-00] (37 pages) - Finding Tracking Tags [draft-ietf-dult-finding-00] (18 pages) - DULT Threat Model [draft-ietf-dult-threat-model-00] (14 pages) - Detecting Unwanted Location Trackers Accessory Protocol [draft-ledvina-dult-accessory-protocol-00] (37 pages) No Requests for Comments Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- Charter Last Modified: 2024-11-08 Current Status: Active Chairs: Brandon Abley 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-10] (22 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-02] (55 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-13] (20 pages) - Simple Mail Transfer Protocol [draft-ietf-emailcore-rfc5321bis-35] (121 pages) - Internet Message Format [draft-ietf-emailcore-rfc5322bis-12] (59 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-07] (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-03] (21 pages) - Using the Extensible Authentication Protocol (EAP) with Ephemeral Diffie-Hellman over COSE (EDHOC) [draft-ietf-emu-eap-edhoc-02] (24 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) 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-04] (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) RFC9671: Sieve Email Filtering: Extension for Processing Calendar Attachments (11 pages) 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 Getting Ready for Energy-Efficient Networking (green) ----------------------------------------------------- Charter Last Modified: 2024-10-09 Current Status: Active Chairs: Diego Lopez Robert Wilton Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari Operations and Management Area Advisor: Mahesh Jethanandani Mailing Lists: General Discussion: green@ietf.org To Subscribe: https://mailman3.ietf.org/mailman3/lists/green.ietf.org/ Archive: https://mailarchive.ietf.org/arch/browse/green/ Description of Working Group: #Background and Motivation Energy efficiency gains for communication systems are highly sought after for environmental, business, and technical reasons. Network operators seek tools and solutions to understand and manage the energy consumption of components, devices, and services across their networks, and support a robust and comprehensive energy efficiency strategy. An energy-efficient network involves deploying and managing network infrastructures to optimize energy use on network devices while achieving the network’s functional and performance requirements by improving overall network utilization. This includes adopting management plane technologies to monitor and manage energy consumption, evaluating the effectiveness of energy-aware policies beyond simply reducing consumption, and implementing management strategies that enhance overall energy efficiency in network operations. The EMAN Working Group previously worked on a closely related technology area, but the standards didn’t achieve wide industry adoption, and as illustrated in RFC 9547, the absence of standardized interfaces for measuring, reporting, and managing energy consumption across diverse network setups remains a significant challenge. #Goals and Scope The GREEN Working Group will examine the EMAN work to re-use where applicable but also consider updated operator input and requirements over those previously documented in RFC 6988. Similarly, it will examine the framework previously described in RFC 7326. It will develop new data models, specified in YANG rather than as MIBs. It is necessary to support heterogeneous deployment where energy-related statistics and management may be provided via other models and mechanisms. Guidance will be provided to operators in these heterogeneous environments to cover the incremental deployment of energy-efficient features in both network devices and the management of energy-efficient networks. The GREEN Working Group is chartered to explore use cases, derive requirements, and provide solutions for identifying and characterizing energy efficiency metrics, methods related to energy consumption of network devices, and optimizing energy efficiency across the network. The Working Group will concentrate on the following: - Collecting and updating requirements for the management of energy-efficient networks. - Defining use cases for managing energy-efficient networks. - Defining terms and definitions related to energy efficiency metrics. Where possible, terms and definitions in existing RFCs will be reused. - Developing YANG models to enable measuring and reporting of energy usage through metrics and attributes at component, device, and network levels. - Providing YANG models to allow operators to optimize energy usage in network components, devices, and across the network, via configurable energy efficiency capabilities. - Developing or selecting a framework for energy efficiency monitoring, energy efficiency capability discovery, and management within a network domain. Initially, the GREEN Working Group is expected to focus on simple foundational building blocks for new energy efficiency strategies for operators, such as the work items listed below, striving to illustrate industry implementation and adoption of the working group output before potentially considering more complex aspects of energy-efficient networks in a future charter. #Out of Scope To stay focused, the Working Group will not address energy-related issues in every networking area. Some topics are already covered in other venues while others may not be mature enough or present major shortcomings (e.g., have well-documented but unresolved security threats). The following topics are not currently within the scope of the Working Group: - Regulatory, compliance, and corporate responsibility-related matters. - Routing protocols and algorithms, including those that consider energy factors. - Methodologies for understanding the impact of energy efficiency optimization on service quality. - Methodologies for assessing environmental sustainability and related performance for the network devices. - The carbon accounting and reporting protocol to measure, manage, and report greenhouse gas emissions and other sustainability-related data such as renewable energy data. - Metadata formats for renewable energy or carbon-related data within the energy-efficient network's management system. #Work Items The GREEN Working Group will initially focus on the following deliverables: - Informational document(s) that (1) defines common terminology and metric definitions, (2) categorizes various types of metrics and measurements at component, device, and network levels. - Standard Track definitions of YANG data models at the component level, device level, and network level for energy-efficient network management including energy usage monitoring and energy consumption management. - Informational document(s) that (1) defines a set of architectural components for managing energy-efficient networks and (2) describes incremental deployment considerations for new energy efficiency metrics monitoring and capability discovery, and management within a network domain. #Dependencies and Liaisons **The GREEN Working Group will collaborate with:** - Other IETF Working Groups that address topics related to power consumption observability and energy efficiency management, such as IVY, OPSAWG, NETMOD, TVR, and INTAREA. - Working Groups that might have related work or expertise with defining and standardizing metrics, measurement frameworks, and benchmarking methodology (e.g., IPPM and BMWG). - The IAB e-impact program to identify short-term metrics-related work and propose longer-term problems for further study. **The GREEN Working Group will also liaise with other SDOs on benchmarking methodologies related to power management, mainly:** - The European Telecommunications Standards Institute (ETSI), particularly the Technical Committee of Environment Engineering (TCEE). - The International Telecommunication Union (ITU), specifically with ITU-T-SG-5. - 3GPP, specifically SA-5. Goals and Milestones: Jun 2025 - Adopt a standardized set of terminologies and definitions related to energy efficient metrics. Dec 2025 - Adopt YANG models to enable measuring, reporting, and management of energy usage at a component, device and network level. Jun 2026 - Adopt a framework for energy efficient monitoring, capability discovery, and management within a network domain. Internet-Drafts: No Requests for Comments 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-04] (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-05] (12 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-02] (11 pages) - BMP Peer Up Message Namespace [draft-ietf-grow-bmp-peer-up-05] (7 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-05] (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-06] (28 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) Building Blocks for HTTP APIs (httpapi) --------------------------------------- Charter Last Modified: 2024-01-17 Current Status: Active Chairs: Darrel Miller Rich Salz Web and Internet Transport Directors: Francesca Palombini Zaheduzzaman Sarker Web and Internet Transport Advisor: Francesca Palombini Secretary: Mark Nottingham Mailing Lists: General Discussion: httpapi@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/httpapi Archive: https://mailarchive.ietf.org/arch/browse/httpapi/ Description of Working Group: In addition to its use for web browsing, HTTP is often used for machine-to-machine communication, facilitated by HTTP APIs. This Working Group will standardise HTTP protocol extensions for use in such cases, with a focus on building blocks for separate or combined use. Its output can include the following: • Specifications for HTTP extensions that relate to HTTP APIs (typically, new HTTP header and/or trailer fields) • Specifications for new message body formats, or conventions for their use in HTTP APIs (e.g., patterns of JSON objects) • Best practices and other documentation for HTTP API designers, consumers, implementers, operators, etc. Other items are out of scope. In particular, this WG will not take on work items for HTTP APIs for specific applications or services, and it will not define new HTTP extension points. APIs for HTTP itself (e.g., in clients and servers) are also out of scope. To be successful, this Working Group will need to have active and broad representation from across the industry -- e.g., API gateway vendors (and other intermediaries), API consultants, API tool vendors, in-house API teams. Therefore, adopted proposals should have public support from multiple implementers and/or deployments before being sent to the IESG. To assess whether the group is functioning well, this charter will be reviewed by the IESG nine months after chartering. This Working Group will also need to coordinate closely with the HTTP Working Group, in particular when new methods and status codes are proposed. Work items that are more broadly applicable (e.g., for implementation in Web browsers) are likely to be more appropriate in the HTTP Working Group, but it is expected that coordination and discussion between the groups' Chairs and Area Director(s) will guide work items to the appropriate venue. Goals and Milestones: Jun 2024 - Send to IESG Jun 2024 - Send to IESG Mar 2025 - Enter WGLC Nov 2025 - Enter WGLC Internet-Drafts: - The Idempotency HTTP Header Field [draft-idempotency-header-01] (13 pages) - api-catalog: a well-known URI and link relation to help discovery of APIs [draft-ietf-httpapi-api-catalog-05] (14 pages) - Link relationship types for authentication [draft-ietf-httpapi-authentication-link-01] (5 pages) - The Deprecation HTTP Header Field [draft-ietf-httpapi-deprecation-header-09] (10 pages) - HTTP Problem Types for Digest Fields [draft-ietf-httpapi-digest-fields-problem-types-00] (9 pages) - The Idempotency-Key HTTP Header Field [draft-ietf-httpapi-idempotency-key-header-05] (12 pages) - HTTP Link Hints [draft-ietf-httpapi-link-hint-01] (12 pages) - Linkset: Media Types and a Link Relation Type for Link Sets [draft-ietf-httpapi-linkset-10] (31 pages) - The Link-Template HTTP Header Field [draft-ietf-httpapi-link-template-04] (6 pages) - Byte Range PATCH [draft-ietf-httpapi-patch-byterange-02] (19 pages) - API Keys and Privacy [draft-ietf-httpapi-privacy-00] (7 pages) - RateLimit header fields for HTTP [draft-ietf-httpapi-ratelimit-headers-08] (32 pages) - REST API Media Types [draft-ietf-httpapi-rest-api-mediatypes-06] (9 pages) - Problem Details for HTTP APIs [draft-ietf-httpapi-rfc7807bis-07] (16 pages) - YAML Media Type [draft-ietf-httpapi-yaml-mediatypes-10] (17 pages) - HTTP Link Hints [draft-nottingham-link-hint-03] (12 pages) - REST API mediatypes [draft-polli-rest-api-mediatypes-00] (9 pages) - API Keys and Privacy [draft-rsalz-httpapi-privacy-00] (7 pages) - api-catalog: A well-known URI to help discovery of APIs [draft-smith-api-catalog-03] (7 pages) - Linkset: Media Types and a Link Relation Type for Link Sets [draft-wilde-linkset-07] (29 pages) - Byte Range PATCH [draft-wright-http-patch-byterange-04] (19 pages) Requests for Comments: RFC9264: Linkset: Media Types and a Link Relation Type for Link Sets (31 pages) RFC9457: Problem Details for HTTP APIs (16 pages) RFC9512: YAML Media Type (13 pages) RFC9652: The Link-Template HTTP Header Field (5 pages) HTTP (httpbis) -------------- Charter Last Modified: 2024-02-22 Current Status: Active Chairs: Mark Nottingham Tommy Pauly Web and Internet Transport Directors: Francesca Palombini Zaheduzzaman Sarker Web and Internet Transport Advisor: Francesca Palombini Mailing Lists: General Discussion: ietf-http-wg@w3.org To Subscribe: ietf-http-wg-request@w3.org Archive: http://lists.w3.org/Archives/Public/ietf-http-wg/ Description of Working Group: This Working Group is charged with maintaining and developing the "core" specifications for HTTP, and generic extensions to it (i.e., those that are not specific to one application). Its current work items are: # HTTP/1.1 Revision After the revision of the core HTTP document set in the RFC723x series, the Working Group published HTTP/2, which defines an alternative mapping of HTTP's semantics to TCP, and introduced new capabilities, like Server Push. Additionally, several ambiguities, interoperability issues and errata have been identified since their publication. The Working Group will revise the "core" HTTP document set (RFC 7230-RFC 7235) to: * Incorporate errata * Address ambiguities * Fix editorial problems which have led to misunderstandings of the specification * Clarify conformance requirements * Remove known ambiguities where they affect interoperability * Clarify existing methods of extensibility * Remove or deprecate those features that are not widely implemented and also unduly affect interoperability * Where necessary, add implementation advice In doing so, it should consider: * Implementer experience * Demonstrated use of HTTP * Impact on existing implementations and deployments # HTTP and QUIC Upon request from the QUIC Working Group, the HTTPBIS Working Group will review the QUIC Working Group's documents regarding the use of HTTP over the transport protocol they define, providing feedback and collaborating where necessary. Once the QUIC Working Group publishes the expression of HTTP semantics in QUIC (HTTP/3), the HTTPBIS Working Group will maintain and develop extensions for HTTP/3 as necessary. This includes ancillary specifications (e.g. QPACK). # Other HTTP-Related Work The Working Group may define extensions and other documents related to HTTP as work items, provided that: * They are generic; i.e., not specific to one application using HTTP. Note that Web browsing by definition is a generic use. * The Working Group Chairs judge that there is consensus to take on the item and believe that it will not interfere with the work described above, and * The Area Director approves the addition and add corresponding milestones. Goals and Milestones: - Submit RFC6265bis (Cookies) - Submit Retrofit Structured Fields - Submit The HTTP QUERY Method - Submit Client-Cert Header - Submit Cache Groups - Submit Unprompted Auth - Submit Compression Dictionaries - Submit Resumable Uploads - Submit Secondary Server Certs Done - Submit the "core" HTTP documents for consideration as Internet Standards Done - Submit Client Hints Done - Submit Structured Headers Done - Submit Building Protocols with HTTP (BCP56bis) Done - Submit Cache-Status Header Done - Submit Proxy-Status Header Done - Submit Digest Headers Done - Submit Binary Representation of HTTP Messages Done - Submit ORIGIN in HTTP/3 Done - Submit HTTP Message Signatures Parked - Submit HTTP Representation Variants Parked - Submit HTTP Alternative Services Internet-Drafts: - Client-Cert HTTP Header: Conveying Client Certificate Information from TLS Terminating Reverse Proxies to Origin Server Applications [draft-bdc-something-something-certificate-05] (13 pages) - Secondary Certificate Authentication in HTTP/2 [draft-bishop-httpbis-http2-additional-certs-05] (21 pages) - The ORIGIN Extension in HTTP/3 [draft-bishop-httpbis-origin-h3-00] (3 pages) - Targeted HTTP Response Header Fields for Cache Control [draft-cdn-control-header-01] (8 pages) - Using TLS 1.3 with HTTP/2 [draft-davidben-http2-tls13-00] (4 pages) - Secondary Certificate Authentication of HTTP Servers [draft-egorbaty-httpbis-secondary-server-certs-01] (14 pages) - The Key HTTP Response Header Field [draft-fielding-http-key-03] (17 pages) - HTTP Client Hints [draft-grigorik-http-client-hints-03] (11 pages) - Bootstrapping WebSockets with HTTP/3 [draft-hamilton-httpbis-h3-websockets-01] (4 pages) - HTTP Proxy-Status Parameter for Next-Hop Aliases [draft-ietf-httpbis-alias-proxy-status-07] (8 pages) - HTTP Alternative Services [draft-ietf-httpbis-alt-svc-14] (20 pages) - HTTP Authentication [draft-ietf-httpbis-auth-01] (4 pages) - HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields [draft-ietf-httpbis-auth-info-05] (6 pages) - Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations [draft-ietf-httpbis-authscheme-registrations-10] (3 pages) - Building Protocols with HTTP [draft-ietf-httpbis-bcp56bis-15] (27 pages) - Binary Representation of HTTP Messages [draft-ietf-httpbis-binary-message-06] (16 pages) - HTTP Caching [draft-ietf-httpbis-cache-19] (35 pages) - Cache Digests for HTTP/2 [draft-ietf-httpbis-cache-digest-05] (17 pages) - HTTP Cache Groups [draft-ietf-httpbis-cache-groups-02] (7 pages) - The Cache-Status HTTP Response Header Field [draft-ietf-httpbis-cache-header-10] (9 pages) - Loop Detection in Content Delivery Networks (CDNs) [draft-ietf-httpbis-cdn-loop-02] (6 pages) - Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding [draft-ietf-httpbis-cice-03] (7 pages) - Client-Cert HTTP Header Field [draft-ietf-httpbis-client-cert-field-06] (14 pages) - HTTP Client Hints [draft-ietf-httpbis-client-hints-15] (10 pages) - Compression Dictionary Transport [draft-ietf-httpbis-compression-dictionary-19] (20 pages) - HTTP Conditional Requests [draft-ietf-httpbis-conditional-01] (4 pages) - Template-Driven HTTP CONNECT Proxying for TCP [draft-ietf-httpbis-connect-tcp-06] (14 pages) - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) [draft-ietf-httpbis-content-disp-09] (14 pages) - Deprecate modification of 'secure' cookies from non-secure origins [draft-ietf-httpbis-cookie-alone-01] (6 pages) - Cookie Prefixes [draft-ietf-httpbis-cookie-prefixes-00] (6 pages) - Same-Site Cookies [draft-ietf-httpbis-cookie-same-site-00] (14 pages) - Digest Fields [draft-ietf-httpbis-digest-headers-13] (42 pages) - An HTTP Status Code for Indicating Hints [draft-ietf-httpbis-early-hints-05] (7 pages) - Encrypted Content-Encoding for HTTP [draft-ietf-httpbis-encryption-encoding-09] (16 pages) - Expect-CT Extension for HTTP [draft-ietf-httpbis-expect-ct-08] (18 pages) - Bootstrapping WebSockets with HTTP/2 [draft-ietf-httpbis-h2-websockets-07] (8 pages) - Bootstrapping WebSockets with HTTP/3 [draft-ietf-httpbis-h3-websockets-04] (4 pages) - HPACK: Header Compression for HTTP/2 [draft-ietf-httpbis-header-compression-12] (55 pages) - Structured Field Values for HTTP [draft-ietf-httpbis-header-structure-19] (30 pages) - Hypertext Transfer Protocol Version 2 (HTTP/2) [draft-ietf-httpbis-http2-17] (96 pages) - HTTP/2 [draft-ietf-httpbis-http2bis-07] (78 pages) - Opportunistic Security for HTTP/2 [draft-ietf-httpbis-http2-encryption-11] (10 pages) - Secondary Certificate Authentication in HTTP/2 [draft-ietf-httpbis-http2-secondary-certs-06] (27 pages) - Using TLS 1.3 with HTTP/2 [draft-ietf-httpbis-http2-tls13-03] (5 pages) - HTTP Immutable Responses [draft-ietf-httpbis-immutable-03] (6 pages) - A JSON Encoding for HTTP Header Field Values [draft-ietf-httpbis-jfv-02] (13 pages) - The Key HTTP Response Header Field [draft-ietf-httpbis-key-01] (17 pages) - An HTTP Status Code to Report Legal Obstacles [draft-ietf-httpbis-legally-restricted-status-04] (5 pages) - HTTP Message Signatures [draft-ietf-httpbis-message-signatures-19] (118 pages) - HTTP/1.1 [draft-ietf-httpbis-messaging-19] (46 pages) - Initial Hypertext Transfer Protocol (HTTP) Method Registrations [draft-ietf-httpbis-method-registrations-15] (5 pages) - No-Vary-Search [draft-ietf-httpbis-no-vary-search-00] (13 pages) - Security Considerations for Optimistic Protocol Transitions in HTTP/1.1 [draft-ietf-httpbis-optimistic-upgrade-01] (9 pages) - The ORIGIN HTTP/2 Frame [draft-ietf-httpbis-origin-frame-06] (11 pages) - The ORIGIN Extension in HTTP/3 [draft-ietf-httpbis-origin-h3-03] (5 pages) - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing [draft-ietf-httpbis-p1-messaging-26] (89 pages) - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content [draft-ietf-httpbis-p2-semantics-26] (101 pages) - HTTP/1.1, part 3: Message Payload and Content Negotiation [draft-ietf-httpbis-p3-payload-20] (3 pages) - Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests [draft-ietf-httpbis-p4-conditional-26] (28 pages) - Hypertext Transfer Protocol (HTTP/1.1): Range Requests [draft-ietf-httpbis-p5-range-26] (25 pages) - Hypertext Transfer Protocol (HTTP/1.1): Caching [draft-ietf-httpbis-p6-cache-26] (43 pages) - Hypertext Transfer Protocol (HTTP/1.1): Authentication [draft-ietf-httpbis-p7-auth-26] (19 pages) - Extensible Prioritization Scheme for HTTP [draft-ietf-httpbis-priority-12] (21 pages) - The Proxy-Status HTTP Response Header Field [draft-ietf-httpbis-proxy-status-08] (22 pages) - HTTP Random Access and Live Content [draft-ietf-httpbis-rand-access-live-04] (10 pages) - HTTP Range Requests [draft-ietf-httpbis-range-01] (4 pages) - Using Early Data in HTTP [draft-ietf-httpbis-replay-04] (12 pages) - Resumable Uploads for HTTP [draft-ietf-httpbis-resumable-upload-05] (35 pages) - Retrofit Structured Fields for HTTP [draft-ietf-httpbis-retrofit-06] (13 pages) - Indicating Character Encoding and Language for HTTP Header Field Parameters [draft-ietf-httpbis-rfc5987bis-05] (13 pages) - Cookies: HTTP State Management Mechanism [draft-ietf-httpbis-rfc6265bis-15] (61 pages) - The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) [draft-ietf-httpbis-rfc7238bis-03] (6 pages) - HTTP Alternative Services [draft-ietf-httpbis-rfc7838bis-00] (20 pages) - The HTTP QUERY Method [draft-ietf-httpbis-safe-method-w-body-06] (13 pages) - Secondary Certificate Authentication of HTTP Servers [draft-ietf-httpbis-secondary-server-certs-01] (14 pages) - Security Requirements for HTTP [draft-ietf-httpbis-security-properties-05] (14 pages) - HTTP Semantics [draft-ietf-httpbis-semantics-19] (194 pages) - Structured Field Values for HTTP [draft-ietf-httpbis-sfbis-06] (43 pages) - Targeted HTTP Cache Control [draft-ietf-httpbis-targeted-cache-control-04] (8 pages) - The ALPN HTTP Header Field [draft-ietf-httpbis-tunnel-protocol-05] (7 pages) - The Concealed HTTP Authentication Scheme [draft-ietf-httpbis-unprompted-auth-12] (17 pages) - HTTP Representation Variants [draft-ietf-httpbis-variants-06] (23 pages) - Window Sizing for Zstandard Content Encoding [draft-ietf-httpbis-zstd-window-size-03] (5 pages) - Window Sizing for Zstandard Content Encoding [draft-jaju-httpbis-zstd-window-size-01] (4 pages) - Extensible Prioritization Scheme for HTTP [draft-kazuho-httpbis-priority-04] (20 pages) - Bootstrapping WebSockets with HTTP/2 [draft-mcmanus-httpbis-h2-websockets-02] (7 pages) - Compression Dictionary Transport [draft-meenan-httpbis-compression-dictionary-05] (14 pages) - The ORIGIN HTTP/2 Frame [draft-nottingham-httpbis-origin-frame-01] (4 pages) - HTTP Cache Groups [draft-nottingham-http-cache-groups-00] (6 pages) - Retrofit Structured Fields for HTTP [draft-nottingham-http-structure-retrofit-02] (14 pages) - The Proxy-Status HTTP Header Field [draft-nottingham-proxy-status-00] (17 pages) - HTTP Proxy-Status Parameter for Next-Hop Aliases [draft-pauly-httpbis-alias-proxy-status-00] (5 pages) - Signing HTTP Messages [draft-richanna-http-message-signatures-00] (38 pages) - HTTP Unprompted Authentication [draft-schinazi-httpbis-unprompted-auth-01] (9 pages) - Template-Driven HTTP CONNECT Proxying for TCP [draft-schwartz-httpbis-connect-tcp-01] (8 pages) - Security Considerations for Optimistic Use of HTTP Upgrade [draft-schwartz-httpbis-optimistic-upgrade-00] (9 pages) - HTTP SEARCH Method [draft-snell-search-method-02] (8 pages) - Reactive Certificate-Based Client Authentication in HTTP/2 [draft-thomson-http2-client-certs-02] (19 pages) - Binary Representation of HTTP Messages [draft-thomson-http-binary-message-01] (16 pages) - tus - Resumable Uploads Protocol [draft-tus-httpbis-resumable-uploads-protocol-02] (21 pages) - Incrementally Better Cookies [draft-west-cookie-incrementalism-01] (17 pages) - Same-site Cookies [draft-west-first-party-cookies-07] (14 pages) - No-Vary-Search [draft-wicg-http-no-vary-search-01] (13 pages) Requests for Comments: RFC6266: Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) (14 pages) RFC7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing (89 pages) * Updates RFC8615 * Obsoletes RFC9110 * Obsoletes RFC9112 RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content (101 pages) * Obsoletes RFC9110 RFC7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests (28 pages) * Obsoletes RFC9110 RFC7233: Hypertext Transfer Protocol (HTTP/1.1): Range Requests (25 pages) * Obsoletes RFC9110 RFC7234: Hypertext Transfer Protocol (HTTP/1.1): Caching (43 pages) * Obsoletes RFC9111 RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication (19 pages) * Obsoletes RFC9110 RFC7236: Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations (3 pages) RFC7237: Initial Hypertext Transfer Protocol (HTTP) Method Registrations (5 pages) RFC7538: The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) (6 pages) * Obsoletes RFC9110 RFC7540: Hypertext Transfer Protocol Version 2 (HTTP/2) (96 pages) * Updates RFC8740 * Obsoletes RFC9113 RFC7541: HPACK: Header Compression for HTTP/2 (55 pages) RFC7615: HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields (6 pages) * Obsoletes RFC9110 RFC7639: The ALPN HTTP Header Field (7 pages) RFC7694: Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding (7 pages) * Obsoletes RFC9110 RFC7725: An HTTP Status Code to Report Legal Obstacles (5 pages) RFC7838: HTTP Alternative Services (20 pages) RFC8164: Opportunistic Security for HTTP/2 (10 pages) RFC8187: Indicating Character Encoding and Language for HTTP Header Field Parameters (13 pages) RFC8188: Encrypted Content-Encoding for HTTP (16 pages) RFC8246: HTTP Immutable Responses (6 pages) RFC8297: An HTTP Status Code for Indicating Hints (7 pages) RFC8336: The ORIGIN HTTP/2 Frame (11 pages) RFC8441: Bootstrapping WebSockets with HTTP/2 (8 pages) RFC8470: Using Early Data in HTTP (12 pages) RFC8586: Loop Detection in Content Delivery Networks (CDNs) (6 pages) RFC8673: HTTP Random Access and Live Content (10 pages) RFC8740: Using TLS 1.3 with HTTP/2 (5 pages) * Obsoletes RFC9113 RFC8941: Structured Field Values for HTTP (30 pages) * Obsoletes RFC9651 RFC8942: HTTP Client Hints (10 pages) RFC9110: HTTP Semantics (194 pages) RFC9111: HTTP Caching (35 pages) RFC9112: HTTP/1.1 (46 pages) RFC9113: HTTP/2 (78 pages) RFC9163: Expect-CT Extension for HTTP (18 pages) RFC9205: Building Protocols with HTTP (27 pages) RFC9209: The Proxy-Status HTTP Response Header Field (22 pages) RFC9211: The Cache-Status HTTP Response Header Field (9 pages) RFC9213: Targeted HTTP Cache Control (8 pages) RFC9218: Extensible Prioritization Scheme for HTTP (21 pages) RFC9220: Bootstrapping WebSockets with HTTP/3 (4 pages) RFC9292: Binary Representation of HTTP Messages (16 pages) RFC9412: The ORIGIN Extension in HTTP/3 (5 pages) RFC9421: HTTP Message Signatures (95 pages) RFC9440: Client-Cert HTTP Header Field (14 pages) RFC9530: Digest Fields (32 pages) RFC9532: HTTP Proxy-Status Parameter for Next-Hop Aliases (7 pages) RFC9651: Structured Field Values for HTTP (35 pages) RFC9659: Window Sizing for Zstandard Content Encoding (4 pages) Inter-Domain Routing (idr) -------------------------- Charter Last Modified: 2024-11-04 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-24] (33 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-06] (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-03] (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-06] (12 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-08] (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-07] (52 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-08] (13 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-07] (10 pages) - Advertisement of Traffic Engineering Paths using BGP Link-State [draft-ietf-idr-bgp-ls-te-path-02] (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-18] (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-02] (10 pages) - Segment Routing Segment Types Extensions for BGP SR Policy [draft-ietf-idr-bgp-sr-segtypes-ext-06] (18 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 Characteristics Attribute [draft-ietf-idr-entropy-label-16] (22 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-24] (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-03] (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-06] (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-02] (51 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-11] (9 pages) - BGP Link Bandwidth Extended Community [draft-ietf-idr-link-bandwidth-09] (8 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-03] (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-03] (56 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-03] (7 pages) - BGP UPDATE for SD-WAN Edge Discovery [draft-ietf-idr-sdwan-edge-discovery-18] (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-09] (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-10] (11 pages) - SR Policy Extensions for Path Segment and Bidirectional Path [draft-ietf-idr-sr-policy-path-segment-13] (14 pages) - Advertising Segment Routing Policies in BGP [draft-ietf-idr-sr-policy-safi-10] (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-08] (28 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 * Updates RFC4724 * Updates RFC9687 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) RFC9687: Border Gateway Protocol 4 (BGP-4) Send Hold Timer (8 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) - Extending ICMP for Node Identification [draft-ietf-intarea-extended-icmp-nodeid-00] (9 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-02] (16 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-14] (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) 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-07] (54 pages) - A summary of security-enabling technologies for IoT devices [draft-ietf-iotops-security-summary-03] (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-02] (17 pages) - Performance Measurement with Asymmetrical Packets in STAMP [draft-ietf-ippm-asymmetrical-pkts-02] (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-10] (53 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-09] (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-03] (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-01] (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-05] (36 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 Headers [draft-ietf-ippm-stamp-ext-hdr-01] (18 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) IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Tero Kivinen Yoav Nir Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Deb Cooley Mailing Lists: General Discussion: ipsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: https://mailarchive.ietf.org/arch/browse/ipsec/ Description of Working Group: The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs, IKEv1 is now obsoleted), IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to ESP and IKEv2. The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols. The current work items include: IKEv1 using shared secret authentication was partially resistant to quantum computers. IKEv2 removed this feature to make the protocol more usable. The working group will add a mode to IKEv2 or otherwise modify the shared-secret mode of IKEv2 to have similar or better quantum resistant properties to those of IKEv1. Currently, widely used counter mode based ciphers send both the ESP sequence number and IV in the form of a counter, as they are very commonly the same. There has been interest to work on a document that will compress the packet and derive IV from the sequence number instead of sending it in separate field. The working group will specify how this compression can be negotiated in the IKEv2, and specify how the encryption algorithm and ESP format is used in this case. The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based protocol for negotiating group keys for both multicast and unicast uses. The Working Group will develop an IKEv2-based alternative that will include cryptographic updates. A possible starting point is draft-yeung-g-ikev2. Postquantum Cryptography brings new key exchange methods. Most of these methods that are known to date have much larger public keys than conventional Diffie-Hellman public keys. Directly using these methods in IKEv2 might lead to a number of problems due to the increased size of initial IKEv2 messages. The working group will analyze the possible problems and develop a solution, that will make adding Postquantum key exchange methods more easy. The solution will allow post quantum key exchange to be performed in parallel with (or instead of) the existing Diffie-Hellman key exchange. A growing number of use cases for constrained networks - but not limited to those networks - have shown interest in reducing ESP (resp. IKEv2) overhead by compressing ESP (resp IKEv2) fields. The WG will define extensions of ESP and IKEv2 to enable ESP header compression. Possible starting points are draft-mglt-ipsecme-diet-esp, draft-mglt-ipsecme-ikev2-diet-esp-extension, draft-smyslov-ipsecme-ikev2-compression and draft-smyslov-ipsecme-ikev2-compact. RFC7427 allows peers to indicate hash algorithms they support, thus eliminating ambiguity in selecting a hash function for digital signature authentication. However, advances in cryptography lead to a situation when some signature algorithms have several signature formats. A prominent example is RSASSA-PKCS#1 v 1.5 and RSASSA-PSS; however it is envisioned that the same situation may repeat in future with other signature algorithms. Currently IKE peers have no explicit way to indicate to each other which signature format(s) they support. That leads to interoperability problems. The WG will investigate the situation and come up with a solution that allows peers to deal with the problem in an interoperable way. RFC7296 defines a generic notification code that is related to a failure to handle an internal address failure. That code does not explicitly allow an initiator to determine why a given address family is not assigned, nor whether it should try using another address family. The Working Group will specify a set of more specific notification codes that will provide sufficient information to the IKEv2 initiator about the encountered failure. A possible starting pointing is draft-boucadair-ipsecme-ipv6-ipv4-codes. Some systems support security labels (aka security context) as one of the selectors of the SPD. This label needs to be part of the IKE negotiation for the IPsec SA. Non-standard implementations exist for IKEv1 (formerly abusing IPSEC Security Association Attribute 10, now using private space IPSEC Security Association Attribute 32001). The work is to standarize this for IKEv2, in a way that will be backwards compatible with old implementations, meaning it must not require any changes to implementations not supporting this. RFC8229, published in 2017, specifies how to encapsulate IKEv2 and ESP traffic in TCP. Implementation experience has revealed that not all situations are covered in RFC8229, and that may lead to interoperability problems or to suboptimal performance. The WG will provide a document to give implementors more guidance about how to use reliable stream transport in IKEv2 and clarify some issues that have been discovered. A possible starting point is draft-smyslov-ipsecme-tcp-guidelines. The demand for Traffic Flow Confidentiality has been increasing in the user community, but the current method defined in RFC4303 (adding null padding to each ESP payload) is very inefficient in its use of network resources. The working group will develop an alternative TFC solution that uses network resources more efficiently. Goals and Milestones: Jun 2021 - The ESP on contrained network to IESG Done - The internal address failure indication in IKEv2 to IESG Done - Traffic Flow Confidentiality document to IESG Done - Signature algorithm negotiation for IKEv2 to IESG Done - Postquantum cryptography document for IKEv2 to IESG Done - TCP-encapsulation guidelines document to IESG Done - G-DOI for IKEv2 to IESG Done - The security labels support for IKEv2 to IESG Internet-Drafts: - IKEv2 Notification Codes for IPv4/IPv6 Coexistence [draft-boucadair-ipsecme-ipv6-ipv4-codes-03] (6 pages) - Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS [draft-btw-add-ipsecme-ike-04] (13 pages) - Definitions of Managed Objects for IP Traffic Flow Security [draft-fedyk-ipsecme-mib-iptfs-00] (19 pages) - IP Traffic Flow Security YANG Module [draft-fedyk-ipsecme-yang-iptfs-02] (27 pages) - Postquantum Preshared Keys for IKEv2 [draft-fluhrer-qr-ikev2-04] (11 pages) - IP Traffic Flow Security [draft-hopps-ipsecme-iptfs-01] (25 pages) - Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS [draft-ietf-ipsecme-add-ike-14] (16 pages) - Auto-Discovery VPN Problem Statement and Requirements [draft-ietf-ipsecme-ad-vpn-problem-09] (12 pages) - Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol [draft-ietf-ipsecme-aes-ctr-ikev2-07] (6 pages) - ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec [draft-ietf-ipsecme-chacha20-poly1305-12] (13 pages) - Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks [draft-ietf-ipsecme-ddos-protection-10] (32 pages) - Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-dh-checks-05] (10 pages) - ESP Header Compression Profile [draft-ietf-ipsecme-diet-esp-02] (25 pages) - An Extension for EAP-Only Authentication in IKEv2 [draft-ietf-ipsecme-eap-mutual-05] (16 pages) - Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-eddsa-04] (5 pages) - Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) [draft-ietf-ipsecme-esp-ah-reqts-10] (11 pages) - Heuristics for Detecting ESP-NULL Packets [draft-ietf-ipsecme-esp-null-heuristics-07] (32 pages) - A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE) [draft-ietf-ipsecme-failure-detection-08] (22 pages) - Group Key Management using IKEv2 [draft-ietf-ipsecme-g-ikev2-16] (74 pages) - Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and Obsoleted Algorithms [draft-ietf-ipsecme-ikev1-algo-to-historic-09] (7 pages) - Announcing Supported Authentication Methods in IKEv2 [draft-ietf-ipsecme-ikev2-auth-announce-10] (14 pages) - Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-ikev2bis-11] (138 pages) - Internet Key Exchange version 2 (IKEv2) extension for Header Compression Profile (HCP) [draft-ietf-ipsecme-ikev2-diet-esp-extension-01] (13 pages) - Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation [draft-ietf-ipsecme-ikev2-fragmentation-10] (20 pages) - Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-ikev2-intermediate-10] (14 pages) - IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-ikev2-ipv6-config-03] (32 pages) - Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-ikev2-multiple-ke-12] (29 pages) - The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-ikev2-null-auth-07] (12 pages) - Mixing Preshared Keys in the IKE_INTERMEDIATE and in the CREATE_CHILD_SA Exchanges of IKEv2 for Post-quantum Security [draft-ietf-ipsecme-ikev2-qr-alt-04] (12 pages) - Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-ikev2-redirect-13] (15 pages) - Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption [draft-ietf-ipsecme-ikev2-resumption-09] (26 pages) - IKEv2 Optional SA&TS Payloads in Child Exchange [draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt-03] (9 pages) - Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP) [draft-ietf-ipsecme-implicit-iv-11] (8 pages) - IPsec Cluster Problem Statement [draft-ietf-ipsecme-ipsec-ha-09] (12 pages) - Protocol Support for High Availability of IKEv2/IPsec [draft-ietf-ipsecme-ipsecha-protocol-06] (26 pages) - Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS) [draft-ietf-ipsecme-iptfs-19] (31 pages) - Internet Key Exchange Protocol Version 2 (IKEv2) Notification Status Types for IPv4/IPv6 Coexistence [draft-ietf-ipsecme-ipv6-ipv4-codes-06] (7 pages) - Labeled IPsec Traffic Selector Support for the Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-labeled-ipsec-12] (7 pages) - Definitions of Managed Objects for IP Traffic Flow Security [draft-ietf-ipsecme-mib-iptfs-11] (19 pages) - IKEv2 support for per-resource Child SAs [draft-ietf-ipsecme-multi-sa-performance-09] (13 pages) - More Raw Public Keys for IKEv2 [draft-ietf-ipsecme-oob-pubkey-00] (8 pages) - Auto Discovery VPN Problem Statement and Requirements [draft-ietf-ipsecme-p2p-vpn-problem-02] (14 pages) - Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security [draft-ietf-ipsecme-qr-ikev2-11] (16 pages) - Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-rfc4307bis-18] (19 pages) - Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) [draft-ietf-ipsecme-rfc7321bis-06] (15 pages) - TCP Encapsulation of Internet Key Exchange Protocol (IKE) and IPsec Packets [draft-ietf-ipsecme-rfc8229bis-09] (30 pages) - IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap [draft-ietf-ipsecme-roadmap-10] (63 pages) - Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement [draft-ietf-ipsecme-safecurves-05] (8 pages) - Split DNS Configuration for the Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-split-dns-17] (16 pages) - TCP Encapsulation of IKE and IPsec Packets [draft-ietf-ipsecme-tcp-encaps-10] (25 pages) - Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility [draft-ietf-ipsecme-traffic-visibility-12] (15 pages) - A YANG Data Model for IP Traffic Flow Security [draft-ietf-ipsecme-yang-iptfs-11] (25 pages) - IKEv2 Optional SA&TS Payloads in Child Exchange [draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-10] (9 pages) - Internet Key Exchange Protocol Version 2 (IKEv2) [draft-kivinen-ipsecme-ikev2-rfc5996bis-04] (142 pages) - Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) [draft-kivinen-ipsecme-signature-auth-07] (18 pages) - ESP Header Compression Profile [draft-mglt-ipsecme-diet-esp-12] (27 pages) - Internet Key Exchange version 2 (IKEv2) extension for the ESP Header Compression (EHC) [draft-mglt-ipsecme-ikev2-diet-esp-extension-04] (8 pages) - Implicit IV for Counter-based Ciphers in IPsec [draft-mglt-ipsecme-implicit-iv-04] (7 pages) - Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) [draft-mglt-ipsecme-rfc7321bis-04] (13 pages) - Using Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange (IKEv2) [draft-nir-ipsecme-eddsa-01] (5 pages) - Split DNS Configuration for IKEv2 [draft-pauly-ipsecme-split-dns-02] (12 pages) - TCP Encapsulation of IKEv2 and IPSec Packets [draft-pauly-ipsecme-tcp-encaps-04] (18 pages) - Deprecation of IKEv1 and obsoleted algorithms [draft-pwouters-ikev1-ipsec-graveyard-06] (6 pages) - IKEv2 support for per-queue Child SAs [draft-pwouters-ipsecme-multi-sa-performance-05] (12 pages) - Announcing Supported Authentication Methods in IKEv2 [draft-smyslov-ipsecme-ikev2-auth-announce-04] (9 pages) - Intermediate Exchange in the IKEv2 Protocol [draft-smyslov-ipsecme-ikev2-aux-02] (10 pages) - Alternative Approach for Mixing Preshared Keys in IKEv2 for Post-quantum Security [draft-smyslov-ipsecme-ikev2-qr-alt-09] (11 pages) - TCP Encapsulation of IKE and IPsec Packets [draft-smyslov-ipsecme-rfc8229bis-02] (29 pages) - Framework to Integrate Post-quantum Key Exchanges into Internet Key Exchange Protocol Version 2 (IKEv2) [draft-tjhai-ipsecme-hybrid-qske-ikev2-04] (21 pages) - Group Key Management using IKEv2 [draft-yeung-g-ikev2-16] (52 pages) Requests for Comments: RFC5685: Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) (15 pages) RFC5723: Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption (26 pages) RFC5739: IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) (32 pages) RFC5840: Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility (15 pages) RFC5879: Heuristics for Detecting ESP-NULL Packets (32 pages) RFC5930: Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol (6 pages) RFC5996: Internet Key Exchange Protocol Version 2 (IKEv2) (138 pages) * Updates RFC5998 * Updates RFC6989 * Updates RFC6989 * Obsoletes RFC7296 RFC5998: An Extension for EAP-Only Authentication in IKEv2 (16 pages) RFC6027: IPsec Cluster Problem Statement (12 pages) RFC6071: IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap (63 pages) RFC6290: A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE) (22 pages) RFC6311: Protocol Support for High Availability of IKEv2/IPsec (26 pages) RFC6989: Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2) (10 pages) RFC7018: Auto-Discovery VPN Problem Statement and Requirements (12 pages) RFC7296: Internet Key Exchange Protocol Version 2 (IKEv2) (142 pages) * Updates RFC7427 * Updates RFC7670 * Updates RFC8247 * Updates RFC8983 * Updates RFC9370 RFC7321: Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) (11 pages) * Obsoletes RFC8221 RFC7383: Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation (20 pages) RFC7427: Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) (18 pages) RFC7619: The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2) (12 pages) RFC7634: ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec (13 pages) RFC8019: Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks (32 pages) RFC8031: Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement (8 pages) RFC8221: Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) (15 pages) * Updates RFC9395 RFC8229: TCP Encapsulation of IKE and IPsec Packets (25 pages) * Obsoletes RFC9329 RFC8247: Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2) (19 pages) * Updates RFC9395 RFC8420: Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2) (5 pages) RFC8598: Split DNS Configuration for the Internet Key Exchange Protocol Version 2 (IKEv2) (16 pages) RFC8750: Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP) (8 pages) RFC8784: Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security (16 pages) RFC8983: Internet Key Exchange Protocol Version 2 (IKEv2) Notification Status Types for IPv4/IPv6 Coexistence (7 pages) RFC9242: Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2) (14 pages) RFC9329: TCP Encapsulation of Internet Key Exchange Protocol (IKE) and IPsec Packets (30 pages) RFC9347: Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS) (31 pages) RFC9348: A YANG Data Model for IP Traffic Flow Security (25 pages) RFC9349: Definitions of Managed Objects for IP Traffic Flow Security (19 pages) RFC9370: Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2) (29 pages) RFC9395: Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and Obsoleted Algorithms (7 pages) RFC9464: Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS (16 pages) RFC9478: Labeled IPsec Traffic Selector Support for the Internet Key Exchange Protocol Version 2 (IKEv2) (7 pages) RFC9593: Announcing Supported Authentication Methods in the Internet Key Exchange Protocol Version 2 (IKEv2) (13 pages) RFC9611: Internet Key Exchange Protocol Version 2 (IKEv2) Support for Per-Resource Child Security Associations (SAs) (9 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 YANG Data Model for Network Inventory Location [draft-ietf-ivy-network-inventory-location-00] (18 pages) - A Network Inventory Topology Model [draft-ietf-ivy-network-inventory-topology-00] (18 pages) - A Base YANG Data Model for Network Inventory [draft-ietf-ivy-network-inventory-yang-04] (32 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 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: Nov 2024 - Submit Webpush Vapid document to IESG Dec 2024 - Adopt a draft for File Storage Dec 2024 - Submit Portability Guide (Minimal Profile) to IESG Dec 2024 - Adopt a draft for Push Filtering Mar 2025 - Adopt a document for JMAP Archive format Mar 2025 - Submit SMIME Sender Extensions document to the IESG Apr 2025 - Submit REST Mapping document to IESG Apr 2025 - Submit Portability Extensions to IESG Jul 2025 - Submit JMAP Tasks document to 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 - Adopt a document for creating Blobs via JMAP method call Done - Submit JMAP S/MIME signature validation document to the IESG 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 Contacts document to the IESG Done - Submit Sieve document to the IESG Done - Submit JMAP Sharing document to IESG Done - Adopt a draft for a basic migration simplified endpoint Done - Adopt a document for JMAP REST mapping Done - Adopt a document for Server info and debug 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) - JMAP File Storage extension [draft-gondwana-jmap-filenode-00] (12 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) - JSON Meta Application Protocol (JMAP) for Calendars [draft-ietf-jmap-calendars-22] (61 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) RFC9661: The JSON Meta Application Protocol (JMAP) for Sieve Scripts (21 pages) Javascript Object Signing and Encryption (jose) ----------------------------------------------- Charter Last Modified: 2024-08-22 Current Status: Active Chairs: John Bradley John Preuß Mattsson Karen O'Donoghue Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Deb Cooley Mailing Lists: General Discussion: jose@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/jose Archive: https://mailarchive.ietf.org/arch/browse/jose/ Description of Working Group: The original [JSON Object Signing and Encryption (JOSE) working group][1] standardized JSON-based representations for: Integrity-protected objects (JSON Web Signatures/JWS, RFC 7515), Encrypted objects (JSON Web Encryption/JWE, RFC7516), Key representations (JSON Web Key/JWK, RFC 7517), Algorithm definitions (JSON Web Algorithms/JWA, RFC 7518), and Test vectors for the above (Examples of Protecting Content Using JSON Object Signing and Encryption, RFC 7520). These were used to define the JSON Web Token (JWT) (RFC 7519), which in turn, has seen widespread deployment in areas as diverse as [digital identity][2] and [secure telephony][3]. As adoption of these standards to express and communicate sensitive data has grown, so too has an increasing societal focus on privacy. User consent, minimal disclosure, and unlinkability are common privacy themes in identity solutions. A multi-decade research activity for a sizeable academic and applied cryptography community has focused on these privacy and knowledge mechanisms (often referred to as anonymous credentials). Certain cryptographic techniques developed in this space involve pairing-friendly curves and zero-knowledge proofs (ZKPs) (to name just a few). Some of the benefits of ZKP algorithms include unlinkability, selective disclosure, and the ability to use predicate proofs. The current container formats defined by JOSE and JWT are not able to represent data using ZKP algorithms. Among the reasons are that most require an additional transform or finalize step, many are designed to operate on sets and not single messages, and the interface to ZKP algorithms has more inputs than conventional signing algorithms. The reconstituted JOSE working group will address these new needs, while reusing aspects of JOSE and JWT, where applicable. This group is chartered to work on the following goals: - An Informational document detailing Use Cases and Requirements for new specifications enabling JSON-based selective disclosure and zero-knowledge proofs. - Standards Track document(s) specifying representation(s) of independently-disclosable integrity-protected sets of data and/or proofs using JSON-based data structures, which also aims to prevent the ability to correlate by different verifiers. - Standards Track document(s) specifying representation(s) of JSON-based claims and/or proofs enabling selective disclosure of these claims and/or proofs, and that also aims to prevent the ability to correlate by different verifiers. - Standards Track document(s) specifying how to use existing cryptographic algorithms and defining their algorithm identifiers. The working group will not invent new cryptographic algorithms. - Standards Track document(s) specifying how to represent keys for these new algorithms as JSON Web Keys (JWKs). - Informational document(s) defining test vectors for these new specifications. - Standards Track document(s) defining CBOR-based representations corresponding to all the above, building upon the COSE and CWT specifications in the same way that the above build on JOSE and JWT. One or more of these goals may be combined into a single document, in which case the concrete milestones for these goals will be satisfied by the consolidated document(s). The JOSE working group will also maintain the JOSE standard and facilitate discussion of clarifications, improvements, and extensions to JWS, JWE, JWA, and JWK. The WG will evaluate, and potentially adopt, proposed standard 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 may also publish informational and BCP documents describing the proper use of these algorithms in JOSE. An informal goal of the working group is close coordination with the [rechartered W3C Verifiable Credentials WG][4], which has taken a dependency on this work for the second version of its Verifiable Credentials specification. The working group will also coordinate with the [Selective Disclosure JWT][5] work in the [OAuth][6] working group, the [Privacy Pass][7] working group, the [CBOR][8] working group, the [COSE][10] working group, and the [CFRG][9]. [1]: https://datatracker.ietf.org/doc/charter-ietf-jose/02/ [2]: https://openid.net/connect/ [3]: https://www.ietf.org/blog/stir-action/ [4]: https://www.w3.org/2022/05/proposed-vc-wg-charter.html [5]: https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/ [6]: https://datatracker.ietf.org/wg/oauth/about/ [7]: https://datatracker.ietf.org/wg/privacypass/about/ [8]: https://datatracker.ietf.org/wg/cbor/about/ [9]: https://datatracker.ietf.org/rg/cfrg/about/ [10]: https://datatracker.ietf.org/wg/cose/about/ Goals and Milestones: Jan 2024 - Adopt document registering cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed (as proposed standard) Apr 2024 - Adopt document describing the use of the NIST algorithm ML-KEM in JOSE (as proposed standard) Apr 2024 - Adopt document describing the use of the NIST algorithm ML-DSA in JOSE (as proposed standard) Apr 2024 - Adopt document describing the use of the NIST algorithm SLH-DSA in JOSE (as proposed standard) Apr 2025 - Adopt document describing the use of the NIST algorithm FN-DSA in JOSE (as proposed standard) Internet-Drafts: - CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE) [draft-ietf-jose-cfrg-curves-06] (14 pages) - Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE) [draft-ietf-jose-cookbook-08] (120 pages) - JOSE: Deprecate 'none' and 'RSA1_5' [draft-ietf-jose-deprecate-none-rsa15-00] (7 pages) - Fully-Specified Algorithms for JOSE and COSE [draft-ietf-jose-fully-specified-algorithms-06] (28 pages) - Use of Hybrid Public Key Encryption (HPKE) with JSON Object Signing and Encryption (JOSE) [draft-ietf-jose-hpke-encrypt-02] (19 pages) - JSON Proof Algorithms [draft-ietf-jose-json-proof-algorithms-07] (41 pages) - JSON Proof Token [draft-ietf-jose-json-proof-token-07] (10 pages) - JSON Web Algorithms (JWA) [draft-ietf-jose-json-web-algorithms-40] (69 pages) - JSON Web Encryption (JWE) [draft-ietf-jose-json-web-encryption-40] (51 pages) - JSON Web Key (JWK) [draft-ietf-jose-json-web-key-41] (40 pages) - JSON Web Proof [draft-ietf-jose-json-web-proof-07] (32 pages) - JSON Web Signature (JWS) [draft-ietf-jose-json-web-signature-41] (59 pages) - JSON Web Key (JWK) Thumbprint [draft-ietf-jose-jwk-thumbprint-08] (13 pages) - JSON Web Signature (JWS) Unencoded Payload Option [draft-ietf-jose-jws-signing-input-options-09] (11 pages) - Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for JOSE and COSE [draft-ietf-jose-pqc-kem-00] (19 pages) - Use Cases and Requirements for JSON Object Signing and Encryption (JOSE) [draft-ietf-jose-use-cases-06] (25 pages) - JSON Proof Algorithms [draft-jmiller-jose-json-proof-algorithms-01] (28 pages) - JSON Proof Token [draft-jmiller-jose-json-proof-token-01] (7 pages) - JSON Web Proof [draft-jmiller-jose-json-web-proof-01] (21 pages) - Fully-Specified Algorithms for JOSE and COSE [draft-jones-jose-fully-specified-algorithms-02] (11 pages) - JWS Signing Input Options [draft-jones-jose-jws-signing-input-options-00] (11 pages) - JOSE: Deprecate 'none' and 'RSA1_5' [draft-madden-jose-deprecate-none-rsa15-01] (7 pages) - Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for JOSE and COSE [draft-reddy-cose-jose-pqc-kem-03] (19 pages) - Use of Hybrid Public Key Encryption (HPKE) with JSON Object Signing and Encryption (JOSE) [draft-rha-jose-hpke-encrypt-07] (19 pages) - Guidance for COSE and JOSE Protocol Designers and Implementers [draft-tschofenig-jose-cose-guidance-01] (6 pages) Requests for Comments: RFC7165: Use Cases and Requirements for JSON Object Signing and Encryption (JOSE) (25 pages) RFC7515: JSON Web Signature (JWS) (59 pages) RFC7516: JSON Web Encryption (JWE) (51 pages) RFC7517: JSON Web Key (JWK) (40 pages) RFC7518: JSON Web Algorithms (JWA) (69 pages) RFC7520: Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE) (120 pages) RFC7638: JSON Web Key (JWK) Thumbprint (13 pages) RFC7797: JSON Web Signature (JWS) Unencoded Payload Option (11 pages) RFC8037: CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE) (14 pages) Key Transparency (keytrans) --------------------------- Charter Last Modified: 2024-07-22 Current Status: Active Chairs: Prachi Jain Shivan Kaul Sahib Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Deb Cooley Mailing Lists: General Discussion: keytrans@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/keytrans Archive: https://mailarchive.ietf.org/arch/browse/keytrans/ Description of Working Group: ## Background Public keys used to provide end-to-end encrypted communication services are often authenticated solely by the assertion of the communications service provider (e.g., a video conferencing or instant messaging service providers). As a result, the underlying encryption protocols are left vulnerable to eavesdropping and impersonation by a service provider which distributes malicious public keys. To provide confidence to their users and to mitigate this attack, end-to-end encrypted communication service providers are increasingly looking to an authentication service to provide verifiability for identity-to-public-key bindings in the context of their service. A scheme for providing this verifiability of key bindings must be: * Transparent: All end users (applications or devices) receive a globally consistent view of the data associated with each identity. * User-friendly: Little (ideally zero) user action, or even awareness of the system, is required to verify a user’s key bindings. * Private: The authentication service used by the service provider only reveals information about specific users, such as what keys are associated with an identity, or even whether or not a specific identity is registered by the service provider, to clients authorized to ask about that user * Efficient: The computational requirements for the end user and the service provider should be practical to deploy for internet scale numbers of keys and for typical end-user devices. ## Goals The KEYTRANS working group will develop a standard for providing verifiability for identity-to-public-key bindings in an authentication service for an end-to-end encrypted communication service. This standard will: * Allow an end-user to search and download the public keys of themselves or for other end-users; and enable a process for updating their public key with the authentication service of the communication service provider * Allow end-users to verify on an ongoing basis that they have a globally consistent view of which public keys have been associated with which accounts, including their own. * Allow end-users to perform this verification of a globally consistent view via an out-of-band mechanism for small groups, or use an anonymous check with the communication service provider in-band for larger groups. This standardized approach is not stand-alone and will need to be integrated into other, more complete end-to-end protocols and services. It is not the goal of this WG to enable interoperability between end-to-end encrypted services as full interoperability of an application would require alignment at many different layers beyond security. ## Program of Work The WG is expected to: * Specify an architecture for this public verifiability mechanism (as an informational status document(s)) * Standardize the core scheme for providing verifiability for identity-to-public-key bindings in an authentication service for an end-to-end encrypted communication service (as a proposed standard document(s)) The WG may standardize integrations of this verifiability mechanism with other protocols (where the exact security guarantees provided will depend on the underlying encryption) The WG will work collaboratively with the MIMI, MLS and SCITT WGs as appropriate. Goals and Milestones: Dec 2023 - Initial WG adoption of an architecture document Mar 2024 - Initial WG adoption of core transparent verifiability mechanism document Jul 2024 - Initial WG adoption of MLS integration document Mar 2025 - Submit architecture document to the IESG as Informational Nov 2025 - Submit core transparent verifiability mechanism document to IESG as Proposed Standard Nov 2025 - Submit MLS integration document to IESG as Proposed Standard Internet-Drafts: - Key Transparency Architecture [draft-ietf-keytrans-architecture-02] (23 pages) - Key Transparency Architecture [draft-mcmillion-keytrans-architecture-01] (13 pages) No Requests for Comments Common Authentication Technology Next Generation (kitten) --------------------------------------------------------- Charter Last Modified: 2023-05-02 Current Status: Active Chairs: Alexey Melnikov Benjamin Kaduk Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Paul Wouters Mailing Lists: General Discussion: kitten@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/kitten Archive: https://mailarchive.ietf.org/arch/browse/kitten/ Description of Working Group: The purpose of the Common Authentication Technology Next Generation (Kitten) working group (WG) is to develop extensions/improvements to the GSS-API and to the Kerberos authentication system, shepherd specific GSS-API security mechanisms, and provide guidance for any new SASL-related submissions. This charter combines the work of the Kerberos WG and the kitten WG (under the aegis of the kitten WG). In places, it identifies which WG was previously home for that work. The working group will develop extensions and/or updates to the GSS-API, working on specific items regarding credential management, replay cache avoidance, error reporting, and supporting stateless and/or distributed acceptors. The working group will also maintain and improve upon the Kerberos protocol, working on items regarding internationalization considering alignment with the precis work, new initial authentication types, authorization framework/data, replay cache avoidance, cryptography advances, interop with 3rd party authentication, and identity management. In detail, both existing and new work items include: Existing Working Group Items --------------------------- SASL Mechanism for OAuth (draft-ietf-kitten-sasl-oauth) SASL Mechansim for SAML-EC (draft-ietf-kitten-sasl-saml-ec) GSS-API IANA Registry (draft-ietf-kitten-gssapi-extensions-iana) KDC Model (draft-ietf-krb-wg-kdc-model) PKINIT Hash Agility (draft-ietf-krb-wg-pkinit-alg-agility) Kerberos IANA Registry (draft-ietf-kitten-kerberos-iana-registries) Initial and Pass Through Authentication in Kerberos 5 (draft-ietf-krb-wg-iakerb) Unencrypted Portion of Ticket Extensions (draft-ietf-krb-wg-ticket-extensions) GSS-API Related --------------- Provide new interfaces for credential management, which include the following: initializing credentials iterating credentials exporting/importing credentials Negotiable replay cache avoidance Define interfaces for better error message reporting. Specify an option for exporting partially-established security contexts and possibly a utility function for exporting security contexts in an encrypted form, as well as a corresponding utility function to decrypt and import such security context tokens. Specify one-time password / two-factor authentication needs for SASL applications. This could be achieved through an explicit new GSS-API/SASL mechanism (e.g., http://tools.ietf.org/html/draft-josefsson-kitten-crotp-00) or if the consensus is that due to usability reasons, it is preferable to do OTP/2FA through an higher level protocol (Kerberos/OpenID/SAML/SAML20EC/EAP?) then prepare a document explaining the usability problem and provide pointers for implementers. Kerberos Related ---------------- Prepare, review, and advance standards-track and informational specifications defining new authorization data types for carrying supplemental information about the client to which a Kerberos ticket has been issued and/or restrictions on what the ticket can be used for. To enhance this ongoing authorization data work, a container format supporting the use cases of draft-ietf-krb-wg-pad may be standardized. Prepare a standards-track protocol to solve the use cases addressed by draft-hotz-kx509-01 including new support for digital signatures. Today Kerberos requires a replay cache to be used in AP exchanges in almost all cases. Replay caches are quite complex to implement correctly, particularly in clustered systems. High-performance replay caches are even more difficult to implement. The WG will pursue extensions to minimize the need for replay caching, optimize replay caching, and/or elide the need for replay caching. Prepare, review, and advance standards-track and informational specifications defining use of new cryptographic algorithms in the Kerberos protocol using the RFC3961 framework, on an ongoing basis. Cryptographic algorithms intended for standards track status must be of good quality, have broad international support, and fill a definite need. Prepare, review, and advance standards-track and informational specifications of new pre-authentication types for the Kerberos protocol, on an ongoing basis. Prepare, review, and advance standards track updates and extensions to RFC4121, as needed and on an ongoing basis. Goals and Milestones: May 2013 - draft-ietf-kitten-gssapi-extensions-iana to IESG Jun 2013 - draft-ietf-kitten-kerberos-iana-registries to IESG Jun 2013 - draft-ietf-krb-wg-pad to IESG Jul 2013 - Adopt work on better error reporting in the GSS-API Jul 2013 - Adopt work on one or more items for GSS-API cred management Aug 2013 - Adopt work on exporting partially-established GSS-API contexts Aug 2013 - draft-ietf-krb-wg-ticket-extensions to IESG Sep 2013 - Adopt work on the GSS-API for replay cache avoidance Mar 2022 - Submit "SPAKE Pre-Authentication" document to IESG Apr 2022 - Decide on preferred solution(s) for 2-Factor Authentication in SASL Oct 2022 - Submit document on 2-Factor Authentication in SASL to IESG Nov 2022 - Submit "Best practices for password hashing and storage" to IESG Dec 2022 - draft-ietf-kitten-sasl-saml-ec to IESG Done - draft-ietf-kitten-sasl-oauth to IESG Done - draft-ietf-krb-wg-cammac to IESG Done - draft-ietf-krb-wg-pkinit-alg-agility to IESG Done - Submit "Channel Bindings for TLS 1.3" to IESG Internet-Drafts: - The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism [draft-ietf-kitten-2478bis-05] (22 pages) - AES Encryption with HMAC-SHA2 for Kerberos 5 [draft-ietf-kitten-aes-cbc-hmac-sha2-00] (15 pages) - AES Encryption with HMAC-SHA2 for Kerberos 5 [draft-ietf-kitten-aes-cts-hmac-sha2-11] (19 pages) - Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs) [draft-ietf-kitten-cammac-04] (10 pages) - Channel Binding Signalling for the Generic Security Services Application Programming Interface [draft-ietf-kitten-channel-bound-flag-04] (9 pages) - Moving DIGEST-MD5 to Historic [draft-ietf-kitten-digest-to-historic-04] (6 pages) - Extended Generic Security Service Mechanism Inquiry APIs [draft-ietf-kitten-extended-mech-inquiry-06] (16 pages) - Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings [draft-ietf-kitten-gssapi-channel-bindings-07] (4 pages) - GSS_API V2: C# Bindings [draft-ietf-kitten-gssapi-csharp-bindings-00] (95 pages) - Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type [draft-ietf-kitten-gssapi-domain-based-names-06] (9 pages) - Namespace Considerations and Registries for GSS-API Extensions [draft-ietf-kitten-gssapi-extensions-iana-11] (13 pages) - Generic Security Service Application Programming Interface (GSS-API) Naming Extensions [draft-ietf-kitten-gssapi-naming-exts-15] (18 pages) - A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API) [draft-ietf-kitten-gssapi-prf-07] (8 pages) - GSS-API V2: Java & C# Bindings [draft-ietf-kitten-gssapi-rfc2853-update-for-csharp-00] (10 pages) - Generic Security Service Application Program Interface (GSS-API) Extension for Storing Delegated Credentials [draft-ietf-kitten-gssapi-store-cred-04] (7 pages) - Guide to the GSS-APIv3 [draft-ietf-kitten-gssapi-v3-guide-to-01] (22 pages) - Structure of the Generic Security Service (GSS) Negotiation Loop [draft-ietf-kitten-gss-loop-05] (21 pages) - Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming [draft-ietf-kitten-gss-naming-05] (12 pages) - A Simple Anonymous GSS-API Mechanism [draft-ietf-kitten-gss-sanon-01] (11 pages) - Initial and Pass Through Authentication Using Kerberos V5 and the GSS- API (IAKERB) [draft-ietf-kitten-iakerb-03] (13 pages) - Move Kerberos protocol parameter registries to IANA [draft-ietf-kitten-kerberos-iana-registries-04] (9 pages) - Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism [draft-ietf-kitten-krb5-gssapi-domain-based-names-05] (5 pages) - A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism [draft-ietf-kitten-krb5-gssapi-prf-04] (5 pages) - Authentication Indicator in Kerberos Tickets [draft-ietf-kitten-krb-auth-indicator-07] (6 pages) - Kerberos Service Discovery using DNS [draft-ietf-kitten-krb-service-discovery-00] (9 pages) - Kerberos SPAKE Pre-Authentication [draft-ietf-kitten-krb-spake-preauth-13] (37 pages) - Best practices for password hashing and storage [draft-ietf-kitten-password-storage-07] (13 pages) - Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Algorithm Agility [draft-ietf-kitten-pkinit-alg-agility-08] (21 pages) - Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension [draft-ietf-kitten-pkinit-freshness-07] (9 pages) - Generic Security Service API Version 2: Java Bindings Update [draft-ietf-kitten-rfc2853bis-05] (99 pages) - A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism [draft-ietf-kitten-rfc4402bis-02] (8 pages) - Generic Security Service API Version 2: Java Bindings Update [draft-ietf-kitten-rfc5653bis-07] (96 pages) - Anonymity Support for Kerberos [draft-ietf-kitten-rfc6112bis-03] (18 pages) - A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth [draft-ietf-kitten-sasl-oauth-23] (21 pages) - A Simple Authentication and Security Layer (SASL) and Generic Security Service Application Program Interface (GSS-API) Mechanism for OpenID [draft-ietf-kitten-sasl-openid-08] (18 pages) - A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML) [draft-ietf-kitten-sasl-saml-09] (22 pages) - SAML Enhanced Client SASL and GSS-API Mechanisms [draft-ietf-kitten-sasl-saml-ec-20] (34 pages) - Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication [draft-ietf-kitten-scram-2fa-04] (12 pages) - Stackable Generic Security Service Pseudo-Mechanisms [draft-ietf-kitten-stackable-pseudo-mechs-02] (17 pages) - Channel Bindings for TLS 1.3 [draft-ietf-kitten-tls-channel-bindings-for-tls13-16] (7 pages) - Kerberos Authorization Data Container Authenticated by Multiple MACs [draft-ietf-krb-wg-cammac-11] (9 pages) - PKINIT Algorithm Agility [draft-ietf-krb-wg-pkinit-alg-agility-07] (18 pages) - Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication [draft-melnikov-scram-2fa-03] (7 pages) - Best practices for password hashing and storage [draft-whited-kitten-password-storage-04] (13 pages) - Channel Bindings for SCRAM over TLS 1.3 [draft-whited-tls-channel-bindings-for-tls13-02] (5 pages) Requests for Comments: RFC4178: The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism (22 pages) RFC4401: A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API) (8 pages) RFC4402: A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism (5 pages) * Obsoletes RFC7802 RFC4768: Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming (12 pages) RFC5178: Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type (9 pages) RFC5179: Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism (5 pages) RFC5554: Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings (4 pages) RFC5587: Extended Generic Security Service Mechanism Inquiry APIs (16 pages) RFC5588: Generic Security Service Application Program Interface (GSS-API) Extension for Storing Delegated Credentials (7 pages) RFC5653: Generic Security Service API Version 2: Java Bindings Update (99 pages) * Obsoletes RFC8353 RFC6331: Moving DIGEST-MD5 to Historic (6 pages) RFC6595: A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML) (22 pages) RFC6616: A Simple Authentication and Security Layer (SASL) and Generic Security Service Application Program Interface (GSS-API) Mechanism for OpenID (18 pages) RFC6680: Generic Security Service Application Programming Interface (GSS-API) Naming Extensions (18 pages) RFC7546: Structure of the Generic Security Service (GSS) Negotiation Loop (21 pages) RFC7628: A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth (21 pages) RFC7751: Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs) (10 pages) RFC7802: A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism (8 pages) RFC8009: AES Encryption with HMAC-SHA2 for Kerberos 5 (19 pages) RFC8062: Anonymity Support for Kerberos (18 pages) RFC8070: Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension (9 pages) RFC8129: Authentication Indicator in Kerberos Tickets (6 pages) RFC8353: Generic Security Service API Version 2: Java Bindings Update (96 pages) RFC8636: Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Algorithm Agility (21 pages) RFC9266: Channel Bindings for TLS 1.3 (7 pages) RFC9588: Kerberos Simple Password-Authenticated Key Exchange (SPAKE) Pre-authentication (33 pages) Lightweight Authenticated Key Exchange (lake) --------------------------------------------- Charter Last Modified: 2024-08-01 Current Status: Active Chairs: Mališa Vučinić Stephen Farrell Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Paul Wouters Mailing Lists: General Discussion: lake@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lake Archive: https://mailarchive.ietf.org/arch/browse/lake/ Description of Working Group: EDHOC (draft-ietf-lake-edhoc), an output of the LAKE working group, defines a lightweight authenticated key exchange protocol between two peers. EDHOC is intended to be used in constrained network environments such as NB-IoT, 6TiSCH and LoRaWAN. By publishing EDHOC, the base protocol specification, and the lake-traces document, the LAKE working group has completed its initial goals. The working group will continue to work on maintaining and extending the base protocol specification as appropriate. The initial design scope of EDHOC ruled out authentication based on pre-shared symmetric keys and focused on asymmetric authentication credentials (e.g., raw public keys and public key certificates) in order to streamline the working group activities. Similarly, the base protocol specification does not define a protocol for rekeying but rather a rekeying function to use as an inner building block for key update. The working group now will define a Standards Track EDHOC rekeying protocol reusing the protocol elements from the base specification that uses symmetric keys for authentication, to make those usable both during a key update and a first-time key exchange. Within each protocol message, EDHOC provides External Authorization Data (EAD) fields. These fields may be used by external security applications to reduce the number of messages and round trips, or to simplify processing. The working group will specify Standards Track documents with the following uses of EAD fields to augment the EDHOC key exchange: - 3rd party-assisted authorization of EDHOC peers. Draft-selander-lake-authz is a candidate starting point for this work. - Remote attestation of EDHOC peers, reusing as much as possible available work from the RATS and TLS working groups. - Status verification of EDHOC peer authentication credentials transported during an EDHOC key exchange (e.g. OCSP stapling). The working group will also work on a Standard Track means for coordinating the use and discovery of EDHOC application profiles, the definition of a well-known application profile and processing extensions through EDHOC’s defined extension points, such as registering new schemes and new EAD registrations. In addition, the working group will work on an Informational document gathering implementation considerations and guidance for the base protocol specification. Goals and Milestones: Jun 2024 - Implementation considerations and guidance submitted to IESG as Informational RFC Jun 2024 - 3rd party-assisted authorization of EDHOC submitted to IESG as Proposed Standard Nov 2024 - EDHOC rekeying protocol submitted to IESG as Proposed Standard Nov 2024 - Remote attestation of EDHOC peers submitted to IESG as Proposed Standard Mar 2025 - Verification of EDHOC authentication credentials submitted to IESG as Proposed Standard Internet-Drafts: - Applying Generate Random Extensions And Sustain Extensibility (GREASE) to EDHOC Extensibility [draft-amsuess-lake-edhoc-grease-01] (8 pages) - Lightweight Authorization using Ephemeral Diffie-Hellman Over COSE (ELA) [draft-ietf-lake-authz-03] (42 pages) - Ephemeral Diffie-Hellman Over COSE (EDHOC) [draft-ietf-lake-edhoc-23] (113 pages) - Implementation Considerations for Ephemeral Diffie-Hellman Over COSE (EDHOC) [draft-ietf-lake-edhoc-impl-cons-02] (36 pages) - Requirements for a Lightweight AKE for OSCORE [draft-ietf-lake-reqs-04] (25 pages) - Traces of EDHOC [draft-ietf-lake-traces-09] (61 pages) - EDHOC PSK authentication [draft-lopez-lake-edhoc-psk-02] (10 pages) - Lightweight Authorization using Ephemeral Diffie-Hellman Over COSE [draft-selander-lake-authz-03] (28 pages) - Requirements for a Lightweight AKE for OSCORE [draft-selander-lake-reqs-04] (19 pages) - Remote attestation over EDHOC [draft-song-lake-ra-02] (26 pages) - Coordinating the Use of Application Profiles for Ephemeral Diffie-Hellman Over COSE (EDHOC) [draft-tiloca-lake-app-profiles-03] (32 pages) - Implementation Considerations for Ephemeral Diffie-Hellman Over COSE (EDHOC) [draft-tiloca-lake-edhoc-implem-cons-01] (25 pages) Requests for Comments: RFC9528: Ephemeral Diffie-Hellman Over COSE (EDHOC) (82 pages) RFC9529: Traces of Ephemeral Diffie-Hellman Over COSE (EDHOC) (62 pages) Limited Additional Mechanisms for PKIX and SMIME (lamps) -------------------------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Russ Housley Tim Hollebeek Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Deb Cooley Mailing Lists: General Discussion: spasm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/spasm Archive: https://mailarchive.ietf.org/arch/browse/spasm/ Description of Working Group: The PKIX and S/MIME Working Groups have been closed for some time. Some updates have been proposed to the X.509 certificate documents produced by the PKIX Working Group and the electronic mail security documents produced by the S/MIME Working Group. The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working Group is chartered to make updates where there is a known constituency interested in real deployment and there is at least one sufficiently well specified approach to the update so that the working group can sensibly evaluate whether to adopt a proposal. The LAMPS WG is now tackling these topics: 1. Specify the use of short-lived X.509 certificates for which no revocation information is made available by the Certification Authority. Short-lived certificates have a lifespan that is shorter than the time needed to detect, report, and distribute revocation information. As a result, revoking short-lived certificates is unnecessary and pointless. 2. Update the specification for the cryptographic protection of email headers -- both for signatures and encryption -- to improve the implementation situation with respect to privacy, security, usability and interoperability in cryptographically-protected electronic mail. Most current implementations of cryptographically-protected electronic mail protect only the body of the message, which leaves significant room for attacks against otherwise-protected messages. 3. The Certificate Management Protocol (CMP) is specified in RFC 4210, and it offers a vast range of certificate management options. CMP is currently being used in many different industrial environments, but it needs to be tailored to the specific needs of such machine-to-machine scenarios and communication among PKI management entities. The LAMPS WG will develop a "lightweight" profile of CMP to more efficiently support of these environments and better facilitate interoperable implementation, while preserving cryptographic algorithm agility. In addition, necessary updates and clarifications to CMP will be specified in a separate document. This work will be coordinated with the LWIG WG. 4. Provide concrete guidance for implementers of email user agents to promote interoperability of end-to-end cryptographic protection of email messages. This may include guidance about the generation, interpretation, and handling of protected messages; management of the relevant certificates; documentation of how to avoid common failure modes; strategies for deployment in a mixed environment; as well as test vectors and examples that can be used by implementers and interoperability testing. The resulting robust consensus among email user agent implementers is expected to provide more usable and useful cryptographic security for email users. 5. Recent progress in the development of quantum computers pose a threat to widely deployed public key algorithms. As a result, there is a need to prepare for a day when cryptosystems such as RSA, Diffie-Hellman, ECDSA, ECDH, and EdDSA cannot be depended upon in the PKIX and S/MIME protocols. 5.a. The US National Institute of Standards and Technology (NIST) has a Post-Quantum Cryptography (PQC) effort to produce one or more quantum-resistant public-key cryptographic algorithm standards. The LAMPS WG will specify the use of these new PQC public key algorithms with the PKIX certificates and the Cryptographic Message Syntax (CMS). These specifications will use object identifiers for the new algorithms that are assigned by NIST. 5.b. A lengthy transition from today's public key algorithms to PQC public key algorithms is expected. Time will be needed to gain full confidence in the new PQC public key algorithms. 5.b.i. The LAMPS WG will specify formats, identifiers, enrollment, and operational practices for "hybrid key establishment" that combines the shared secret values one or more traditional key-establishment algorithm and one or more NIST PQC key-establishment algorithm or a PQC key-establishment algorithm vetted by the CFRG. The shared secret values will be combined using HKDF (see RFC 5869), one of the key derivation functions in NIST SP 800-56C, or a key derivation function vetted by the CFRG. 5.b.ii. The LAMPS WG will specify formats, identifiers, enrollment, and operational practices for "dual signature" that combine one or more traditional signature algorithm with one or more NIST PQC signature algorithm or a PQC algorithm vetted by the CFRG. In addition, the LAMPS WG may investigate other updates to documents produced by the PKIX and S/MIME WG. The LAMPS WG may produce clarifications where needed, but the LAMPS WG shall not adopt anything beyond clarifications without rechartering. Goals and Milestones: Jul 2021 - Adopt a draft for short-lived certificate conventions Oct 2021 - Adopt draft for PQC KEM public keys in PKIX certificates Oct 2021 - Adopt draft for PQC KEM algorithms in CMS Nov 2021 - Header protection conventions sent to IESG for standards track publication Dec 2021 - Adopt draft for PQC signatures in CMS Dec 2021 - CMP updates sent to IESG for standards track publication Dec 2021 - Lightweight CMP profile sent to IESG for informational publication Dec 2021 - Adopt draft for PQC signatures in PKIX certificates Dec 2021 - Adopt draft for public keys for hybrid key establishment in PKIX certificates Dec 2021 - Adopt draft for hybrid key establishment in CMS Dec 2021 - Adopt draft for dual signatures in PKIX certificates Dec 2021 - Adopt draft for dual signature in CMS Dec 2021 - CMP algorithms sent to IESG for standards track publication Mar 2022 - Short-lived certificate conventions sent to IESG for BCP publication Jul 2022 - End-to-end email user agent guidance sent to IESG for informational publication Dec 2022 - Send draft for rfc6712bis to IESG for standards track publication Dec 2022 - Send draft for rfc4210bis to IESG for standards track publication Done - Adopt a draft for end-to-end email user agent guidance Done - Adopt draft for rfc6712bis Done - Adopt draft for rfc4210bis Internet-Drafts: - Related Certificates for Use in Multiple Authentications within a Protocol [draft-becker-guthrie-cert-binding-for-multi-auth-02] (14 pages) - Certification Authority Authorization (CAA) Processing for Email Addresses [draft-bonnell-caa-issuemail-01] (7 pages) - Updates to Lightweight OCSP Profile for High Volume Environments [draft-bonnell-rfc5019bis-03] (18 pages) - Guidance on End-to-End E-mail Security [draft-dkg-lamps-e2e-mail-guidance-01] (25 pages) - Internet X.509 Public Key Infrastructure: Algorithm Identifiers for HSS and XMSS [draft-gazdag-x509-shbs-00] (15 pages) - Internet X.509 Public Key Infrastructure: Algorithm Identifiers for SLH-DSA [draft-gazdag-x509-slhdsa-00] (16 pages) - DNS Certification Authority Authorization (CAA) Resource Record [draft-hoffman-andrews-caa-simplification-03] (19 pages) - Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS) [draft-housley-lamps-cms-aes-mac-alg-00] (7 pages) - Encryption Key Derivation in the Cryptographic Message Syntax (CMS) using HKDF with SHA-256 [draft-housley-lamps-cms-cek-hkdf-sha256-01] (14 pages) - Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection [draft-housley-lamps-cms-update-alg-id-protect-00] (8 pages) - Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) [draft-housley-lamps-crmf-update-algs-01] (4 pages) - Use of the RSA-KEM Algorithm in the Cryptographic Message Syntax (CMS) [draft-housley-lamps-rfc5990bis-00] (23 pages) - Online Certificate Status Protocol (OCSP) Nonce Extension [draft-hsharma-lamps-ocsp-nonce-update-06] (5 pages) - Clarifications for Elliptic Curve Cryptography Subject Public Key Information [draft-ietf-lamps-5480-ku-clarifications-03] (3 pages) - X.509 Certificate Extension for 5G Network Function Types [draft-ietf-lamps-5g-nftypes-08] (11 pages) - Clarifications for Ed25519, Ed448, X25519, and X448 Algorithm Identifiers [draft-ietf-lamps-8410-ku-clarifications-02] (5 pages) - Nonce-based Freshness for Remote Attestation in Certificate Signing Requests (CSRs) for the Certification Management Protocol (CMP) and for Enrollment over Secure Transport (EST) [draft-ietf-lamps-attestation-freshness-03] (16 pages) - Certification Authority Authorization (CAA) Processing for Email Addresses [draft-ietf-lamps-caa-issuemail-07] (8 pages) - Related Certificates for Use in Multiple Authentications within a Protocol [draft-ietf-lamps-cert-binding-for-multi-auth-05] (15 pages) - Certificate Management Protocol (CMP) Algorithms [draft-ietf-lamps-cmp-algorithms-15] (28 pages) - Certificate Management Protocol (CMP) Updates [draft-ietf-lamps-cmp-updates-23] (55 pages) - Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-cms-aes-gmac-alg-05] (9 pages) - Encryption Key Derivation in the Cryptographic Message Syntax (CMS) using HKDF with SHA-256 [draft-ietf-lamps-cms-cek-hkdf-sha256-05] (14 pages) - Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-cms-hash-sig-10] (14 pages) - Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-cms-kemri-08] (17 pages) - Use of ML-KEM in the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-cms-kyber-05] (20 pages) - Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-cms-mix-with-psk-07] (31 pages) - Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-cms-ml-dsa-00] (14 pages) - Use of the SHA3 One-way Hash Functions in the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-cms-sha3-hash-04] (20 pages) - Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-cms-shakes-18] (16 pages) - Use of the SLH-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-cms-sphincs-plus-14] (19 pages) - Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection [draft-ietf-lamps-cms-update-alg-id-protect-05] (8 pages) - Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) [draft-ietf-lamps-crmf-update-algs-07] (9 pages) - Use of Remote Attestation with Certification Signing Requests [draft-ietf-lamps-csr-attestation-14] (42 pages) - Internet X.509 Public Key Infrastructure: Algorithm Identifiers for ML-DSA [draft-ietf-lamps-dilithium-certificates-05] (27 pages) - X.509 Certificate General-Purpose Extended Key Usage (EKU) for Document Signing [draft-ietf-lamps-documentsigning-eku-06] (8 pages) - Guidance on End-to-End E-mail Security [draft-ietf-lamps-e2e-mail-guidance-16] (67 pages) - Internationalized Email Addresses in X.509 Certificates [draft-ietf-lamps-eai-addresses-18] (12 pages) - Hash Of Root Key Certificate Extension [draft-ietf-lamps-hash-of-root-key-cert-extn-07] (10 pages) - Header Protection for Cryptographically Protected E-mail [draft-ietf-lamps-header-protection-24] (269 pages) - Problem Statement and Requirements for Header Protection [draft-ietf-lamps-header-protection-requirements-01] (24 pages) - X.509 Certificate Extended Key Usage (EKU) for Instant Messaging URIs [draft-ietf-lamps-im-keyusage-03] (6 pages) - Key Attestation Extension for Certificate Management Protocols [draft-ietf-lamps-key-attestation-ext-00] (14 pages) - Use of KYBER in the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-kyber-00] (16 pages) - Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) [draft-ietf-lamps-kyber-certificates-06] (19 pages) - Lightweight Certificate Management Protocol (CMP) Profile [draft-ietf-lamps-lightweight-cmp-profile-21] (83 pages) - X.509 Certificate Extended Key Usage (EKU) for 5G Network Functions [draft-ietf-lamps-nf-eku-05] (11 pages) - No Revocation Available for X.509 Public Key Certificates [draft-ietf-lamps-norevavail-04] (10 pages) - Online Certificate Status Protocol (OCSP) Nonce Extension [draft-ietf-lamps-ocsp-nonce-05] (6 pages) - Online Certificate Status Protocol (OCSP) Nonce Extension [draft-ietf-lamps-ocsp-nonce-update-11] (14 pages) - Use of Password Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax [draft-ietf-lamps-pkcs12-pbmac1-09] (17 pages) - Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs [draft-ietf-lamps-pkix-shake-15] (14 pages) - Composite ML-KEM for use in X.509 Public Key Infrastructure and CMS [draft-ietf-lamps-pq-composite-kem-05] (56 pages) - Composite ML-DSA For use in X.509 Public Key Infrastructure and CMS [draft-ietf-lamps-pq-composite-sigs-03] (69 pages) - Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates [draft-ietf-lamps-rfc3709bis-10] (39 pages) - Internet X.509 Public Key Infrastructure -- Certificate Management Protocol (CMP) [draft-ietf-lamps-rfc4210bis-14] (140 pages) - Updates to Lightweight OCSP Profile for High Volume Environments [draft-ietf-lamps-rfc5019bis-12] (36 pages) - Certificate Management over CMS (CMC) [draft-ietf-lamps-rfc5272bis-01] (106 pages) - Certificate Management over CMS (CMC): Transport Protocols [draft-ietf-lamps-rfc5273bis-01] (10 pages) - Certificate Management Messages over CMS (CMC): Compliance Requirements [draft-ietf-lamps-rfc5274bis-01] (14 pages) - Internationalization Updates to RFC 5280 [draft-ietf-lamps-rfc5280-i18n-update-04] (9 pages) - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling [draft-ietf-lamps-rfc5750-bis-08] (29 pages) - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification [draft-ietf-lamps-rfc5751-bis-12] (63 pages) - Use of the RSA-KEM Algorithm in the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-rfc5990bis-10] (33 pages) - Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP) [draft-ietf-lamps-rfc6712bis-07] (13 pages) - DNS Certification Authority Authorization (CAA) Resource Record [draft-ietf-lamps-rfc6844bis-07] (17 pages) - Clarification and enhancement of RFC7030 CSR Attributes definition [draft-ietf-lamps-rfc7030-csrattrs-13] (23 pages) - Clarification of Enrollment over Secure Transport (EST): Transfer Encodings and ASN.1 [draft-ietf-lamps-rfc7030est-clarify-10] (13 pages) - Update to the Object Identifier Registry for the PKIX Working Group [draft-ietf-lamps-rfc7299-update-02] (4 pages) - Internationalized Email Addresses in X.509 Certificates [draft-ietf-lamps-rfc8398bis-05] (14 pages) - Internationalization Updates to RFC 5280 [draft-ietf-lamps-rfc8399bis-05] (11 pages) - Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-rfc8708bis-03] (15 pages) - Use of Password-Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax [draft-ietf-lamps-rfc9579bis-03] (18 pages) - S/MIME Example Keys and Certificates [draft-ietf-lamps-samples-08] (32 pages) - Updates to X.509 Policy Validation [draft-ietf-lamps-x509-policy-graph-05] (22 pages) - Use of the HSS and XMSS Hash-Based Signature Algorithms in Internet X.509 Public Key Infrastructure [draft-ietf-lamps-x509-shbs-09] (35 pages) - Internet X.509 Public Key Infrastructure: Algorithm Identifiers for SLH-DSA [draft-ietf-lamps-x509-slhdsa-02] (30 pages) - General Purpose Extended Key Usage (EKU) for Document Signing X.509 Certificates [draft-ito-documentsigning-eku-02] (8 pages) - X.509 Certificate Extended Key Usage (EKU) for Instant Messaging URIs [draft-mahy-lamps-im-keyusage-01] (5 pages) - Certificate Management over CMS (CMC) [draft-mandel-lamps-rfc5272bis-02] (99 pages) - Certificate Management over CMS (CMC): Transport Protocols [draft-mandel-lamps-rfc5273bis-02] (9 pages) - Certificate Management Messages over CMS (CMC): Compliance Requirements [draft-mandel-lamps-rfc5274bis-02] (14 pages) - Clarifications for Ed25519, Ed448, X25519, and X448 Algorithm Identifiers [draft-mtis-lamps-8410-ku-clarifications-01] (5 pages) - Use of Attestation with Certification Signing Requests [draft-ounsworth-csr-attestation-00] (15 pages) - Composite KEM For Use In Internet PKI [draft-ounsworth-pq-composite-kem-02] (22 pages) - Use of Post-Quantum KEM in the Cryptographic Message Syntax (CMS) [draft-perret-prat-lamps-cms-pq-kem-01] (15 pages) - X.509 Certificate Extended Key Usage (EKU) for (JOSE) and CBOR Object Signing and Encryption (COSE) [draft-reddy-lamps-jose-eku-02] (11 pages) - Clarification of RFC7030 CSR Attributes definition [draft-richardson-lamps-rfc7030-csrattrs-04] (7 pages) - Clarification of Enrollment over Secure Transport (EST): transfer encodings and ASN.1 [draft-richardson-lamps-rfc7030est-clarify-05] (10 pages) - Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS) [draft-salter-lamps-cms-ml-dsa-00] (13 pages) - Nonce-based Freshness for Remote Attestation in Certificate Signing Requests (CSRs) for the Certification Management Protocol (CMP) and for Enrollment over Secure Transport (EST) [draft-tschofenig-lamps-nonce-cmp-est-01] (12 pages) - Clarifications for Elliptic Curve Cryptogtaphy Subject Public Key Information [draft-turner-5480-ku-clarifications-01] (3 pages) - Key Attestation Extension for Certificate Management Protocols [draft-wallace-lamps-key-attestation-ext-01] (14 pages) Requests for Comments: RFC8398: Internationalized Email Addresses in X.509 Certificates (12 pages) * Obsoletes RFC9598 RFC8399: Internationalization Updates to RFC 5280 (9 pages) * Obsoletes RFC9549 RFC8550: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling (29 pages) RFC8551: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification (63 pages) RFC8649: Hash Of Root Key Certificate Extension (10 pages) RFC8659: DNS Certification Authority Authorization (CAA) Resource Record (17 pages) RFC8692: Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs (14 pages) RFC8696: Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) (31 pages) RFC8702: Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS) (16 pages) RFC8708: Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS) (14 pages) RFC8813: Clarifications for Elliptic Curve Cryptography Subject Public Key Information (3 pages) RFC8933: Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection (8 pages) RFC8951: Clarification of Enrollment over Secure Transport (EST): Transfer Encodings and ASN.1 (13 pages) RFC8954: Online Certificate Status Protocol (OCSP) Nonce Extension (6 pages) * Obsoletes RFC9654 RFC9044: Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS) (9 pages) RFC9045: Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) (9 pages) RFC9158: Update to the Object Identifier Registry for the PKIX Working Group (4 pages) RFC9216: S/MIME Example Keys and Certificates (32 pages) RFC9295: Clarifications for Ed25519, Ed448, X25519, and X448 Algorithm Identifiers (5 pages) RFC9310: X.509 Certificate Extension for 5G Network Function Types (11 pages) RFC9336: X.509 Certificate General-Purpose Extended Key Usage (EKU) for Document Signing (8 pages) RFC9399: Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates (39 pages) RFC9480: Certificate Management Protocol (CMP) Updates (55 pages) RFC9481: Certificate Management Protocol (CMP) Algorithms (28 pages) RFC9483: Lightweight Certificate Management Protocol (CMP) Profile (83 pages) RFC9495: Certification Authority Authorization (CAA) Processing for Email Addresses (8 pages) RFC9509: X.509 Certificate Extended Key Usage (EKU) for 5G Network Functions (9 pages) RFC9549: Internationalization Updates to RFC 5280 (10 pages) RFC9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax (15 pages) RFC9598: Internationalized Email Addresses in X.509 Certificates (12 pages) RFC9608: No Revocation Available for X.509 Public Key Certificates (10 pages) RFC9618: Updates to X.509 Policy Validation (19 pages) RFC9629: Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS) (15 pages) RFC9654: Online Certificate Status Protocol (OCSP) Nonce Extension (13 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-17] (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-15] (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) - LISP Multicast Overlay Group to Underlay RLOC Mappings [draft-ietf-lisp-group-mapping-01] (10 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-05] (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:Large-Area Dynamic Comprehension Based On H3 and LISP [draft-ietf-lisp-nexagon-54] (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-15] (17 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-01] (7 pages) - LISP Traffic Engineering [draft-ietf-lisp-te-20] (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-22] (80 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-01] (6 pages) - IS-IS Distributed Flooding Reduction [draft-ietf-lsr-distoptflood-07] (13 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-15] (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-03] (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) - YANG Data Model for IS-IS L2 Bundle Member Link Attributes PICS [draft-ietf-lsr-isis-pics-l2member-attr-yang-00] (9 pages) - YANG Data Model for IS-IS Segment Routing MPLS PICS [draft-ietf-lsr-isis-pics-srmpls-yang-00] (14 pages) - YANG Model for IS-IS Protocol Implementation Conformance Statement (PICS) [draft-ietf-lsr-isis-pics-yang-00] (10 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-06] (27 pages) - Extensions to OSPF for Advertising Prefix Administrative Tags [draft-ietf-lsr-ospf-admin-tags-22] (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-01] (9 pages) - Prefix Flag Extension for OSPFv2 and OSPFv3 [draft-ietf-lsr-ospf-prefix-extended-flags-03] (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) RFC9666: Area Proxy for IS-IS (17 pages) RFC9667: Dynamic Flooding on Dense Graphs (41 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: Sep 2024 - LSVR with standard Dijkstra path selection Sep 2024 - LSV distribution using BGP transport Oct 2024 - Applicability statement for LSVR in DCs Mar 2025 - YANG specification for LSVR Internet-Drafts: - Usage and Applicability of Link State Vector Routing in Data Centers [draft-ietf-lsvr-applicability-14] (14 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-38] (39 pages) - Layer-3 Discovery and Liveness [draft-ietf-lsvr-l3dl-13] (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 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: Nov 2024 - Use Cases and Identity Requirements (informational) document submitted to the IESG for publication Done - MAC Address Randomization current state-of-affairs (informational) 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: Context, Network Impacts and Use Cases [draft-ietf-madinas-use-cases-12] (20 pages) - MAC address randomization [draft-zuniga-madinas-mac-address-randomization-01] (15 pages) No Requests for Comments 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: Nov 2024 - Call for adoption of draft-gulbrandsen-smtputf8-syntax Nov 2024 - Call for Adoption of draft-eggert-uidbatches Nov 2024 - Call for Adoption of draft-eggert-mailflagcolors Nov 2024 - Call for Adoption of draft-jenkins-mail-keywords Nov 2024 - Call for Adoption of draft-jenkins-oauth-public Nov 2024 - Call for adoption of draft-gulbrandsen-smtputf8-nice-addresses 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 - Discuss where work on updating/clarifying SMTPUTF8 should be done 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) - mAuth - OAuth2 profile for mail apps and other public clients [draft-bucksch-mauth-00] (8 pages) - Adding a Wrong Recipient URL for Handling Misdirected Emails [draft-dweekly-wrong-recipient-06] (9 pages) - IMAP "$MailFlagBit" Keywords [draft-eggert-mailflagcolors-00] (6 pages) - IMAP UIDBATCHES Extension [draft-eggert-uidbatches-00] (9 pages) - Nice Email Addresses for SMTPUTF8 [draft-gulbrandsen-smtputf8-nice-addresses-01] (12 pages) - SMTPUTF8 address syntax [draft-gulbrandsen-smtputf8-syntax-00] (7 pages) - Mail Autoconfig [draft-ietf-mailmaint-autoconfig-00] (21 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) - Registration of further IMAP/JMAP keywords and mailbox names [draft-jenkins-mail-keywords-00] (13 pages) - OAuth Profile for Open Public Clients [draft-jenkins-oauth-public-01] (17 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 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-01] (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-01] (6 pages) - DLEP Radio Quality Extension [draft-ietf-manet-dlep-radio-quality-01] (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) Multiplexed Application Substrate over QUIC Encryption (masque) --------------------------------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Dennis Jackson Eric Kinnear Web and Internet Transport Directors: Francesca Palombini Zaheduzzaman Sarker Web and Internet Transport Advisor: Zaheduzzaman Sarker Mailing Lists: General Discussion: masque@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/masque Archive: https://mailarchive.ietf.org/arch/browse/masque/ Description of Working Group: Many network topologies lead to situations where transport protocol proxying is beneficial. For example, proxying enables endpoints to communicate when end-to-end connectivity is not possible or to apply additional encryption where desirable (such as a VPN). Proxying can also improve client privacy, e.g., by hiding a client's IP address from a target server. Proxying technologies such as SOCKS and HTTP(S) CONNECT exist, albeit with their own shortcomings. For example, SOCKS signalling is not encrypted and HTTP CONNECT is currently limited to TCP. The primary goal of this working group is to develop mechanism(s) that allow configuring and concurrently running multiple proxied stream- and datagram-based flows inside an HTTP connection. The group has specified CONNECT-UDP and CONNECT-IP, collectively known as MASQUE, to enable this functionality. MASQUE leverages the HTTP request/response semantics, multiplexes flows over streams, uses a unified congestion controller, encrypts flow metadata, and enables unreliable delivery suitable for UDP and IP-based applications. The MASQUE working group will now develop HTTP extensions, which might be specific to the HTTP version, to the core client-initiated CONNECT-UDP and CONNECT-IP functionality. Services that a proxy initiates without any prompt from a client are out of scope. Exercising the extension points defined by CONNECT-UDP and CONNECT-IP helps to make it easier to support new use cases or accommodate changes in the environment in which these protocols are deployed. The initial set of extensions will be in support of UDP listening, CONNECT-UDP proxying optimizations when the UDP traffic is QUIC, and tunneling of Ethernet packets. Additional extensions that provide missing functionality, improve performance, or otherwise ease deployability for use cases may be adopted where there are multiple implementation and/or deployment proponents. The intended status is Standards Track, but the WG may downgrade if it believes that is appropriate for the ultimate document maturity level. Extensions to HTTP Datagrams will be coordinated with HTTPBIS. Extensions that solely relate to generic proxying functionality, and are not specific to the core MASQUE documents, are out of scope. Specifying proxy server discovery mechanisms is out of scope. New congestion control and loss recovery algorithms are also out of scope. However, the working group will consider implications of tunneling protocols with congestion control and loss recovery over MASQUE proxies, and may issue recommendations accordingly. The working group will consider how the protocols it defines might operate over versions of HTTP that use TCP rather than QUIC, for use when QUIC is unavailable. This might include defining alternative extensions specifically for use in these HTTP versions. IP multicast is out of scope. Designs need not explicitly preclude multicast, but they will not focus on multicast-specific features. Impacts on address migration, NAT rebinding, and future multipath mechanisms of QUIC are not anticipated. However, the working group should document these impacts, or those of any other QUIC developments, if they arise. The group will coordinate closely with other working groups responsible for maintaining relevant protocol extensions, such as HTTPBIS, QUIC, or TLS. It will also coordinate closely with ICCRG and CCWG on congestion control and loss recovery considerations, and intarea for IP Proxying and Ethernet tunneling. Finally, it will coordinate with IEEE 802.3 to make sure Ethernet concepts are correctly represented. MASQUE is not intended to be a long-lived working group. Goals and Milestones: - Submit an extension for UDP listeners - Submit an extension for QUIC-aware proxying - Submit an extension for Ethernet over MASQUE Internet-Drafts: - IP Proxying Support for HTTP [draft-age-masque-connect-ip-01] (20 pages) - Requirements for a MASQUE Protocol to Proxy IP Traffic [draft-cms-masque-ip-proxy-reqs-01] (10 pages) - Proxying Ethernet in HTTP [draft-ietf-masque-connect-ethernet-05] (17 pages) - Proxying IP in HTTP [draft-ietf-masque-connect-ip-13] (37 pages) - DNS Configuration for Proxying IP in HTTP [draft-ietf-masque-connect-ip-dns-01] (12 pages) - Proxying UDP in HTTP [draft-ietf-masque-connect-udp-15] (16 pages) - Proxying Bound UDP in HTTP [draft-ietf-masque-connect-udp-listen-04] (15 pages) - HTTP Datagrams and the Capsule Protocol [draft-ietf-masque-h3-datagram-11] (14 pages) - Requirements for a MASQUE Protocol to Proxy IP Traffic [draft-ietf-masque-ip-proxy-reqs-03] (11 pages) - QUIC-Aware Proxying Using HTTP [draft-ietf-masque-quic-proxy-04] (38 pages) - QUIC-Aware Proxying Using HTTP [draft-pauly-masque-quic-proxy-06] (24 pages) - The CONNECT-UDP HTTP Method [draft-schinazi-masque-connect-udp-00] (7 pages) - Using QUIC Datagrams with HTTP/3 [draft-schinazi-masque-h3-datagram-04] (10 pages) Requests for Comments: RFC9297: HTTP Datagrams and the Capsule Protocol (14 pages) RFC9298: Proxying UDP in HTTP (16 pages) * Updates RFC9484 RFC9484: Proxying IP in HTTP (37 pages) MBONE Deployment (mboned) ------------------------- Charter Last Modified: 2024-10-23 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 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: - Media Type Specifications and Registration Procedures [draft-ietf-mediaman-6838bis-00] (31 pages) - 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) Nov 2024 - WG adoption of MIMI room policy Mar 2025 - Forward specification of MIMI room policy to IESG Mar 2025 - Forward specification of MIMI protocol to IESG Mar 2025 - Forward specification for identifier naming conventions 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-02] (48 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-02] (24 pages) - Extension Formatting for the Opus Codec [draft-ietf-mlcodec-opus-extension-02] (7 pages) No Requests for Comments Messaging Layer Security (mls) ------------------------------ Charter Last Modified: 2022-05-04 Current Status: Active Chairs: Nick Sullivan Sean Turner Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Paul Wouters Secretary: Katriel Cohn-Gordon Mailing Lists: General Discussion: mls@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mls Archive: https://mailarchive.ietf.org/arch/browse/mls/ Description of Working Group: The Messaging Layer Security (MLS) protocol, RFC 9420, specifies a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands. The MLS WG will maintain the protocol and will work on the following MLS protocol extensions: * Support for use of MLS in protocols developed by the MIMI working group * Support for new credential types * Support for common operational patterns in messaging applications * Support for quantum resistance * Framework for safe extensibility * Detection of lost application messages * Support for sending messages to individual members of a group Many of the extensions to support these features will be included in draft-ietf-mls-extensions, but some of the extensions will be published in separate specifications. Goals and Milestones: Dec 2024 - Submit MLS extensions I-D to IESG as Proposed Standard Dec 2025 - Submit Additional Credentials I-D to IESG as Proposed Standard Dec 2026 - Post Quantum security for MLS Internet-Drafts: - The Messaging Layer Security (MLS) Protocol [draft-barnes-mls-protocol-01] (37 pages) - Flexible Hybrid PQ MLS Combiner [draft-hale-mls-combiner-01] (16 pages) - The Messaging Layer Security (MLS) Architecture [draft-ietf-mls-architecture-15] (50 pages) - The Messaging Layer Security (MLS) Extensions [draft-ietf-mls-extensions-05] (37 pages) - The Messaging Layer Security (MLS) Federation [draft-ietf-mls-federation-03] (8 pages) - The Messaging Layer Security (MLS) Protocol [draft-ietf-mls-protocol-20] (132 pages) - Messaging Layer Security Architecture [draft-omara-mls-architecture-01] (16 pages) - The Messaging Layer Security (MLS) Federation [draft-omara-mls-federation-00] (8 pages) - The Messaging Layer Security (MLS) Extensions [draft-robert-mls-extensions-00] (6 pages) Requests for Comments: RFC9420: The Messaging Layer Security (MLS) Protocol (132 pages) MODeration PrOceDures (modpod) ------------------------------ Charter Last Modified: 2024-10-29 Current Status: Active Chairs: Jon Peterson Lisa M. Dusseault General Area Directors: Roman Danyliw General Area Advisor: Roman Danyliw Mailing Lists: General Discussion: mod-discuss@ietf.org To Subscribe: https://mailman3.ietf.org/mailman3/lists/mod-discuss.ietf.org/ Archive: https://mailarchive.ietf.org/arch/browse/mod-discuss/ Description of Working Group: ## Background The IETF Guidelines for Conduct (RFC7154) state that IETF participants “extend respect and courtesy to their colleagues at all times” and “have impersonal discussions.” The IETF has a number of processes to address moderation of participants in non-face-to-face venues (e.g., RFC3934, RFC9245, BCP83, and “IESG Statement of Disruptive Posting”) in response to behavior which violates the IETF guidelines for conduct (RFC7154). Experience implementing moderation in the IETF has found: - that BCP83 has led to substantial strife within the community; - Inconsistency between working group and plenary lists policies; - A lack of defined policies for forums beyond email (e.g., chat, wikis); - Inconsistent application of existing policies due to community disagreement on the thresholds for reacting to disruptive behavior; and - Application of RFC3934 or posting-rights action (BCP83) to be perceived as cumbersome, slow, making it ill-suited to situations that escalate quickly. ## Scope of Work The MODeration PrOceDures (MODPOD) work group will revise existing and define new moderation procedures suitable for all IETF communication channels. The approaches the WG defines will (in no particular order of importance): - Aim to ensure that consistent and fair moderation procedures exist for all channels/forums in the IETF - Determine who can take moderation actions on a per channel/forum basis, how they are selected and the terms of their service, and the authority afforded to them - Determine who can initiate or propose a moderation action - Balance the need between privacy and dignity of individuals involved with the need for transparency to evaluate moderator adherence to policies. - Be flexible to varying circumstances, allowing for timely, appropriate responses in each situation. - Be capable of responding to patterns of behavior across channels/forums and moderating them collectively - Enable the use of more consistent moderation actions across channels/forums - Have a clear, consistent, and efficient path for appeals - Have a process to review previous moderator actions The WG will elaborate on how the moderation role and associated procedures interact or overlap with other roles such as working group chairs and the IETF Ombudsteam. As a starting point, the working group will consider draft-ecahc-moderation and draft-lear-bcp38-replacement, and associated discussions. An eventual proposal for the working group can be based on adopting aspects from these inputs or from a new approach. The revising or redefining of related Ombudsteam policies or practices such as RFC7776, Sections 1 and 2 of RFC 9245, or the IETF Guidelines for Conduct (RFC7154) is out of scope. ## Deliverables At a minimum, the working group will update or obsolete BCP83, and may update or obsolete other related RFCs such as BCP45. Goals and Milestones: Mar 2025 - WG adoption of one or more drafts on moderation procedures Nov 2025 - WGLC of draft(s) on moderation procedures Internet-Drafts: No Requests for Comments 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: - Network Overlay Impacts to Streaming Video [draft-deen-mops-network-overlay-impacts-02] (14 pages) - 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) Media Over QUIC (moq) --------------------- Charter Last Modified: 2024-10-14 Current Status: Active Chairs: Alan Frindell Magnus Westerlund Martin Duke Web and Internet Transport Directors: Francesca Palombini Zaheduzzaman Sarker Web and Internet Transport Advisor: Zaheduzzaman Sarker Tech Advisor: Zaheduzzaman Sarker Mailing Lists: General Discussion: moq@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/moq Archive: https://mailarchive.ietf.org/arch/browse/moq/ Description of Working Group: Media over QUIC (moq) will develop a simple low-latency media delivery solution for ingest and distribution of media. This solution addresses use cases including live streaming, gaming, and media conferencing and will scale efficiently. The solution will be implementable in both browser and non-browser endpoints. The work focuses on building protocol mechanisms for publication of media and means to identify and receive the media. The media publication protocol will enable sending media including audio, video, and timed metadata, such as closed captions and cue points. The common protocol for publishing media for ingest and distribution will support: * one or more media formats * an interoperable way to indicate the media and the media format being sent * rate adaptation strategies based on changing codec rates, changing chosen media encoding/qualities, or other mechanisms * cache friendly media mechanisms The mechanism to name and receive media will enable: * Requesting the server start sending media related to a given point in the stream * Selection of desired encoding (choosing language, bit rate, etc.) Media will be mapped onto underlying QUIC mechanisms (QUIC streams and/or QUIC datagrams) and can be used over raw QUIC or WebTransport. The proposed solution will provide extensibility for supporting different media formats and will support multiple media types and media encodings. The working group will define MoQ so that the media publication protocol can leverage coordinating relays, caches, or replication points wherever applicable to improve the delivery performance. The solution will specify a simple method for clients to authenticate to the relay or server to transmit or receive media. Media will be encrypted at the transport layer using the standard QUIC mechanisms. Media content may be end-to-end encrypted in certain use cases, where the "end-to-end" keys are available to media sources and consumers, but not relays. Even when media content is end-to-end encrypted, the relays can access metadata needed for caching (such as timestamp), making media forwarding decisions (such as drop or delay under congestion), and so on. Such media metadata will be authenticated and integrity-protected end-to-end. Mechanisms for establishing keys for these end-to-end protections are outside the scope of this group. This working group will not propose changes to the underlying QUIC transport, but may propose requirements for QUIC extensions to the QUIC WG. This working group will not define signaling mechanisms for discovery of relay or media producers or consumers. This working group will coordinate with the QUIC, WebTransport, and MOPS working groups as needed. It will liaise with MPEG Systems WG, DASH Industry Forum, and W3C WebTransport as appropriate. Goals and Milestones: Dec 2022 - WG adoption of Protocol Specification for Common Media Publication Protocol over QUIC Dec 2022 - WG adoption of Protocol Specification for the use of the Datagram Extension for Media Publication Protocol over QUIC Dec 2022 - WG adoption of Protocol Specification for Media Subscription Protocol over QUIC Dec 2022 - WG adoption of Architecture Specification for a Common Media Delivery Protocol over QUIC Dec 2022 - WG adoption of Use Cases and Requirements document for Media Delivery over QUIC Jun 2023 - Forward Protocol Specification for Common Media Publication Protocol over QUIC draft to IESG Jun 2023 - Forward Protocol Specification for the use of the Datagram Extension for Media Publication Protocol over QUIC draft to IESG Jun 2023 - Forward Protocol Specification for Media Subscription Protocol over QUIC draft to IESG Jun 2023 - Forward Architecture Specification for a Common Media Delivery Protocol over QUIC draft to IESG Internet-Drafts: - Common Catalog Format for moq-transport [draft-ietf-moq-catalogformat-01] (30 pages) - Media Over QUIC - Use Cases and Requirements for Media Transport Protocol Design [draft-ietf-moq-requirements-02] (27 pages) - Media over QUIC Transport [draft-ietf-moq-transport-07] (55 pages) No Requests for Comments 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) - Encapsulation of Simple Two-Way Active Measurement Protocol for Pseudowires and LSPs in MPLS Networks [draft-gandhi-mpls-stamp-pw-07] (19 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-11] (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-12] (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-15] (15 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-17] (22 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-03] (13 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-09] (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) * Updates RFC9658 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) RFC9658: Multipoint LDP Extensions for Multi-Topology Routing (14 pages) Network Configuration (netconf) ------------------------------- Charter Last Modified: 2024-11-12 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-02] (18 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-03] (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-10] (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-05] (67 pages) - NETCONF Extensions to Support List Pagination [draft-ietf-netconf-list-pagination-nc-05] (13 pages) - RESTCONF Extensions to Support List Pagination [draft-ietf-netconf-list-pagination-rc-05] (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) - NETCONF over QUIC [draft-ietf-netconf-over-quic-01] (9 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-05] (29 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-03] (10 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-02] (20 pages) - Transaction ID Mechanism for NETCONF [draft-ietf-netconf-transaction-id-07] (79 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-05] (13 pages) - UDP-based Transport for Configured Subscriptions [draft-ietf-netconf-udp-notif-16] (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) - Augmented-by Addition into the IETF-YANG-Library [draft-ietf-netconf-yang-library-augmentedby-01] (28 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) * Updates RFC9646 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) RFC9640: YANG Data Types and Groupings for Cryptography (47 pages) RFC9641: A YANG Data Model for a Truststore (30 pages) RFC9642: A YANG Data Model for a Keystore (39 pages) RFC9643: YANG Groupings for TCP Clients and TCP Servers (29 pages) RFC9644: YANG Groupings for SSH Clients and SSH Servers (64 pages) RFC9645: YANG Groupings for TLS Clients and TLS Servers (59 pages) RFC9646: Conveying a Certificate Signing Request (CSR) in a Secure Zero-Touch Provisioning (SZTP) Bootstrapping Request (32 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-11] (83 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-02] (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-17] (44 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-21] (93 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-03] (64 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-33] (51 pages) - System-defined Configuration [draft-ietf-netmod-system-config-09] (32 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-04] (55 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 File System Version 4 (nfsv4) ------------------------------------- Charter Last Modified: 2024-01-17 Current Status: Active Chairs: Brian Pawlowski Christopher Inacio Web and Internet Transport Directors: Francesca Palombini Zaheduzzaman Sarker Web and Internet Transport Advisor: Zaheduzzaman Sarker Tech Advisor: Leif Johansson Secretary: Thomas Haynes Mailing Lists: General Discussion: nfsv4@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/nfsv4 Archive: https://mailarchive.ietf.org/arch/browse/nfsv4/ Description of Working Group: Network File System version 4 (NFSv4) is an IETF standard for file sharing. To maintain NFS Version 4's utility and currency, the NFSv4 working group is chartered to maintain the existing NFSv4.0, NFSv4.1, and NFSv4.2 protocols and specifications of related ONC components, such as those defining RPC, XDR, and RPCSECGSS. The NFSv4 working group is also responsible for maintenance and extension of the RDMA protocols originally developed by the now-concluded RDDP WG (RFCs 5040-5045, e.g., RDMAP, DDP and MPA) , whose maintenance and extension were previously handled by the now-concluded STORM WG. In addition, extensions will be developed, as necessary, to correct problems with the protocols as currently specified, to accommodate needed file system semantics, and to respond to technological developments in the areas of networking and persistent storage/memory. Maintenance The working group's experience has been that, as NFSv4 implementations mature and deployments continue, clarifications and corrections to existing RFCs are needed. These specification updates help vendors in delivering high-quality and interoperable implementations. The NFSv4 working group is chartered with vetting reported issues and determining correctness of submitted errata. In addition, some areas may need more concentrated work to correct the specifications already published, to deal with unanticipated interactions between features, or to respond to evolving expectations with regard to areas such as security. Since necessary changes in such cases are generally not appropriate for the errata system, the working group will assist in publication of new RFCs that provide implementation guidance, editorial modification or technical updates to existing RFCs. Since the new NFSv4 versioning framework has been approved, these technical updates to NFSv4 minor versions could include limited XDR changes. Extensions The NFSv4 protocol is designed to allow extension by the definition of new operations, new attributes, and new Parallel NFS layout types, as well as the creation of minor versions. Similarly, associated ONC protocol components that have a versioning/ extension framework can be incrementally extended, when necessary. The working group will discuss proposals for such extensions and assure that they have adequate technical review, including discussion of their interaction with existing features, before adopting them as working group items and helping to draft specification documents. Some likely motivations for such extensions would be to: * Maximize NFS performance on advanced network fabrics. * Accommodate new storage technologies. * Provide facilities useful in management of NFS-accessed storage in large-scale virtualization environments. * Provide more effective NFS response to security challenges. New milestones that fall within the scope specified in this charter can be added to the list below after working group consensus and upon approval by the responsible Area Director. The WG will extend RDMA to enhance the Memory Placement operations such as Flush, Atomic Write and Validation using Integrity Signatures. Goals and Milestones: Dec 2024 - NFSv4 Internationalization Aug 2025 - Submit final document describing NFSv4 security. Dec 2025 - Submit POSIX ACL to IESG for publication Jul 2026 - Submit final draft of rfc5661bis Nov 2026 - Submit Flex File v2 to IESG for publication Internet-Drafts: - Network File System (NFS) Version 4 Minor Version 1 Protocol [draft-dnoveck-nfsv4-rfc5661bis-05] (663 pages) - NFS version 4 Protocol [draft-ietf-nfsv4-07] (212 pages) - NFS version 4 Protocol [draft-ietf-nfsv4-03-00] (230 pages) - Mapping Between NFSv4 and Posix Draft ACLs [draft-ietf-nfsv4-acl-mapping-05] (20 pages) - NFS Version 4 ACLs [draft-ietf-nfsv4-acls-00] (35 pages) - The Channel Conjunction Mechanism (CCM) for GSS [draft-ietf-nfsv4-ccm-03] (28 pages) - On the Use of Channel Bindings to Secure Channels [draft-ietf-nfsv4-channel-bindings-04] (17 pages) - Extending the Opening of Files in NFSv4.2 [draft-ietf-nfsv4-delstid-08] (14 pages) - NFS Version 4 Design Considerations [draft-ietf-nfsv4-designconsider-03] (22 pages) - NFSv4.1: Directory Delegations and Notifications [draft-ietf-nfsv4-directory-delegation-01] (24 pages) - A DNS RR for NFSv4 ID Domains [draft-ietf-nfsv4-dns-rr-00] (11 pages) - Administration Protocol for Federated File Systems [draft-ietf-nfsv4-federated-fs-admin-15] (37 pages) - Using DNS SRV to Specify a Global File Namespace with NFS Version 4 [draft-ietf-nfsv4-federated-fs-dns-srv-namespace-13] (11 pages) - Namespace Database (NSDB) Protocol for Federated File Systems [draft-ietf-nfsv4-federated-fs-protocol-15] (65 pages) - Requirements for Federated File Systems [draft-ietf-nfsv4-federated-fs-reqts-06] (26 pages) - Parallel NFS (pNFS) Flexible File Layout [draft-ietf-nfsv4-flex-files-19] (42 pages) - Integrity Measurement for Network File System version 4 [draft-ietf-nfsv4-integrity-measurement-08] (18 pages) - Internationalization for the NFSv4 Protocols [draft-ietf-nfsv4-internationalization-11] (61 pages) - NFS operation over IPv4 and IPv6 [draft-ietf-nfsv4-ipv4v6-00] (14 pages) - NFS operation over IPv6 [draft-ietf-nfsv4-ipv6-00] (8 pages) - Requirements for Labeled NFS [draft-ietf-nfsv4-labreqs-05] (18 pages) - Requirements for Parallel NFS (pNFS) Layout Types [draft-ietf-nfsv4-layout-types-13] (17 pages) - Add LAYOUT_WCC to NFSv4.2's Flex File Layout Type [draft-ietf-nfsv4-layoutwcc-04] (13 pages) - Reporting of Errors via LAYOUTRETURN in NFSv4.2 [draft-ietf-nfsv4-layrec-02] (7 pages) - Registry Specification for Mandatory Access Control (MAC) Security Label Formats [draft-ietf-nfsv4-lfs-registry-06] (10 pages) - NFSv4 Migration and Trunking: Implementation and Specification Issues [draft-ietf-nfsv4-migration-issues-16] (55 pages) - Network File System (NFS) Version 4 Minor Version 1 Protocol [draft-ietf-nfsv4-minorversion1-29] (617 pages) - Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description [draft-ietf-nfsv4-minorversion1-dot-x-12] (73 pages) - Network File System (NFS) Version 4 Minor Version 2 Protocol [draft-ietf-nfsv4-minorversion2-41] (104 pages) - Network File System (NFS) Version 4 Minor Version 2 External Data Representation Standard (XDR) Description [draft-ietf-nfsv4-minorversion2-dot-x-41] (87 pages) - Requirements for NFSv4.2 [draft-ietf-nfsv4-minorversion-2-requirements-00] (10 pages) - Requirements for NFSv4 Multi-Domain Namespace Deployment [draft-ietf-nfsv4-multi-domain-fs-reqs-11] (17 pages) - NFS Version 4.0 Trunking Update [draft-ietf-nfsv4-mv0-trunking-update-05] (22 pages) - NFS Version 4.1 Update for Multi-Server Namespace [draft-ietf-nfsv4-mv1-msns-update-04] (106 pages) - Network File System (NFS) Direct Data Placement [draft-ietf-nfsv4-nfsdirect-08] (10 pages) - Network File System (NFS) Remote Direct Memory Access (RDMA) Problem Statement [draft-ietf-nfsv4-nfs-rdma-problem-statement-08] (15 pages) - NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5 [draft-ietf-nfsv4-nfssec-03] (19 pages) - Network File System (NFS) Upper-Layer Binding To RPC-Over-RDMA Version 2 [draft-ietf-nfsv4-nfs-ulb-v2-07] (18 pages) - NFSv4 pNFS Extensions [draft-ietf-nfsv4-pnfs-00] (63 pages) - pNFS Access Permissions Check [draft-ietf-nfsv4-pnfs-access-permissions-check-00] (12 pages) - Parallel NFS (pNFS) Block/Volume Layout [draft-ietf-nfsv4-pnfs-block-12] (28 pages) - Parallel NFS (pNFS) Block Disk Protection [draft-ietf-nfsv4-pnfs-block-disk-protection-03] (6 pages) - Object-Based Parallel NFS (pNFS) Operations [draft-ietf-nfsv4-pnfs-obj-12] (35 pages) - Implementation Guide for Referrals in NFSv4 [draft-ietf-nfsv4-referrals-00] (24 pages) - Server-to-Server Replication/Migration Protocol Design Principles [draft-ietf-nfsv4-repl-mig-design-00] (12 pages) - A Server-to-Server Replication/Migration Protocol [draft-ietf-nfsv4-repl-mig-proto-01] (30 pages) - NFS Version 4 Requirements [draft-ietf-nfsv4-requirements-03] (19 pages) - RPC: Remote Procedure Call Protocol Specification Version 2 [draft-ietf-nfsv4-rfc1831bis-13] (63 pages) - XDR: External Data Representation Standard [draft-ietf-nfsv4-rfc1832bis-06] (27 pages) - Network File System (NFS) version 4 Protocol [draft-ietf-nfsv4-rfc3010bis-05] (275 pages) - Network File System (NFS) Version 4 Protocol [draft-ietf-nfsv4-rfc3530bis-35] (323 pages) - Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description [draft-ietf-nfsv4-rfc3530bis-dot-x-24] (39 pages) - NFSv4.0 Migration: Specification Update [draft-ietf-nfsv4-rfc3530-migration-update-08] (55 pages) - Network File System (NFS) Version 4 Minor Version 1 Protocol [draft-ietf-nfsv4-rfc5661bis-09] (753 pages) - NFS Version 4.1 Update for Multi-Server Namespace [draft-ietf-nfsv4-rfc5661-msns-update-00] (135 pages) - Network File System (NFS) Version 4 Minor Version 1 Protocol [draft-ietf-nfsv4-rfc5661sesqui-msns-04] (560 pages) - Object-Based Parallel NFS (pNFS) Operations [draft-ietf-nfsv4-rfc5664bis-03] (38 pages) - Remote Direct Memory Access Transport for Remote Procedure Call Version 1 [draft-ietf-nfsv4-rfc5666bis-11] (55 pages) - RPC-over-RDMA Version One Implementation Experience [draft-ietf-nfsv4-rfc5666-implementation-experience-03] (50 pages) - Network File System (NFS) Upper-Layer Binding to RPC-over-RDMA Version 1 [draft-ietf-nfsv4-rfc5667bis-13] (21 pages) - RPC Numbering Authority Transfer to IANA [draft-ietf-nfsv4-rpc-iana-03] (13 pages) - IPv6 extension to RPC [draft-ietf-nfsv4-rpc-ipv6-00] (13 pages) - IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats [draft-ietf-nfsv4-rpc-netid-06] (14 pages) - Remote Direct Memory Access Transport for Remote Procedure Call [draft-ietf-nfsv4-rpcrdma-09] (34 pages) - Bidirectional Remote Procedure Call on RPC-over-RDMA Transports [draft-ietf-nfsv4-rpcrdma-bidirection-08] (13 pages) - Remote Direct Memory Access - Connection Manager (RDMA-CM) Private Data for RPC-over-RDMA Version 1 [draft-ietf-nfsv4-rpcrdma-cm-pvt-data-08] (12 pages) - RPC-over-RDMA Version 2 Protocol [draft-ietf-nfsv4-rpcrdma-version-two-07] (90 pages) - RPCSEC_GSS Version 2 [draft-ietf-nfsv4-rpcsec-gss-v2-06] (14 pages) - Remote Procedure Call (RPC) Security Version 3 [draft-ietf-nfsv4-rpcsec-gssv3-17] (26 pages) - Remote Procedure Call (RPC) Security Version 3 [draft-ietf-nfsv4-rpcsecgssv3-00] (23 pages) - Towards Remote Procedure Call Encryption by Default [draft-ietf-nfsv4-rpc-tls-11] (21 pages) - Parallel NFS (pNFS) Small Computer System Interface (SCSI) Layout [draft-ietf-nfsv4-scsi-layout-10] (30 pages) - Using the Parallel NFS (pNFS) SCSI Layout to access NVMe storage devices [draft-ietf-nfsv4-scsi-layout-nvme-07] (10 pages) - NFSv4.1: SECINFO Changes [draft-ietf-nfsv4-secinfo-02] (15 pages) - NFSv4 Session Extensions [draft-ietf-nfsv4-sess-02] (69 pages) - Allowing Inheritable NFSv4 Access Control Entries to Override the Umask [draft-ietf-nfsv4-umask-05] (7 pages) - Rules for NFSv4 Extensions and Minor Versions [draft-ietf-nfsv4-versioning-11] (26 pages) - File System Extended Attributes in NFSv4 [draft-ietf-nfsv4-xattrs-07] (28 pages) - NFS version 4 [draft-shepler-nfsv4-03] (133 pages) Requests for Comments: RFC2623: NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5 (19 pages) RFC2624: NFS Version 4 Design Considerations (22 pages) RFC3010: NFS version 4 Protocol (212 pages) * Obsoletes RFC3530 RFC3530: Network File System (NFS) version 4 Protocol (275 pages) * Obsoletes RFC7530 RFC4506: XDR: External Data Representation Standard (27 pages) RFC5403: RPCSEC_GSS Version 2 (14 pages) * Updates RFC7861 RFC5531: RPC: Remote Procedure Call Protocol Specification Version 2 (63 pages) * Updates RFC9289 RFC5532: Network File System (NFS) Remote Direct Memory Access (RDMA) Problem Statement (15 pages) RFC5661: Network File System (NFS) Version 4 Minor Version 1 Protocol (617 pages) * Updates RFC8178 * Updates RFC8434 * Obsoletes RFC8881 RFC5662: Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description (73 pages) RFC5663: Parallel NFS (pNFS) Block/Volume Layout (28 pages) * Updates RFC6688 RFC5664: Object-Based Parallel NFS (pNFS) Operations (35 pages) RFC5665: IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats (14 pages) RFC5666: Remote Direct Memory Access Transport for Remote Procedure Call (34 pages) * Obsoletes RFC8166 RFC5667: Network File System (NFS) Direct Data Placement (10 pages) * Obsoletes RFC8267 RFC5716: Requirements for Federated File Systems (26 pages) RFC6641: Using DNS SRV to Specify a Global File Namespace with NFS Version 4 (11 pages) RFC6688: Parallel NFS (pNFS) Block Disk Protection (6 pages) RFC7204: Requirements for Labeled NFS (18 pages) RFC7530: Network File System (NFS) Version 4 Protocol (323 pages) * Updates RFC7931 * Updates RFC8587 RFC7531: Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description (39 pages) RFC7532: Namespace Database (NSDB) Protocol for Federated File Systems (65 pages) RFC7533: Administration Protocol for Federated File Systems (37 pages) RFC7569: Registry Specification for Mandatory Access Control (MAC) Security Label Formats (10 pages) RFC7861: Remote Procedure Call (RPC) Security Version 3 (26 pages) RFC7862: Network File System (NFS) Version 4 Minor Version 2 Protocol (104 pages) * Updates RFC8178 RFC7863: Network File System (NFS) Version 4 Minor Version 2 External Data Representation Standard (XDR) Description (87 pages) RFC7931: NFSv4.0 Migration: Specification Update (55 pages) RFC8000: Requirements for NFSv4 Multi-Domain Namespace Deployment (17 pages) RFC8154: Parallel NFS (pNFS) Small Computer System Interface (SCSI) Layout (30 pages) RFC8166: Remote Direct Memory Access Transport for Remote Procedure Call Version 1 (55 pages) * Updates RFC8797 RFC8167: Bidirectional Remote Procedure Call on RPC-over-RDMA Transports (13 pages) RFC8178: Rules for NFSv4 Extensions and Minor Versions (26 pages) RFC8267: Network File System (NFS) Upper-Layer Binding to RPC-over-RDMA Version 1 (21 pages) RFC8275: Allowing Inheritable NFSv4 Access Control Entries to Override the Umask (7 pages) RFC8276: File System Extended Attributes in NFSv4 (28 pages) RFC8434: Requirements for Parallel NFS (pNFS) Layout Types (17 pages) RFC8435: Parallel NFS (pNFS) Flexible File Layout (42 pages) RFC8587: NFS Version 4.0 Trunking Update (22 pages) RFC8797: Remote Direct Memory Access - Connection Manager (RDMA-CM) Private Data for RPC-over-RDMA Version 1 (12 pages) RFC8881: Network File System (NFS) Version 4 Minor Version 1 Protocol (560 pages) RFC9289: Towards Remote Procedure Call Encryption by Default (21 pages) RFC9561: Using the Parallel NFS (pNFS) SCSI Layout to Access Non-Volatile Memory Express (NVMe) Storage Devices (9 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: Jun 2025 - Submit "Digital Map: Concept, Requirements, and Use Cases" to the IESG Sep 2025 - Submit Architecture for YANG-Push to Message Broker Integration to the IESG Dec 2025 - Submit Network Incident Management to the IESG Dec 2025 - Submit Network Anomaly Management to the IESG Dec 2025 - Submit NMOP Terminology to the IESG Done - Adopt a document describing how to integrate YANG Push with Apache Kafka Done - Adopt a document on network incident management 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) - Digital Map: Concept, Requirements, and Use Cases [draft-ietf-nmop-digital-map-concept-02] (15 pages) - An Architecture for a Network Anomaly Detection Framework [draft-ietf-nmop-network-anomaly-architecture-01] (19 pages) - A YANG Data Model for Network Incident Management [draft-ietf-nmop-network-incident-yang-02] (42 pages) - Some Key Terms for Network Fault and Problem Management [draft-ietf-nmop-terminology-07] (15 pages) - An Architecture for YANG-Push to Message Broker Integration [draft-ietf-nmop-yang-message-broker-integration-05] (24 pages) - An Architecture for a Network Anomaly Detection Framework [draft-netana-nmop-network-anomaly-architecture-00] (18 pages) - An Experiment: Network Anomaly Lifecycle [draft-netana-nmop-network-anomaly-lifecycle-05] (23 pages) - Semantic Metadata Annotation for Network Anomaly Detection [draft-netana-nmop-network-anomaly-semantics-04] (20 pages) - An Architecture for YANG-Push to Message Broker Integration [draft-netana-nmop-yang-message-broker-integration-00] (21 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-08] (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) - NTS extensions for enabling pools [draft-venhoek-nts-pool-01] (9 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) 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-12] (10 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) RFC9638: Network Virtualization over Layer 3 (NVO3) Encapsulation Considerations (22 pages) Web Authorization Protocol (oauth) ---------------------------------- Charter Last Modified: 2024-03-27 Current Status: Active Chairs: Hannes Tschofenig Rifaat Shekh-Yusef Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Deb Cooley Mailing Lists: General Discussion: oauth@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/oauth Archive: https://mailarchive.ietf.org/arch/browse/oauth/ Description of Working Group: The Web Authorization (OAuth) protocol allows a user to grant a third-party web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing web site to print their private pictures, without allowing the printing site to gain full control of the user's account and without having the user share his or her photo-sharing sites' long-term credential with the printing site. The OAuth 2.0 protocol suite already includes * a procedure for enabling a client to register with an authorization server, * a protocol for obtaining authorization tokens from an authorization server with the resource owner's consent, and * protocols for presenting these authorization tokens to protected resources for access to a resource. This protocol suite has been enhanced with functionality for interworking with legacy identity infrastructure (such as SAML), token revocation, token exchange, dynamic client registration, token introspection, a standardized token format with the JSON Web Token, and specifications that mitigate security attacks, such as Proof Key for Code Exchange. The ongoing standardization efforts within the OAuth working group focus on increasing interoperability of OAuth deployments and to improve security. More specifically, the working group is defining proof of possession tokens, developing a discovery mechanism, providing guidance for the use of OAuth with native apps, re-introducing the device flow used by devices with limited user interfaces, additional security enhancements for clients communicating with multiple service providers, definition of claims used with JSON Web Tokens, techniques to mitigate open redirector attacks, as well as guidance on encoding state information. For feedback and discussion about our specifications please subscribe to our public mailing list at . For security related bug reports that relate to our specifications please contact . If the reported bug report turns out to be implementation-specific we will attempt to forward it to the appropriate developers. Goals and Milestones: Mar 2021 - Submit 'OAuth 2.0 Pushed Authorization Requests" to IESG Jul 2021 - Submit "OAuth 2.1 Authorization Framework" to IESG Jul 2021 - Submit 'OAuth 2.0 Security Best Practice" to IESG Oct 2021 - Submit "OAuth 2.0 for Browser-Based Apps" to IES Jan 2022 - Submit "OAuth 2.0 Proof-of-Posession at the Application Layer" to IESG Apr 2022 - Submit "OAuth 2.0 Authorization Server Issue Identifier in Authorization Response" to IESG Done - Submit 'Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)' to the IESG Done - Submit 'OAuth 2.0 Proof-of-Possession (PoP) Security Architecture' to the IESG Done - Submit 'Request by JWS ver.1.0 for OAuth 2.0' to the IESG for consideration as a Proposed Standard Done - Submit 'Authentication Method Reference Values' to the IESG Done - Submit 'OAuth 2.0 for Native Apps' to the IESG Done - Submit 'OAuth 2.0 Authorization Server Discovery Metadata' to the IESG Done - Submit 'OAuth 2.0 Device Flow' to the IESG Done - Submit 'OAuth 2.0 Token Exchange' to the IESG for consideration as a Proposed Standard Internet-Drafts: - JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens [draft-ietf-oauth-access-token-jwt-13] (15 pages) - Authentication Method Reference Values [draft-ietf-oauth-amr-values-08] (15 pages) - Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [draft-ietf-oauth-assertions-18] (20 pages) - OAuth 2.0 Attestation-Based Client Authentication [draft-ietf-oauth-attestation-based-client-auth-04] (20 pages) - The OAuth Protocol: Authentication [draft-ietf-oauth-authentication-01] (21 pages) - OAuth 2.0 for Browser-Based Applications [draft-ietf-oauth-browser-based-apps-19] (62 pages) - OAuth 2.0 Security: Closing Open Redirectors in OAuth [draft-ietf-oauth-closing-redirectors-00] (7 pages) - Cross-Device Flows: Security Best Current Practice [draft-ietf-oauth-cross-device-security-08] (55 pages) - OAuth 2.0 Device Authorization Grant [draft-ietf-oauth-device-flow-15] (21 pages) - OAuth 2.0 Authorization Server Metadata [draft-ietf-oauth-discovery-10] (23 pages) - Distributed OAuth [draft-ietf-oauth-distributed-01] (9 pages) - OAuth 2.0 Demonstrating Proof of Possession (DPoP) [draft-ietf-oauth-dpop-16] (39 pages) - OAuth 2.0 Dynamic Client Registration Protocol [draft-ietf-oauth-dyn-reg-30] (39 pages) - OAuth 2.0 Dynamic Client Registration Management Protocol [draft-ietf-oauth-dyn-reg-management-15] (18 pages) - OAuth 2.0 Dynamic Client Registration Metadata [draft-ietf-oauth-dyn-reg-metadata-01] (4 pages) - OAuth 2.0 for First-Party Applications [draft-ietf-oauth-first-party-apps-00] (38 pages) - OAuth Identity and Authorization Chaining Across Domains [draft-ietf-oauth-identity-chaining-02] (19 pages) - OAuth 2.0 Incremental Authorization [draft-ietf-oauth-incremental-authz-04] (11 pages) - OAuth 2.0 Token Introspection [draft-ietf-oauth-introspection-11] (17 pages) - OAuth 2.0 Authorization Server Issuer Identification [draft-ietf-oauth-iss-auth-resp-05] (9 pages) - JSON Web Token (JWT) [draft-ietf-oauth-json-web-token-32] (30 pages) - JWK Thumbprint URI [draft-ietf-oauth-jwk-thumbprint-uri-03] (6 pages) - The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR) [draft-ietf-oauth-jwsreq-34] (25 pages) - JSON Web Token Best Current Practices [draft-ietf-oauth-jwt-bcp-07] (13 pages) - JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants [draft-ietf-oauth-jwt-bearer-12] (12 pages) - JWT Response for OAuth Token Introspection [draft-ietf-oauth-jwt-introspection-response-12] (19 pages) - OAuth 2.0 Mix-Up Mitigation [draft-ietf-oauth-mix-up-mitigation-01] (14 pages) - OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens [draft-ietf-oauth-mtls-17] (24 pages) - OAuth 2.0 for Native Apps [draft-ietf-oauth-native-apps-12] (21 pages) - OAuth 2.0 Pushed Authorization Requests [draft-ietf-oauth-par-10] (18 pages) - OAuth 2.0 Proof-of-Possession (PoP) Security Architecture [draft-ietf-oauth-pop-architecture-08] (23 pages) - OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution [draft-ietf-oauth-pop-key-distribution-07] (17 pages) - Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) [draft-ietf-oauth-proof-of-possession-11] (15 pages) - OAuth 2.0 Rich Authorization Requests [draft-ietf-oauth-rar-23] (38 pages) - Reciprocal OAuth [draft-ietf-oauth-reciprocal-04] (8 pages) - Resource Indicators for OAuth 2.0 [draft-ietf-oauth-resource-indicators-08] (11 pages) - OAuth 2.0 Protected Resource Metadata [draft-ietf-oauth-resource-metadata-13] (31 pages) - OAuth 2.0 Token Revocation [draft-ietf-oauth-revocation-11] (11 pages) - Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants [draft-ietf-oauth-saml2-bearer-23] (15 pages) - SD-JWT-based Verifiable Credentials (SD-JWT VC) [draft-ietf-oauth-sd-jwt-vc-06] (53 pages) - OAuth 2.0 Security Best Current Practice [draft-ietf-oauth-security-topics-29] (59 pages) - Selective Disclosure for JWTs (SD-JWT) [draft-ietf-oauth-selective-disclosure-jwt-13] (93 pages) - A Method for Signing HTTP Requests for OAuth [draft-ietf-oauth-signed-http-request-03] (13 pages) - Proof Key for Code Exchange by OAuth Public Clients [draft-ietf-oauth-spop-15] (20 pages) - Token Status List [draft-ietf-oauth-status-list-05] (48 pages) - OAuth 2.0 Step Up Authentication Challenge Protocol [draft-ietf-oauth-step-up-authn-challenge-17] (14 pages) - OAuth 2.0 Token Binding [draft-ietf-oauth-token-binding-08] (30 pages) - OAuth 2.0 Token Exchange [draft-ietf-oauth-token-exchange-19] (27 pages) - Transaction Tokens [draft-ietf-oauth-transaction-tokens-03] (28 pages) - An IETF URN Sub-Namespace for OAuth [draft-ietf-oauth-urn-sub-ns-06] (5 pages) - OAuth Use Cases [draft-ietf-oauth-use-cases-03] (24 pages) - The OAuth 2.0 Authorization Framework [draft-ietf-oauth-v2-31] (76 pages) - The OAuth 2.1 Authorization Framework [draft-ietf-oauth-v2-1-11] (96 pages) - The OAuth 2.0 Authorization Framework: Bearer Token Usage [draft-ietf-oauth-v2-bearer-23] (18 pages) - OAuth 2.0 Message Authentication Code (MAC) Tokens [draft-ietf-oauth-v2-http-mac-05] (37 pages) - OAuth 2.0 Threat Model and Security Considerations [draft-ietf-oauth-v2-threatmodel-08] (71 pages) - The OAuth Protocol: Web Delegation [draft-ietf-oauth-web-delegation-01] (18 pages) Requests for Comments: RFC6749: The OAuth 2.0 Authorization Framework (76 pages) * Updates RFC8252 * Updates RFC8996 RFC6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage (18 pages) * Updates RFC8996 RFC6755: An IETF URN Sub-Namespace for OAuth (5 pages) RFC6819: OAuth 2.0 Threat Model and Security Considerations (71 pages) RFC7009: OAuth 2.0 Token Revocation (11 pages) RFC7519: JSON Web Token (JWT) (30 pages) * Updates RFC7797 * Updates RFC8725 RFC7521: Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants (20 pages) RFC7522: Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants (15 pages) RFC7523: JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants (12 pages) RFC7591: OAuth 2.0 Dynamic Client Registration Protocol (39 pages) RFC7592: OAuth 2.0 Dynamic Client Registration Management Protocol (18 pages) RFC7636: Proof Key for Code Exchange by OAuth Public Clients (20 pages) RFC7662: OAuth 2.0 Token Introspection (17 pages) RFC7800: Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) (15 pages) RFC8176: Authentication Method Reference Values (15 pages) RFC8252: OAuth 2.0 for Native Apps (21 pages) RFC8414: OAuth 2.0 Authorization Server Metadata (23 pages) RFC8628: OAuth 2.0 Device Authorization Grant (21 pages) RFC8693: OAuth 2.0 Token Exchange (27 pages) RFC8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens (24 pages) RFC8707: Resource Indicators for OAuth 2.0 (11 pages) RFC8725: JSON Web Token Best Current Practices (13 pages) RFC9068: JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens (15 pages) RFC9101: The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR) (25 pages) RFC9126: OAuth 2.0 Pushed Authorization Requests (18 pages) RFC9207: OAuth 2.0 Authorization Server Issuer Identification (9 pages) RFC9278: JWK Thumbprint URI (6 pages) RFC9396: OAuth 2.0 Rich Authorization Requests (38 pages) RFC9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) (39 pages) RFC9470: OAuth 2.0 Step Up Authentication Challenge Protocol (14 pages) Oblivious HTTP Application Intermediation (ohai) ------------------------------------------------ Charter Last Modified: 2022-05-06 Current Status: Active Chairs: Richard Barnes Shivan Kaul Sahib Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Francesca Palombini Mailing Lists: General Discussion: ohai@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ohai Archive: https://mailarchive.ietf.org/arch/browse/ohai/ Description of Working Group: In a number of different settings, interactions between clients and servers involve information that could be sensitive when associated with client identity. Client-server applications built on HTTP reveal aspects of client identity to servers through these interactions, especially source addresses. Even without client identity, a server might be able to build a profile of client activity by correlating requests from the same client over time. In HTTP-based applications where the information included in requests does not need to be correlated, the protocol this working group defines will allow a supporting server to accept requests via a proxy. The proxy ensures that the server cannot see source addressing information for clients, which prevents servers linking multiple requests from the same client. Encryption ensures that the proxy is unable to read requests or responses. However, if the proxy and server collude, then neither of these privacy properties hold. Applications and use cases best suited for this protocol are those that have discrete, transactional queries that might reveal small amounts of information that accumulate over time. Examples include DNS queries, telemetry submission, and certificate revocation checking. In some of these application deployments, the relationship between client, server, and cooperating proxy might be configured out-of-band. General purpose HTTP applications such as web browsing are not in scope for the protocol that is to be defined. Broad applicability is limited by multiple factors, including the need for explicit server support of the protocol. In contrast, transport-level proxies such as HTTP CONNECT or MASQUE are a more appropriate mechanism for those use cases, as they allow connecting to unmodified servers. The OHAI working group will define a protocol for anonymization of HTTP requests using a partly-trusted intermediary, a method of encapsulating HTTP requests and responses that provides protected, low-latency exchanges. This protocol will use existing cryptographic primitives to meet these goals. The working group will define any data formats necessary to carry encapsulated requests and responses, plus formats for supplementary material, such as server keying material, that might be needed to use the protocol. The OHAI working group will include an applicability statement that documents the limitations of this design and any usage constraints that are necessary to ensure that the protocol is secure. The working group will consider the operational impact as part of the protocol design and document operational considerations. The working group will prioritize work on the core protocol elements as identified. In addition, the working group may work on other use cases and deployment models, including those that involve discovery of proxies or servers and their key configurations. The OHAI working group will work closely with other groups that develop the tools that the protocol depends on (HTTPbis for HTTP, CFRG for HPKE) or that might use the protocol (DPRIVE and ADD for DNS over HTTPS). The working group will use draft-thomson-http-oblivious as input. Goals and Milestones: Jul 2025 - Submit Chunked OHTTP draft to the IESG for publication Done - Submit the protocol draft to the IESG for publication Internet-Drafts: - Chunked Oblivious HTTP Messages [draft-ietf-ohai-chunked-ohttp-02] (12 pages) - Oblivious HTTP [draft-ietf-ohai-ohttp-10] (49 pages) - Discovery of Oblivious Services via Service Binding Records [draft-ietf-ohai-svcb-config-07] (12 pages) - Chunked Oblivious HTTP Messages [draft-ohai-chunked-ohttp-01] (12 pages) - Discovery of Oblivious Services via Service Binding Records [draft-pauly-ohai-svcb-config-03] (11 pages) - Oblivious Relay Feedback [draft-rdb-ohai-feedback-to-proxy-09] (13 pages) - Oblivious HTTP [draft-thomson-ohai-ohttp-00] (30 pages) Requests for Comments: RFC9458: Oblivious HTTP (40 pages) RFC9540: Discovery of Oblivious Services via Service Binding Records (10 pages) Open Specification for Pretty Good Privacy (openpgp) ---------------------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Daniel Kahn Gillmor Stephen Farrell Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Paul Wouters Mailing Lists: General Discussion: openpgp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/openpgp Archive: https://mailarchive.ietf.org/arch/browse/openpgp/ Description of Working Group: OpenPGP standardized mechanisms for object encryption, object signing, and identity certification. The working group is chartered to work on improvements and additions to the OpenPGP format and ecosystem to address certain issues that have been identified by the community, as set out in the list of in-scope topics below. Due to the WG having been dormant for a number of years, there is somewhat of a backlog of topics, and as addressing all of these topics at once seems difficult, the WG will follow the process defined below to prioritize current lists of milestones, selected from this long list of in-scope topics. # In-scope Topics The working group will produce a number of specifications that are adjacent to the OpenPGP specification and provide guidance to OpenPGP libraries and/or applications. These improvements may include: ## Security improvements - **Post-Quantum Cryptography (PQC)**: The addition and facilitation of post-quantum algorithms for encryption and signing (using draft-wussler-openpgp-pqc) as initial input). - **Forward secrecy**: enable encrypted OpenPGP communication that cannot be decrypted when long-term keys are compromised. - **Context binding**: facilitate [domain separation for signing and/or encryption](https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/145). ## New functionality - **Automatic Forwarding**: using proxy re-encryption (using draft-wussler-openpgp-forwarding) as initial input). - **Persistent Symmetric Keys**: for long-term storage of symmetric key material, symmetrically encrypted messages, and symmetric attestations (using draft-huigens-openpgp-persistent-symmetric-keys as initial input). - **First-Party Approval of Third-Party Certifications (1PA3PC)**: to mitigate certificate flooding attacks (using draft-dkg-openpgp-1pa3pc as initial input). - **Superseded Keys**: to facilitate [transition to new keys without revoking the old ones](https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/222). - **Stateless OpenPGP Interface (SOP)**: using draft-dkg-openpgp-stateless-cli as initial input. - **PGP/MIME Separate Encrypted Parts**: Extending RFC3156 to describe [messages composed of multiple encrypted parts](https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/171). - **cert-d**: A common certificate storage mechanism (using draft-nwjw-openpgp-cert-d as initial input). ## Network-based Key Discovery Mechanisms - **HTTP Keyserver Protocol (HKP)**: using draft-gallagher-openpgp-hkp as initial input. - **Web Key Directory (WKD)**: using draft-koch-openpgp-webkey-service as initial input. ## Key Verification Mechanisms - **Web-of-Trust (WoT)**: Specifying semantics for the WoT calculus (using [the OpenPGP Web of Trust draft](https://sequoia-pgp.gitlab.io/sequoia-wot/) as initial input). - **Key Transparency**: in collaboration with the [Key Transparency Working Group](https://datatracker.ietf.org/wg/keytrans/about/), e.g., integrating its outputs. - **Key Verification**: Improved manual key verification, for example using a QR code. ## Miscellaneous Cleanup Work - **Semantics**: Define semantics of mechanisms provided by OpenPGP. This includes, but is not limited to, defining validity of signatures, acceptance and placement of signature subpackets, as well as structure and meaning of certificates and messages. - **User ID Conventions**: Properly document User ID conventions (using draft-dkg-openpgp-userid-conventions as initial input). - **Revocation**: Clarify and improve revocation semantics and workflows, including replacement of the deprecated Revocation Key mechanism (using draft-dkg-openpgp-revocation as initial input). - **Message Grammar**: [Simplify](https://mailarchive.ietf.org/arch/msg/openpgp/uepOF6XpSegMO4c59tt9e5H1i4g/) the OpenPGP Message Grammar; e.g., by limiting nesting, or by constraining sequences of packet types. - **PGP/MIME One-Pass Signatures**: Extending RFC3156 to permit [one-pass signature verification for v6 signatures](https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/116) # Working Group Process All work items will require demonstration of interoperable support by at least two independent implementations before being submitted to the IESG for publication. The WG chairs will periodically poll the WG for which of the topics above to add as milestones, as participant interest, document editor, review and implementer resources permit. The WG chairs will ensure that the list of active topics is credible at all times, likely resulting in only 3-4 topics being "active" at any given time. Such polls will typically result in the addition of a call-for-adoption for one or two new topics from the list above, depending on resources, and as currently active work is completed. As calls-for-adoption are held, those will also consider the intended-status (PS, informational, BCP) for the documents concerned. Completion will typically mean that a draft has passed working group last call or IETF last call, but, if needed, the chairs will make use of other datatracker IETF document states (e.g., parked WG document) if some document is stalled for technical or personnel reasons, leaving space for tackling another topic. The set of initial milestones below was selected following discussion on the WG list following the above process, and will be updated periodically as milestones are met. Goals and Milestones: Jan 2024 - Call for adoption of drafts related to post quantum cryptography to produce a proposed standard RFC Mar 2024 - Call for adoption of drafts related to superseded keys to produce a proposed standard RFC Mar 2024 - Call for adoption of drafts related to persistent symmetric keys to produce a proposed standard RFC Jun 2024 - Call for adoption of drafts related to WKD and/or HKP to produce a proposed standard RFC Internet-Drafts: - OpenPGP Replacement Key Signalling Mechanism [draft-gallagher-openpgp-replacementkey-02] (12 pages) - Persistent Symmetric Keys in OpenPGP [draft-huigens-openpgp-persistent-symmetric-keys-02] (8 pages) - OpenPGP [draft-ietf-openpgp-crypto-refresh-13] (199 pages) - OpenPGP Message Format [draft-ietf-openpgp-formats-07] (65 pages) - MIME Security with OpenPGP [draft-ietf-openpgp-mime-08] (15 pages) - Multiple Signatures using Security Multiparts [draft-ietf-openpgp-multsig-02] (6 pages) - Persistent Symmetric Keys in OpenPGP [draft-ietf-openpgp-persistent-symmetric-keys-00] (8 pages) - Post-Quantum Cryptography in OpenPGP [draft-ietf-openpgp-pqc-06] (81 pages) - OpenPGP Key Replacement [draft-ietf-openpgp-replacementkey-01] (13 pages) - OpenPGP Message Format [draft-ietf-openpgp-rfc2440bis-22] (90 pages) - Post-Quantum Cryptography in OpenPGP [draft-wussler-openpgp-pqc-04] (41 pages) Requests for Comments: RFC2440: OpenPGP Message Format (65 pages) * Obsoletes RFC4880 RFC3156: MIME Security with OpenPGP (15 pages) RFC4880: OpenPGP Message Format (90 pages) * Updates RFC5581 * Obsoletes RFC9580 RFC9580: OpenPGP (166 pages) Operations and Management Area Working Group (opsawg) ----------------------------------------------------- Charter Last Modified: 2024-11-02 Current Status: Active Chairs: Benoît Claise 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) - A YANG Model for Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3 [draft-boucadair-opsawg-secure-tacacs-yang-03] (30 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-11] (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-05] (39 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-04] (33 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) - IP Flow Information Export (IPFIX) Alternate-Marking Information Elements [draft-ietf-opsawg-ipfix-alt-mark-01] (11 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 GTP-U Information in IP Flow Information Export (IPFIX) [draft-ietf-opsawg-ipfix-gtpu-01] (14 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-14] (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-19] (20 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-14] (121 pages) - Guidelines for Characterizing "OAM" [draft-ietf-opsawg-oam-characterization-04] (11 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-07] (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) - A YANG Model for Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3 [draft-ietf-opsawg-secure-tacacs-yang-00] (10 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-14] (18 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-18] (170 pages) - A Common YANG Data Model for Attachment Circuits [draft-ietf-opsawg-teas-common-ac-13] (64 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-06] (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) - Export of GTP-U Information in IP Flow Information Export (IPFIX) [draft-voyersriram-opsawg-ipfix-gtpu-07] (13 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) 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-10] (38 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 Tree Engineering for Bit Index Explicit Replication (BIER-TE) [draft-ietf-pce-bier-te-01] (17 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-07] (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-01] (19 pages) - Definitions of Managed Objects for Path Computation Element Discovery [draft-ietf-pce-disc-mib-04] (24 pages) - IGP protocol extensions for Path Computation Element (PCE) Discovery [draft-ietf-pce-disco-proto-igp-02] (37 pages) - IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery [draft-ietf-pce-disco-proto-isis-08] (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-02] (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 PCE Communication Protocol (PCEP) Registration Procedures and Allowing Experimental Error Codes [draft-ietf-pce-iana-update-03] (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-12] (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-05] (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-02] (41 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-06] (22 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-26] (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-18] (27 pages) - Carrying SR-Algorithm Information in PCE-based Networks. [draft-ietf-pce-sid-algo-14] (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-12] (27 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-10] (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-10] (12 pages) - Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE [draft-ietf-pce-stateful-sync-optimizations-10] (26 pages) - Procedures for Communication between Stateful Path Computation Elements [draft-ietf-pce-state-sync-09] (34 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) - Update to Automatic Bandwidth Adjustment procedure of Stateful PCE [draft-peng-pce-stateful-pce-autobw-update-02] (8 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-02] (8 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-02] (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-05] (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-08] (6 pages) - Host Threats to Protocol Independent Multicast (PIM) [draft-ietf-pim-lasthop-threats-04] (12 pages) - PIM Light [draft-ietf-pim-light-08] (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-07] (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-01] (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-01] (11 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-10] (22 pages) - Updates to Dynamic IPv6 Multicast Address Group IDs [draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-03] (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) Privacy Preserving Measurement (ppm) ------------------------------------ Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Benjamin M. Schwartz Sam Weiler Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Deb Cooley Mailing Lists: General Discussion: ppm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ppm Archive: https://mailarchive.ietf.org/arch/browse/ppm/ Description of Working Group: There are many situations in which it is desirable to take measurements of data which people consider sensitive. For instance, a browser company might want to measure web sites that do not render properly without learning which users visit those sites, or a public health authority might want to measure exposure to some disease without learning the identities of those exposed. In these cases, the entity taking the measurement is not interested in people's individual responses but rather in aggregated data (e.g., how many users had errors on site X). Conventional methods require collecting individual measurements in plaintext and then aggregating them, thus representing a threat to user privacy and rendering many such measurements difficult and impractical. New cryptographic techniques address this gap through a variety of approaches, all of which aim to ensure that the server (or multiple, non-colluding servers) can compute the aggregated value without learning the value of individual measurements. The Privacy Preserving Measurement (PPM) work will standardize protocols for deployment of these techniques on the Internet. This will include mechanisms for: - Client submission of individual measurements, potentially along with proofs of validity - Verification of validity proofs by the server(s), if sent by client - Computation of aggregate values by the server(s) and reporting of results to the entity taking the measurement A successful PPM system assumes that clients and servers are configured with each other's identities and details of the types of measurements to be taken. This is assumed to happen out of band and will not be standardized in this WG. The WG will deliver one or more protocols which can accommodate multiple PPM algorithms. The initial deliverables will support the calculation of simple predefined statistical aggregates such as averages, as well as calculations of the values that most frequently appear in individual measurements. The PPM protocols will use cryptographic algorithms and protocols defined by the CFRG to enable privacy-preserving properties. The protocol will be designed to limit abuse by both client and server, including exposure of individual user measurements and denial of service attacks on the measurement system. The resulting document(s) shall consider deployment contexts, and clearly describe abuse cases and remaining attacks which are not prevented or mitigated by the protocol(s). The starting point for PPM WG discussions shall be draft-gpew-priv-ppm. Goals and Milestones: Dec 2023 - Submit PPM protocol to IESG for publication Internet-Drafts: - Privacy Preserving Measurement [draft-gpew-priv-ppm-01] (46 pages) - Distributed Aggregation Protocol for Privacy Preserving Measurement [draft-ietf-ppm-dap-13] (93 pages) - Task Binding and In-Band Provisioning for DAP [draft-ietf-ppm-dap-taskprov-01] (20 pages) - Task Binding and In-Band Provisioning for DAP [draft-wang-ppm-dap-taskprov-07] (17 pages) No Requests for Comments Post-Quantum Use In Protocols (pquip) ------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Paul E. Hoffman Sofia Celi Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Paul Wouters Mailing Lists: General Discussion: pqc@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/pqc Archive: https://mailarchive.ietf.org/arch/browse/pqc/ Description of Working Group: Some IETF protocols rely upon cryptographic mechanisms that are considered secure given today’s “classical computers” but would be vulnerable to attacks by a Cryptographically Relevant Quantum Computer (CRQC). These mechanisms rely upon algorithms based on integer factorization or the discrete logarithm problem. Outside of the IETF, active work is underway to develop and validate Post-Quantum Cryptography (PQC) mechanisms that are expected to be resilient to the cryptanalysis capabilities of future CRQCs (e.g., CFRG, US NIST). Select IETF WGs (e.g., LAMPS, TLS, IPSECME, COSE) have already begun standardizing revised protocol behaviors. The focus of Post-Quantum Use in Protocols (PQUIP) WG is to support this growing body of work in the IETF to facilitate the evolution of IETF protocols and document associated operational guidance with respect to PQC. The WG will provide a standing venue to discuss PQC (operational and engineering) transition issues and experiences to date relevant to work in the IETF. The WG will also provide a venue of last resort to discuss PQC-related issues in IETF protocols that have no associated maintenance WGs. This WG will not update existing protocols, specify new protocols, define new cryptographic mechanisms, or assess whether a given cryptographic mechanism is quantum-resistant. The WG will document operational and design guidance which supports PQC transition. The general process of elaboration through documentation will be for issues to be identified and discussed on the mailing list, and presentations made at WG meetings. When topics merit more coherent documentation, the WG will adopt 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 Informational or Best Current Practices RFCs. At any point, from early discussion of topics through later documentation stages, the WG may identify a more appropriate WG for the matter, and with coordination, dispatch it there. The output of this WG is expended to inform protocol work and guidance developed by other WGs in the IETF. Consistent with other IETF WGs, this WG will also rely on outside entities (e.g., CFRG) to define and assess new PQC mechanisms. The IESG is establishing this working group on an experimental basis, and in 2 years, the IESG intends to review it for rechartering to continue or else closure. Goals and Milestones: Apr 2023 - WG Adoption of an Informational document that defines terminology for (hybrid) PQC schemes May 2023 - WG Adoption of an Informational document on ‘PQC for engineers’ Internet-Drafts: - Hybrid signature spectrums [draft-ietf-pquip-hybrid-signature-spectrums-03] (25 pages) - Post-Quantum Cryptography for Engineers [draft-ietf-pquip-pqc-engineers-06] (47 pages) - Terminology for Post-Quantum Traditional Hybrid Schemes [draft-ietf-pquip-pqt-hybrid-terminology-04] (18 pages) No Requests for Comments Privacy Pass (privacypass) -------------------------- Charter Last Modified: 2022-05-06 Current Status: Active Chairs: Benjamin M. Schwartz Joseph A. Salowey Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Paul Wouters Mailing Lists: General Discussion: privacy-pass@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/privacy-pass Archive: https://mailarchive.ietf.org/arch/browse/privacy-pass/ Description of Working Group: The Privacy Pass protocol provides a performant, application-layer mechanism for token creation and anonymous redemption. Servers (Issuers) create and later verify tokens that are redeemed by an ecosystem of clients, such that: - An Issuer cannot link a redeemed token to one of N previously created tokens using the same key with probability non-negligibly larger than 1/N. - Clients can verify that a token created by an Issuer corresponds to a committed keypair. - Tokens are unforgeable. - The token issuance and redemption mechanisms are efficient. The primary purpose of the Privacy Pass Working Group is to develop and standardize a protocol that meets these requirements, influenced by applications that have arisen from the wider community. The aims of the Working Group can be split into three distinct goals: First, specify an extensible protocol for creating and redeeming anonymous and transferrable tokens. The protocol should permit suitable cryptographic ciphersuites and security parameterization for cryptographic agility. The cryptographic profile used by the protocol participants will be determined by the specific instantiation of the protocol, and it will be fixed for the duration of an Issuer's committed keypair. We will work closely with the CFRG in determining acceptable cryptographic ciphersuites and parameters that satisfy the security and privacy properties of the protocol. The Working Group will specify a preliminary set of extensions, including Issuer-supplied metadata and cryptographic instantiations that additionally support public verifiability of Issued tokens, and may consider any additional extensions that arise in the future. Security and privacy properties of the protocol shall be well-documented. Formal analysis of the protocol will ensure that the security and privacy properties of the protocol are well-understood and well-documented. Second, describe and develop protocol use cases and properties thereof. This includes, though is not limited to: 1. Describing use cases and interfaces that allow the protocol to be used for those use cases. 2. Defining the privacy goals for each Client during protocol execution, along with expectations placed on the Issuers and the ecosystem at large. 3. Describing recommended parameterization(s) of variables associated with the protocol ecosystem that control the size of the anonymity set that the client belongs to. 4. Describing verification mechanisms for trusting Issuers and their corresponding keying material. Such mechanisms should prevent Issuers from presenting any key material that could be used to deanonymize clients. 5. Describing the procedure for including small amounts of metadata with Issued tokens, as well as the associated impacts on privacy. 6. Describing the risk and possible ramifications of Issuer centralization, and exploring possible mechanisms to mitigate these risks. Third, and finally, specify a HTTP-layer API for the protocol. This includes a common understanding of how Privacy Pass is integrated with HTTP requests and responses for web-based applications. The following milestones (along with the approximate dates of completion) will be used to judge the progress of the working group: - Specification of protocol & surrounding architecture - February 2021. - Risk assessment for centralization in Privacy Pass deployments for multiple design options - February 2021 - Specification of application-layer requirements (including HTTP integration) - June 2021. - Specification of HTTP browser API (in coordination with W3C) - October 2021. Note that the specifications developed by this working group will be informed by the following initial drafts: - draft-davidson-pp-protocol-00; - draft-davidson-pp-architecture-00; - draft-svaldez-pp-http-api-00. These existing drafts may be further developed into the core deliverables of the working group, supplemented by any additional extensions. Alternatively, they may contribute indirectly to a future set of documents that meet the core goals of the working group. Goals and Milestones: Internet-Drafts: - Privacy Pass: Architectural Framework [draft-davidson-pp-architecture-01] (22 pages) - Privacy Pass: The Protocol [draft-davidson-pp-protocol-01] (20 pages) - Checking Resource Consistency with HTTP Mirrors [draft-group-privacypass-consistency-mirror-01] (13 pages) - Public Metadata Issuance [draft-hendrickson-privacypass-public-metadata-03] (16 pages) - The Privacy Pass Architecture [draft-ietf-privacypass-architecture-16] (30 pages) - The Privacy Pass HTTP Authentication Scheme [draft-ietf-privacypass-auth-scheme-15] (27 pages) - The PrivateToken HTTP Authentication Scheme Extensions Parameter [draft-ietf-privacypass-auth-scheme-extensions-01] (8 pages) - Batched Token Issuance Protocol [draft-ietf-privacypass-batched-tokens-03] (17 pages) - Checking Resource Consistency with HTTP Mirrors [draft-ietf-privacypass-consistency-mirror-00] (13 pages) - Privacy Pass HTTP API [draft-ietf-privacypass-http-api-01] (12 pages) - Key Consistency and Discovery [draft-ietf-privacypass-key-consistency-01] (13 pages) - Privacy Pass Issuance Protocol [draft-ietf-privacypass-protocol-16] (40 pages) - Privacy Pass Issuance Protocols with Public Metadata [draft-ietf-privacypass-public-metadata-issuance-01] (16 pages) - Rate-Limited Token Issuance Protocol [draft-ietf-privacypass-rate-limit-tokens-06] (52 pages) - The Privacy Pass HTTP Authentication Scheme [draft-pauly-privacypass-auth-scheme-00] (12 pages) - Rate-Limited Token Issuance Protocol [draft-privacypass-rate-limit-tokens-03] (47 pages) - Batched Token Issuance Protocol [draft-robert-privacypass-batched-tokens-01] (9 pages) - Privacy Pass: HTTP API [draft-svaldez-pp-http-api-01] (12 pages) - Key Consistency and Discovery [draft-wood-key-consistency-03] (13 pages) - The PrivateToken HTTP Authentication Scheme Extensions Parameter [draft-wood-privacypass-auth-scheme-extensions-02] (6 pages) Requests for Comments: RFC9576: The Privacy Pass Architecture (25 pages) RFC9577: The Privacy Pass HTTP Authentication Scheme (25 pages) RFC9578: Privacy Pass Issuance Protocols (36 pages) QUIC (quic) ----------- Charter Last Modified: 2024-01-17 Current Status: Active Chairs: Lucas Pardue Matt Joras Web and Internet Transport Directors: Francesca Palombini Zaheduzzaman Sarker Web and Internet Transport Advisor: Zaheduzzaman Sarker Mailing Lists: General Discussion: quic@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/quic Archive: https://mailarchive.ietf.org/arch/browse/quic/ Description of Working Group: The QUIC WG originated the specifications describing version 1 of QUIC, a UDP-based, stream-multiplexing, encrypted transport protocol. The WG acts as the focal point for any QUIC-related work in the IETF. It is chartered to pursue work in the areas detailed below: 1. The first area of work is maintenance and evolution of the existing QUIC specifications: * Maintenance and evolution of the QUIC base specifications that describe its invariants, core transport mechanisms, security and privacy properties, loss detection and recovery, congestion control, version and extension negotiation, etc. This includes the specification of new versions of QUIC. * Maintenance and evolution of the existing QUIC extensions specified by the WG. WG adoption of work items falling into this first area of work needs to be strongly motivated by existing or ongoing production deployments of QUIC at scale, and needs to carefully consider its impact on the applications and higher-layer protocols (simply called "application protocols" in the rest of this charter) that have adopted QUIC as a transport. 2. The second area of work is supporting the deployability of QUIC, which includes specifications and documents such as applicability and manageability statements, improved operation with load balancers, the specification of a logging format, and more. 3. The third area of work is the specification of new extensions to QUIC. The WG will primarily focus on extensions to the QUIC transport layer, i.e., extensions to QUIC that have broad applicability to multiple application protocols. The WG may also publish specifications to publicly document deployed proprietary extensions or to enable wider experimentation with proposed new protocol features. Specifications describing how new or existing application protocols use the QUIC transport layer, called application protocol mappings below, need not be specified in the QUIC WG, although they can. The QUIC WG will collaborate with other groups that define such application protocols that intend to use QUIC. New application protocol mappings might require QUIC extensions and it may be efficient to define these alongside the mapping specifications. Groups that define application protocols using QUIC, or extensions to QUIC in support of those protocols, are strongly requested to consult with the QUIC WG and seek early and ongoing review of and collaboration on proposals. This is intended to reduce the possibility of duplicate work and/or conflicts with other extensions. The QUIC WG originated HTTP/3, the mapping of HTTP to QUIC, and the QPACK header compression scheme. These specifications are now maintained in the HTTP WG. Defining new congestion control schemes is explicitly out of scope for the WG. However, new QUIC extensions that support development and experimentation with new congestion control schemes may fall under the third work area. Goals and Milestones: - QUIC Acknowledgement Frequency to IESG - Reliable Stream Resets to IESG - Qlog documents to IESG - Multipath Extension to QUIC to IESG Sep 2021 - QUIC-LB: Generating Routable QUIC Connection IDs to IESG - QUIC Retry Offload to IESG Done - QUIC Applicability and Manageability Statement to IESG Done - Datagram Extension to IESG Done - Greasing the QUIC bit to IESG Done - Version Negotiation Extension to IESG Done - QUIC Version 2 to IESG Internet-Drafts: - QUIC-LB: Generating Routable QUIC Connection IDs [draft-duke-quic-load-balancers-06] (31 pages) - QUIC Retry Offload [draft-duke-quic-retry-offload-00] (24 pages) - QUIC Version 2 [draft-duke-quic-v2-02] (7 pages) - QUIC: A UDP-Based Multiplexed and Secure Transport [draft-hamilton-quic-transport-protocol-01] (45 pages) - QUIC Acknowledgment Frequency [draft-ietf-quic-ack-frequency-10] (18 pages) - Applicability of the QUIC Transport Protocol [draft-ietf-quic-applicability-18] (22 pages) - Greasing the QUIC Bit [draft-ietf-quic-bit-grease-04] (6 pages) - An Unreliable Datagram Extension to QUIC [draft-ietf-quic-datagram-10] (9 pages) - HTTP/3 [draft-ietf-quic-http-34] (57 pages) - Version-Independent Properties of QUIC [draft-ietf-quic-invariants-13] (9 pages) - QUIC-LB: Generating Routable QUIC Connection IDs [draft-ietf-quic-load-balancers-19] (42 pages) - Manageability of the QUIC Transport Protocol [draft-ietf-quic-manageability-18] (29 pages) - Multipath Extension for QUIC [draft-ietf-quic-multipath-11] (38 pages) - Header Compression for HTTP over QUIC [draft-ietf-quic-qcram-00] (11 pages) - HTTP/3 qlog event definitions [draft-ietf-quic-qlog-h3-events-09] (24 pages) - qlog: Structured Logging for Network Protocols [draft-ietf-quic-qlog-main-schema-10] (57 pages) - QUIC event definitions for qlog [draft-ietf-quic-qlog-quic-events-09] (64 pages) - QPACK: Field Compression for HTTP/3 [draft-ietf-quic-qpack-21] (41 pages) - QUIC Loss Detection and Congestion Control [draft-ietf-quic-recovery-34] (42 pages) - QUIC Stream Resets with Partial Delivery [draft-ietf-quic-reliable-stream-reset-06] (9 pages) - QUIC Retry Offload [draft-ietf-quic-retry-offload-00] (26 pages) - The QUIC Latency Spin Bit [draft-ietf-quic-spin-exp-01] (8 pages) - Using TLS to Secure QUIC [draft-ietf-quic-tls-34] (52 pages) - QUIC: A UDP-Based Multiplexed and Secure Transport [draft-ietf-quic-transport-34] (151 pages) - QUIC Version 2 [draft-ietf-quic-v2-10] (14 pages) - QUIC Version Aliasing [draft-ietf-quic-version-aliasing-00] (11 pages) - Compatible Version Negotiation for QUIC [draft-ietf-quic-version-negotiation-14] (15 pages) - Sender Control of Acknowledgement Delays in QUIC [draft-iyengar-quic-delayed-ack-02] (10 pages) - QUIC Congestion Control And Loss Recovery [draft-iyengar-quic-loss-recovery-01] (10 pages) - Header Compression for HTTP over QUIC [draft-krasic-quic-qcram-04] (9 pages) - Applicability of the QUIC Transport Protocol [draft-kuehlewind-quic-applicability-00] (7 pages) - Manageability of the QUIC Transport Protocol [draft-kuehlewind-quic-manageability-00] (10 pages) - Multipath Extension for QUIC [draft-lmbdhk-quic-multipath-00] (26 pages) - QUIC and HTTP/3 event definitions for qlog [draft-marx-qlog-event-definitions-quic-h3-02] (62 pages) - Main logging schema for qlog [draft-marx-qlog-main-schema-03] (47 pages) - HTTP/3 and QPACK event definitions for qlog [draft-marx-quic-qlog-h3-events-00] (21 pages) - QUIC event definitions for qlog [draft-marx-quic-qlog-quic-events-00] (42 pages) - An Unreliable Datagram Extension to QUIC [draft-pauly-quic-datagram-05] (9 pages) - Compatible Version Negotiation for QUIC [draft-schinazi-quic-version-negotiation-02] (8 pages) - HTTP/2 Semantics Using The QUIC Transport Protocol [draft-shade-quic-http2-mapping-00] (11 pages) - Greasing the QUIC Bit [draft-thomson-quic-bit-grease-01] (6 pages) - Version-Independent Properties of QUIC [draft-thomson-quic-invariants-00] (9 pages) - Using Transport Layer Security (TLS) to Secure QUIC [draft-thomson-quic-tls-01] (22 pages) Requests for Comments: RFC8999: Version-Independent Properties of QUIC (9 pages) * Updates RFC9368 RFC9000: QUIC: A UDP-Based Multiplexed and Secure Transport (151 pages) RFC9001: Using TLS to Secure QUIC (52 pages) RFC9002: QUIC Loss Detection and Congestion Control (42 pages) RFC9114: HTTP/3 (57 pages) RFC9204: QPACK: Field Compression for HTTP/3 (41 pages) RFC9221: An Unreliable Datagram Extension to QUIC (9 pages) RFC9287: Greasing the QUIC Bit (6 pages) RFC9308: Applicability of the QUIC Transport Protocol (22 pages) RFC9312: Manageability of the QUIC Transport Protocol (29 pages) RFC9368: Compatible Version Negotiation for QUIC (15 pages) RFC9369: QUIC Version 2 (14 pages) RADIUS EXTensions (radext) -------------------------- Charter Last Modified: 2024-11-05 Current Status: Active Chairs: Margaret Cullen Valery Smyslov Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Paul Wouters Mailing Lists: General Discussion: radext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/radext Archive: https://mailarchive.ietf.org/arch/browse/radext/ Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol. To ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, all documents produced must specify means of interoperation with legacy RADIUS. Any non-backwards compatibility changes with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090, 5176 and 6158 must be justified. Transport profiles should be compatible with RFC 3539, with any non-backwards compatibility changes justified. The WG will review its existing RFCs' document track categories and where necessary or useful change document tracks, with minor changes in the documents if needed. Work Items The immediate goals of the RADEXT working group are: - Deprecating the use of insecure transports outside of secure networks. This work updates RFC 6421. - Bring RFC 6614 (RADIUS/TLS), and RFC 7360 (RADIUS/DTLS) to Standards track. - Define best practices for using TLS-PSK with TLS-based transport. - Define best practices for RADIUS roaming, and roaming consortia based on experience with RADIUS/TLS. - Improve operations for multi-hop RADIUS networks: e.g. loop detection and prevention, a multi-hop Status-Server equivalent with ability to Trace the proxy steps a RADIUS message will follow. - Extend the 8-bit RADIUS ID space to allow more than 256 "in flight" packets across one connection. - Allow for CoA / Disconnect packets to be sent in "reverse" down a RADIUS/TLS or RADIUS/DTLS connection. This functionality assists with transit of NATs. - Defining Application-Layer Protocol Negotiation (ALPN) extensions for RADIUS/TLS and RADIUS/TLS which allow the use of those transports in a FIPS-140 compliant environment. Timeline: Much of this work should be completed by 2024 in order to be part of the Wi-Fi 8 release, with products in 2026. Goals and Milestones: Aug 2023 - reverse change of authorization (CoA)" path support for RADIUS Jan 2024 - 6614bis and 7360bis to IESG Jan 2024 - Deprecating Insecure Uses of RADIUS to IESG May 2024 - Extend 8-bit ID Space to IESG May 2024 - multi-hop status / traceroute, extend 8-bit ID space Done - ALPN negotiation Done - TLS-PSK Best Practices Internet-Drafts: - Status-Realm and Loop Prevention for the Remote Dial-In User Service (RADIUS) [draft-cullen-radextra-status-realm-01] (23 pages) - Dynamic Authorization Proxying in Remote Authorization Dial-In User Service Protocol (RADIUS) [draft-dekok-radext-coa-proxy-00] (10 pages) - Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS) [draft-dekok-radext-datatypes-06] (32 pages) - Deprecating Insecure Practices in RADIUS [draft-dekok-radext-deprecating-radius-05] (34 pages) - The Network Access Identifier [draft-dekok-radext-nai-02] (19 pages) - RADIUS Version 1.1 [draft-dekok-radext-radiusv11-05] (27 pages) - Reverse CoA in RADIUS [draft-dekok-radext-reverse-coa-01] (10 pages) - RADIUS and TLS-PSK [draft-dekok-radext-tls-psk-01] (11 pages) - Larger Packets for RADIUS over TCP [draft-ietf-radext-bigger-packets-07] (10 pages) - Chargeable User Identity [draft-ietf-radext-chargeable-user-id-06] (10 pages) - Dynamic Authorization Proxying in the Remote Authentication Dial-In User Service (RADIUS) Protocol [draft-ietf-radext-coa-proxy-10] (21 pages) - Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS) [draft-ietf-radext-crypto-agility-requirements-07] (12 pages) - Data Types in RADIUS [draft-ietf-radext-datatypes-08] (35 pages) - RADIUS Delegated-IPv6-Prefix Attribute [draft-ietf-radext-delegated-prefix-05] (7 pages) - Deprecating Insecure Practices in RADIUS [draft-ietf-radext-deprecating-radius-04] (78 pages) - RADIUS Design Guidelines [draft-ietf-radext-design-19] (38 pages) - RADIUS Extension for Digest Authentication [draft-ietf-radext-digest-auth-09] (32 pages) - Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS [draft-ietf-radext-dtls-13] (27 pages) - Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI) [draft-ietf-radext-dynamic-discovery-15] (32 pages) - RADIUS Dynamic Authorization Client MIB [draft-ietf-radext-dynauth-client-mib-06] (24 pages) - RADIUS Dynamic Authorization Server MIB [draft-ietf-radext-dynauth-server-mib-06] (24 pages) - Extended Remote Authentication Dial In User Service (RADIUS) Attributes [draft-ietf-radext-extended-attributes-09] (13 pages) - RADIUS Filter Rule Attribute [draft-ietf-radext-filter-08] (9 pages) - RADIUS Attributes for Filtering and Redirection [draft-ietf-radext-filter-rules-03] (30 pages) - Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes [draft-ietf-radext-fixes-08] (28 pages) - VLAN, Priority, and Filtering Attributes [draft-ietf-radext-ieee802-01] (32 pages) - RADIUS Attributes for IEEE 802 Networks [draft-ietf-radext-ieee802ext-12] (29 pages) - RADIUS Extensions for IP Port Configuration and Reporting [draft-ietf-radext-ip-port-radius-ext-17] (43 pages) - RADIUS Attributes for IPv6 Access Networks [draft-ietf-radext-ipv6-access-16] (15 pages) - Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management [draft-ietf-radext-management-authorization-07] (25 pages) - The Network Access Identifier [draft-ietf-radext-nai-15] (30 pages) - Considerations regarding the correct use of EAP-Response/Identity [draft-ietf-radext-populating-eapidentity-01] (10 pages) - (Datagram) Transport Layer Security ((D)TLS Encryption for RADIUS [draft-ietf-radext-radiusdtls-bis-03] (40 pages) - Remote Authentication Dial In User Service (RADIUS) Protocol Extensions [draft-ietf-radext-radius-extensions-13] (68 pages) - Support of Fragmentation of RADIUS Packets [draft-ietf-radext-radius-fragmentation-12] (38 pages) - RADIUS/1.1, Leveraging ALPN to remove MD5 [draft-ietf-radext-radiusv11-11] (41 pages) - Transport Layer Security (TLS) Encryption for RADIUS [draft-ietf-radext-radsec-12] (22 pages) - Reverse CoA in RADIUS [draft-ietf-radext-reverse-coa-01] (11 pages) - The Network Access Identifier [draft-ietf-radext-rfc2486bis-06] (16 pages) - RADIUS Authentication Client MIB for IPv6 [draft-ietf-radext-rfc2618bis-04] (24 pages) - RADIUS Authentication Server MIB for IPv6 [draft-ietf-radext-rfc2619bis-04] (25 pages) - RADIUS Accounting Client MIB for IPv6 [draft-ietf-radext-rfc2620bis-04] (23 pages) - RADIUS Accounting Server MIB for IPv6 [draft-ietf-radext-rfc2621bis-04] (24 pages) - Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) [draft-ietf-radext-rfc3576bis-13] (34 pages) - RADIUS Extension for Digest Authentication [draft-ietf-radext-rfc4590bis-02] (33 pages) - Status-Realm and Loop Prevention for the Remote Dial-In User Service (RADIUS) [draft-ietf-radext-status-realm-00] (23 pages) - Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol [draft-ietf-radext-status-server-09] (24 pages) - RADIUS over TCP [draft-ietf-radext-tcp-transport-09] (16 pages) - Operational Considerations for RADIUS and TLS-PSK [draft-ietf-radext-tls-psk-11] (24 pages) - New Tunnel-Type Values [draft-ietf-radext-tunnel-type-00] (6 pages) - RADIUS Attributes for Virtual LAN and Priority Support [draft-ietf-radext-vlan-06] (15 pages) - (Datagram) Transport Layer Security ((D)TLS Encryption for RADIUS [draft-janfred-radext-radiusdtls-bis-00] (30 pages) - Transport Layer Security (TLS) Encryption for RADIUS [draft-rieckers-radext-rfc6614bis-02] (20 pages) - Considerations regarding the correct use of EAP-Response/Identity [draft-winter-radext-populating-eapidentity-01] (7 pages) Requests for Comments: RFC4282: The Network Access Identifier (16 pages) * Obsoletes RFC7542 RFC4372: Chargeable User Identity (10 pages) RFC4590: RADIUS Extension for Digest Authentication (32 pages) * Obsoletes RFC5090 RFC4668: RADIUS Authentication Client MIB for IPv6 (24 pages) RFC4669: RADIUS Authentication Server MIB for IPv6 (25 pages) RFC4670: RADIUS Accounting Client MIB for IPv6 (23 pages) RFC4671: RADIUS Accounting Server MIB for IPv6 (24 pages) RFC4672: RADIUS Dynamic Authorization Client MIB (24 pages) RFC4673: RADIUS Dynamic Authorization Server MIB (24 pages) RFC4675: RADIUS Attributes for Virtual LAN and Priority Support (15 pages) RFC4818: RADIUS Delegated-IPv6-Prefix Attribute (7 pages) RFC4849: RADIUS Filter Rule Attribute (9 pages) RFC5080: Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes (28 pages) RFC5090: RADIUS Extension for Digest Authentication (33 pages) RFC5176: Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) (34 pages) * Updates RFC8559 RFC5607: Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management (25 pages) RFC5997: Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol (24 pages) RFC6158: RADIUS Design Guidelines (38 pages) * Updates RFC6929 * Updates RFC8044 RFC6421: Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS) (12 pages) RFC6613: RADIUS over TCP (16 pages) * Updates RFC7930 RFC6614: Transport Layer Security (TLS) Encryption for RADIUS (22 pages) * Updates RFC8996 RFC6911: RADIUS Attributes for IPv6 Access Networks (15 pages) RFC6929: Remote Authentication Dial In User Service (RADIUS) Protocol Extensions (68 pages) RFC7268: RADIUS Attributes for IEEE 802 Networks (29 pages) * Updates RFC8044 RFC7360: Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS (27 pages) RFC7499: Support of Fragmentation of RADIUS Packets (38 pages) RFC7542: The Network Access Identifier (30 pages) RFC7585: Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI) (32 pages) RFC7930: Larger Packets for RADIUS over TCP (10 pages) RFC8044: Data Types in RADIUS (35 pages) RFC8045: RADIUS Extensions for IP Port Configuration and Reporting (43 pages) RFC8559: Dynamic Authorization Proxying in the Remote Authentication Dial-In User Service (RADIUS) Protocol (21 pages) Remote ATtestation ProcedureS (rats) ------------------------------------ Charter Last Modified: 2024-11-07 Current Status: Active Chairs: Kathleen Moriarty Ned Smith Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Deb Cooley Mailing Lists: General Discussion: rats@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/rats Archive: https://mailarchive.ietf.org/arch/browse/rats/ Description of Working Group: # Introduction In network protocol exchanges, it is often the case that one entity (a Relying Party) requires evidence about the remote peer (and system components [RFC4949] thereof), in order to assess the trustworthiness of the peer. Remote attestation procedures (RATS) determine whether relying parties can establish a level of confidence in the trustworthiness of remote peers, called Attesters. The objective is achieved by a two-stage appraisal procedure facilitated by a trusted third party, called Verifier, with trusted links to the supply chain. The procedures for the two stages are: * Evidence Appraisal: a Verifier applies policy and supply chain input, such as Endorsements and References Values, to create Attestation Results from Evidence. * Attestation Results Appraisal: a Relying Party applies policy to Attestation Results associated with an Attester's Evidence that originates from a trusted Verifier. The results are trust decisions regarding the Attester. To improve the confidence in a system component's trustworthiness, a relying party may require evidence about: * system component identity, * composition of system components, including nested components, * roots of trust, * an assertion/claim origination or provenance, * manufacturing origin, * system component integrity, * system component configuration, * operational state and measurements of steps which led to the operational state, or * other factors that could influence trust decisions. While domain-specific attestation mechanisms such as Trusted Computing Group (TCG) Trusted Platform Module (TPM)/TPM Software Stack (TSS), Fast Identity Online (FIDO) Alliance attestation, and Android Keystore attestation exist, there is no interoperable way to create and process attestation evidence to make determinations about system components among relying parties of different manufactures and origins. # Goals The WG has defined an architecture (draft-ietf-rats-architecture) for remote attestation. The WG will standardize formats for describing evidence and attestation results and the associated procedures and protocols to convey evidence for appraisal to a verifier and attestation results to a relying party. Additionally, the WG will standardize formats for endorsements and reference values, and may apply and/or profile existing protocols (e.g., DTLS, CoAP, or MUD) to convey them to the verifier. Formats and protocols for appraisal policy for evidence and appraisal policy for attestation results are out of scope. The WG will continue to cooperate and coordinate with other IETF WGs such as TEEP, SUIT, CoRE, ACE, and CBOR; and work with organizations in the community, such as the TCG, Global Platform, and the FIDO Alliance, as appropriate. # Program of Work The working group will develop standards supporting interoperable remote attestation procedures for system components. The main deliverables are as follows: 1. Specify use cases for remote attestation (to document and achieve WG consensus but not expected to be published as an RFC). 2. Specify augmentations to the RATS architecture (draft-ietf-rats-architecture) in support of specific attestation techniques. 3. Standardize an information model for evidence and attestations results scoped by the specified use-cases. 4. Standardize data models that implement and secure the defined information model (e.g., CBOR Web Token structures [RFC8392], JSON Web Token structures [RFC7519]). 5. If feasible, use or extend existing protocols to securely convey evidence and attestation results, or if not, then standardize interoperable protocols for this purpose. 6. Standardize interoperable data formats to securely declare and convey endorsements and reference values. Goals and Milestones: Jul 2023 - Submit CBOR Tag for Unprotected CWT Claim sets to WGLC Nov 2023 - Submit Attestation Results for Secure Interactions for WGLC Nov 2023 - Submit Reference Interaction Models Nov 2023 - Submit Network Device Subscription for publication Dec 2023 - Submit Direct Anonymous Attestation for RATs for publication Dec 2023 - Submit Concise Reference Integrity and Endorsement Manifests to WGLC Dec 2023 - Submit CBOR Tag for Unprotected CWT Claim sets for publication Dec 2023 - Submit Entity Attestation Token for publication Dec 2023 - Submit Network Device Subscription to WGLC Dec 2023 - Submit Direct Anonymous Attestation for RATs to WGLC Dec 2023 - Submit Attestation Results for Secure Interactions for publication Dec 2023 - Submit Reference Interaction Models to WGLC Mar 2024 - Submit Concise Reference Integrity and Endorsement Manifests for publication Jul 2024 - Submit EAT Media types for publication Nov 2024 - Submit RATS Conceptual Message Wrapper for WGLC Done - Call for adoption on Concise Reference Integrity and Endorsement Manifests Done - Submit EAT Media types to WGLC Internet-Drafts: - Concise Reference Integrity Manifest [draft-birkholz-rats-corim-03] (32 pages) - Epoch Markers [draft-birkholz-rats-epoch-markers-08] (17 pages) - EAT Measured Component [draft-fft-rats-eat-measured-component-03] (14 pages) - Attestation Results for Secure Interactions [draft-ietf-rats-ar4si-07] (35 pages) - Remote ATtestation procedureS (RATS) Architecture [draft-ietf-rats-architecture-22] (46 pages) - Concise TA Stores (CoTS) [draft-ietf-rats-concise-ta-stores-02] (25 pages) - Concise Reference Integrity Manifest [draft-ietf-rats-corim-06] (99 pages) - Direct Anonymous Attestation for the Remote Attestation Procedures Architecture [draft-ietf-rats-daa-06] (10 pages) - The Entity Attestation Token (EAT) [draft-ietf-rats-eat-31] (101 pages) - EAT Measured Component [draft-ietf-rats-eat-measured-component-00] (14 pages) - EAT Media Types [draft-ietf-rats-eat-media-type-12] (14 pages) - RATS Endorsements [draft-ietf-rats-endorsements-05] (12 pages) - Epoch Markers [draft-ietf-rats-epoch-markers-00] (17 pages) - RATS Conceptual Messages Wrapper (CMW) [draft-ietf-rats-msg-wrap-10] (33 pages) - Attestation Event Stream Subscription [draft-ietf-rats-network-device-subscription-05] (25 pages) - PKI-based Attestation Evidence [draft-ietf-rats-pkix-evidence-00] (25 pages) - Remote Posture Assessment for Systems, Containers, and Applications at Scale [draft-ietf-rats-posture-assessment-01] (13 pages) - Reference Interaction Models for Remote Attestation Procedures [draft-ietf-rats-reference-interaction-models-11] (30 pages) - TPM-based Network Device Remote Integrity Verification [draft-ietf-rats-tpm-based-network-device-attest-14] (45 pages) - A CBOR Tag for Unprotected CWT Claims Sets [draft-ietf-rats-uccs-12] (20 pages) - A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs [draft-ietf-rats-yang-tpm-charra-23] (60 pages) - EAT Media Types [draft-lundblade-rats-eat-media-type-00] (12 pages) - Remote Posture Assessment for Systems, Containers, and Applications [draft-moriarty-rats-posture-assessment-01] (12 pages) - PKI-based Attestation Evidence [draft-ounsworth-rats-pkix-evidence-00] (25 pages) Requests for Comments: RFC9334: Remote ATtestation procedureS (RATS) Architecture (46 pages) 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" 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 "Registry Data Escrow Specification" Done - Submit for publication "Domain Name Registration Data (DNRD) Objects Mapping" 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 "Registration Data Access Protocol (RDAP) Query Format" Done - Submit for publication "JSON Responses for the Registration Data Access Protocol (RDAP)" 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" Done - Submit for publication "Best Practices for Deletion of Domain and Host Objects in the Extensible Provisioning Protocol (EPP)" 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-22] (26 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-17] (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-04] (23 pages) - An RDAP Extension for Geofeed Data [draft-ietf-regext-rdap-geofeed-08] (13 pages) - Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses [draft-ietf-regext-rdap-jscontact-19] (27 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-11] (25 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-02] (33 pages) - An RDAP With Extensions Media Type [draft-ietf-regext-rdap-x-media-type-02] (16 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) 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 experienced substantial growth, commonly hosting tens of thousands or more end points in a single network. The unique characteristics of data center networks driven by their topologies (both traditional and emerging), traffic patterns, requirements for rapid restoration, and a need for minimal human intervention, necessitates specialized routing solutions. The adoption of Clos and Fat-Tree topologies has become prevalent in data center networks, particularly in centralized architectures designed to deliver computation and storage services efficiently. The Routing in Fat Trees (RIFT) protocol has been developed to meet the specific routing needs of Clos and Fat-Tree networks. RIFT employs a hybrid approach, combining elements of both link-state and distance-vector routing techniques, which can be colloquially described as 'link-state towards the spine and distance vector towards the leaves'. This approach is optimized for networks characterized by regular topologies with a high degree of connectivity, defined directionality, and large scale. The RIFT Working Group has completed the base protocol specification. Building upon this foundation, the Working Group will continue to develop standards-track specifications in the following areas: - Key-Value Data Store: Development of a key-value data store to enhance RIFT protocol functionality. - Policy Guided Prefix: Specification of mechanisms to enable policy-guided prefix distribution. - MPLS: RIFT extensions to support the MPLS data plane. - Segment Routing: RIFT extensions to support Segment Routing, enhancing routing flexibility and scalability. - Zero Touch Provisioning (ZTP) integration: Leveraging RIFT ZTP procedures as a management plane to carry attributes that enable the provisioning and instantiation of other protocols, including: - EVPN: Distribution of Ethernet VPN (EVPN) attributes, such as Virtual Network Identifiers (VNIs), Route Targets (RTs), and Route Distinguishers (RDs), as defined in RFC7342. - IS-IS: Distribution of Flood Reflection attributes, such as Flood Reflection Cluster IDs, and related IS-IS attributes, as defined in RFC9377. - Multicast: Extensions to RIFT to support the construction of multicast trees within the network. - Leaf Ring Topologies: Extensions to RIFT to facilitate the creation and management of leaf ring topologies. - Dragonfly Topologies: Extensions to RIFT to support the construction of Top-of-Fabric (ToF) ring topologies. The goal of the RIFT Working Group is to ensure that the RIFT protocol evolves in a manner that meets the current and future needs of large-scale, highly connected data center networks, with a focus on efficiency and scalability. The RIFT Working Group will cooperate with other Working Groups as necessary. Key interactions include (but are not limited to): * SPRING WG: Close cooperation on RIFT protocol extensions, new requirements, and operational considerations. * BESS WG: Cooperation on RIFT-based protocol extensions for BGP-enabled services, new service transport requirements, and functional considerations. * LSR WG: Cooperation on RIFT-based LSR extensions, new RIFT-based attributes and encodings, and functional considerations. * PIM WG: Cooperation on RIFT-based PIM extensions, new RIFT-based attributes and encodings, and functional considerations. * BIER WG: Cooperation on RIFT-based BIER protocol extensions, new RIFT-based attributes and encodings, and functional 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 - Submit RIFT Auto-EVPN specification to IESG for publication Dec 2024 - Submit RIFT Key-Value Data Store specification to IESG for publication Apr 2025 - Submit RIFT for ISIS flood reflection specification to IESG for publication Apr 2025 - Submit RIFT Segment Routing MPLS specification to IESG for publication Dec 2025 - Submit RIFT Multicast specification to IESG for publication 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 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 Done - Initial submission of Fast Border Router Crash Detection 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-07] (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-27] (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-02] (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-18] (27 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) - A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP) [draft-ietf-rtgwg-vrrp-rfc8347bis-00] (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) 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-07] (36 pages) - Secure Asset Transfer (SAT) Use Cases [draft-ietf-satp-usecases-04] (20 pages) - Secure Asset Transfer (SAT) Use Cases [draft-ramakrishna-sat-use-cases-02] (12 pages) No Requests for Comments 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: - Inter-domain Source Address Validation (SAVNET) Architecture [draft-ietf-savnet-inter-domain-architecture-00] (41 pages) - 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-01] (21 pages) - Source Address Validation in Intra-domain Networks Gap Analysis, Problem Statement, and Requirements [draft-ietf-savnet-intra-domain-problem-statement-07] (16 pages) - Source Address Validation Using BGP UPDATEs, ASPA, and ROA (BAR-SAV) [draft-ietf-sidrops-bar-sav-05] (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) - Inter-domain Source Address Validation (SAVNET) Architecture [draft-wu-savnet-inter-domain-architecture-12] (41 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 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: 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 FEC for fragments Dec 2024 - Request for publication of a standard track specification of Operations, Administration, and Maintenance (OAM) 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 of a standard track specification SCHC over IP Mar 2025 - Request for publication of a standard track specification for rules provisioning Done - WG adoption of a standard track specification for SCHC over PPP Done - WG adoption of an information document about SCHC architecture Done - WG adoption of a standard track specification of Operations, Administration, and Maintenance (OAM) Internet-Drafts: - Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) [draft-ietf-schc-8824-update-03] (88 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 (SCHC) for the Internet Control Message Protocol (ICMPv6) [draft-ietf-schc-icmpv6-compression-00] (21 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 System for Cross-domain Identity Management (scim) -------------------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Aaron Parecki Nancy Cam-Winget Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Deb Cooley Mailing Lists: General Discussion: scim@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/scim Archive: https://mailarchive.ietf.org/arch/browse/scim/ Description of Working Group: The System for Cross-domain Identity Management (SCIM) specifications provide an HTTP-based protocol (RFC7643) and schema (RFC7644) that makes managing identities in multi-domain scenarios easier. Since its publication in 2015, SCIM has seen growing adoption. The first goal of this working group is to incorporate implementation experience; errata and interoperability feedback; and current security and best practices into a revised version of RFC7643 (protocol) and RFC7644 (base schema) suitable for consideration at the Internet Standard level of specification maturity. Additionally, implementation experience with SCIM has surfaced new use cases and requirements. The WG will document them in a revision of RFC7642. The WG will also consider publishing extensions to SCIM that have found broad adoption. These extensions may include profiles and schemas for interoperability in additional use cases. The scope of work for the SCIM WG is: * Revision of RFC7642 that will: * Focus on Use cases and implementation patterns * Pull vs. Push based use cases * Events and signals use cases * Deletion use cases * New use cases may be added to the revised RFC * Revision of RFC7643 and RFC7644 that will include: * Profiling SCIM relationships with other identity-centric protocols such as OAuth 2.0, OpenID Connect, Shared Signals, and Fastfed * Updates to the evolution of the externalid usage * Updates to account state for capturing context of the state or change in state of the users account * Multi-Value Query Filtering and Paging (will use draft-hunt-scim-mv-paging as input) * Define a method for coordinating resources between domains: * Incremental approach to synchronization * Consider building off of RFC8417 and draft-hunt-idevent-scim * Support for deletion-related goals including: * Handling Deletes in SCIM Servers that don’t allow Deletes (Soft Deletes) (will use draft-ansari-scim-soft-delete as input) * Support for advanced automation scenarios such as: * Discovery and negotiation of client credentials * Attribute mapping * Per-attribute schema negotiation * Enhance the existing schema to support exchanging of human resources, enterprise group and privileged access management (will use draft-grizzle-scim-pam-ext as input) Goals and Milestones: Dec 2021 - Working group adoption of I-D for revising RFC7642 Dec 2021 - Working group adoption of I-Ds for Soft Delete Mar 2022 - Working group adoption of I-Ds (either new or existing) for privileged access management Mar 2022 - Working group adoption of I-Ds for Multi-valued paging Mar 2022 - Working Group adoption of I-Ds for coordination/synchronization between domains Jun 2022 - Progress I-D revising RFC7642 to WGLC Jun 2022 - Working group adoption of I-D revising RFC7643 Jun 2022 - Working group adoption of I-D revising RFC7644 Dec 2022 - Progress I-Ds for Soft Delete to WGLC Dec 2022 - Progress I-Ds for Multi-valued paging to WGLC Mar 2023 - Progress I-Ds (either new or existing) for privileged access management to WGLC Jun 2023 - Progress I-Ds for coordination/synchronization between domains to WGLC Jun 2023 - Progress I-D revising RFC7643 to WGLC Jun 2023 - Progress I-D revising RFC7644 to WGLC Internet-Drafts: - System for Cross-domain Identity Management: Protocol [draft-ietf-scim-api-19] (89 pages) - System for Cross-domain Identity Management: Core Schema [draft-ietf-scim-core-schema-22] (104 pages) - Cursor-based Pagination of SCIM Resources [draft-ietf-scim-cursor-pagination-05] (17 pages) - Device Schema Extensions to the SCIM model [draft-ietf-scim-device-model-09] (73 pages) - SCIM Profile for Security Event Tokens [draft-ietf-scim-events-06] (35 pages) - SCIM Roles and Entitlements Extension [draft-ietf-scim-roles-entitlements-00] (15 pages) - System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements [draft-ietf-scim-use-cases-08] (19 pages) Requests for Comments: RFC7642: System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements (19 pages) RFC7643: System for Cross-domain Identity Management: Core Schema (104 pages) RFC7644: System for Cross-domain Identity Management: Protocol (89 pages) Supply Chain Integrity, Transparency, and Trust (scitt) ------------------------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Christopher Inacio Jon Geater Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Deb Cooley Mailing Lists: General Discussion: scitt@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/scitt Archive: https://mailarchive.ietf.org/arch/browse/scitt/ Description of Working Group: Introduction ============ The Supply Chain Integrity, Transparency, and Trust (SCITT) WG will define a set of interoperable building blocks that will allow implementers to build integrity and accountability into software supply chain systems to help assure trustworthy operation. For example, a public computer interface system could report its software composition that can then be compared against known software compositions or certifications for such a device thereby giving confidence that the system is running the software expected and has not been modified, either by attack or accident, in the supply chain. Problem Statement ================= Some of the fundamental security issues that face the supply chain ecosystem today are as follows: 1. A single product is composed of multiple sub-products coming from different suppliers. There are several standards to compose supply chain information with different producers choosing different methods. 2. There are no uniform APIs or services to publish supply chain information to third parties, nor are there ways to verify the integrity or date of publication of that information. 3. There is a lack of decentralized, globally interoperable, transparent services to publish supply chain data. 4. The lack of sufficient standards for independently verifying the presence of supply chain data in tamper-proof data stores. 5. Fractured verification methodologies across software distribution ecosystems create inconsistent security guarantees for end users. 6. Software consumers have no trustworthy way to verify that a software signature on a software package is legitimate. A minimal, simple, and concise set of building blocks that interact in a standardized way will assure long-term accountability and interoperability for supply chain components throughout their lifecycles across architecturally diverse systems. Goals ===== Based on an input document on the architecture (draft-birkholz-scitt-architecture), the WG will standardize the technical flows for providing information about a software supply chain, which also includes firmware, and covering the essential building blocks that make up the architecture. The WG will: - reuse existing work from IETF WGs such as COSE and RATS, as appropriate, - coordinate with other standards bodies, such as the OpenSSF, W3C, ISO, and the Trusted Computing Group. Non-Goals ========= The WG does not: 1. make recommendations or suggestions on best practices on how to design the supply chain, 2. establish a universal/centralized registry for supply chain data, 3. define methods to prevent authenticated supply chain issuers from making false claims, 4. define data formats for payload content, such as Bills of Materials data formats. Program of Work =============== Documents produced by the working group will address one or more of the following programs of work: ## Architectural Model: Actors, Interactions, Terminology The WG shall start by documenting and defining terms in an architectural model for: 1. essential actors, such as the claim's "issuer" (one which generates supply chain artifacts and statements about them), "notary", and "consumer" and 2. the basic interactions these have with other actors, and their duties in the ecosystem. The architectural model shall provide an aggregated overview of corresponding actor-specific information models and interaction models. It will provide examples of composition patterns that illustrate how to address a concise set of use cases. The architectural model shall include an abstract threat model that minimally encompasses the initial use cases and will be based on a set of to be defined security objectives. ## Consistent Actor Identification The WG shall select (and potentially profile) acceptable common identity format/formats that will be used to identify and authenticate various actors in the SCITT ecosystem. The WG shall create guidance on how to create and manage new identity documents, their trust anchors, and corresponding security considerations in the context of supply chains. ## Information Models and Interaction Models for: 1. Registry: The WG shall define an Abstract Transparent Registry and also define the interactions and conceptual messages that will be supported by registries with an aim to generate homogeneity across multiple supply chains. 2. Notarization: The WG shall develop a specification that describes the notarization information model and the interaction model a notary will use to interact with supply chain entities. 3. Auditing: The WG shall develop standards to permit auditing of supply chain claims that are introduced in the transparent registry. This will, in turn, generate audit claims based on an information model (results of an audit), which can be introduced in the same registry. A corresponding interaction model will describe how audit information can be queried by supply chain consumers (e.g., end customers) before making critical business decisions. ## Versatile Countersigning Format in Support of Transparency Services The WG shall specify a standard format for authenticity data returned from the transparent registry such as proofs, etc. The standard shall enable independent verification of supply chain claims at a (much) later point on multiple platforms across multiple geographical locations. ## Generic Protocol Bindings for Information Model and Interaction Models The WG shall standardize request-response interactions ("external API") and potentially other generic interaction schemes provided to various external entities to interact with the supply chain ecosystem. This includes standardizing inter-component messages (based on the interaction models) and payload serialization between supply chain actors to support common reference implementations of SCITT building blocks by various organizations to expedite industry-wide adaptation. Goals and Milestones: Dec 2023 - Submit an Architecture and Terminology document to the IESG for publication Dec 2023 - Submit a Use Cases, Security Objectives, and concise Threat Model document to the IESG for publication Mar 2024 - Submit an Information and Interaction Model to the IESG for publication Jun 2024 - Submit a Countersigning Format for Claim Registration document to the IESG for publication Jun 2024 - Submit an HTTP-based REST API for Request-Response Interactions document to the IESG for publication Internet-Drafts: - An Architecture for Trustworthy and Transparent Digital Supply Chains [draft-ietf-scitt-architecture-10] (43 pages) - SCITT Reference APIs [draft-ietf-scitt-scrapi-02] (25 pages) - Detailed Software Supply Chain Uses Cases for SCITT [draft-ietf-scitt-software-use-cases-03] (15 pages) No Requests for Comments Standard Communication with Network Elements (scone) ---------------------------------------------------- Charter Last Modified: 2024-10-29 Current Status: Active Chairs: Brian Trammell Qin Wu Web and Internet Transport Directors: Francesca Palombini Zaheduzzaman Sarker Web and Internet Transport Advisor: Zaheduzzaman Sarker Mailing Lists: General Discussion: scone@ietf.org To Subscribe: https://mailman3.ietf.org/mailman3/lists/scone.ietf.org/ Archive: https://mailarchive.ietf.org/arch/browse/scone Description of Working Group: ## Background Many applications are capable of adjusting their bit rate based on network conditions and attempt to understand what bitrate is usable for a given network UDP 4-tuple. Some networks use rate-limiters to influence these applications. However, when networks enforce rate-limiters, applications like video streaming or conferencing struggle to adapt, leading to a suboptimal user experience. ## Goals This WG aims to establish a mechanism for network elements capable of rate-limiting a UDP 4-tuple to communicate an upper bound on achievable bitrate, termed "throughput advice", to the sender of packets matching the UDP 4-tuple. This mechanism will allow an application to receive notifications containing throughput advice for both upstream and downstream traffic from any network elements capable of dropping or delaying packets on the path of a UDP 4-tuple. The throughput advice serves as a guideline to enhance user experience and represents the maximum bitrate manageable by a single network element for that user's current connection. It is not a strict indicator of network congestion. This mechanism focuses on throughput advice intended for adaptive bitrate applications and is not a replacement for congestion control algorithms. Owing to the possibly dynamic nature of throughput advice, network elements may need to provide updates on the throughput advice. To achieve the goals listed above, the working group will determine whether it is necessary for an endpoint to explicitly signal its capability of receiving throughput advice, and whether it is necessary for an endpoint to confirm its receipt of throughput advice. The working group will initially focus on developing a solution for QUIC. ## Non-Goals The solution produced by the working group, - must not require looking inside an encryption envelope. - need not be a congestion signal appropriate to be used as input to a congestion control algorithm. - need not provide information other than the throughput advice. ## Program of Work The WG is expected to: 1. Develop a proposed standard protocol to communicate an upper bound on achievable bitrate — termed "throughput advice"— from network elements to the endpoint. 2. Develop an Informational Applicability and Manageability specification. The WG will work collaboratively with the WEBTRANS, MOQ, AVTCORE, MOPS, QUIC, TSVWG, and CCWG WGs as appropriate. No work on APIs related to the use of the "throughput advice" will be carried out in the working group. Goals and Milestones: Nov 2025 - Submit an informational documentation of Applicability and Manageability for SCONE protocol to the IESG for publicatio Nov 2025 - Submit a standard track protocol to communicate "throughput advice"— from network elements to the endpoint to the IESG for publication Internet-Drafts: No Requests for Comments Security Dispatch (secdispatch) ------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Daniel Kahn Gillmor Rifaat Shekh-Yusef Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Paul Wouters Mailing Lists: General Discussion: secdispatch@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/secdispatch Archive: https://mailarchive.ietf.org/arch/browse/secdispatch/ Description of Working Group: The Security Dispatch working group is a DISPATCH-style WG (see [RFC7957]) chartered to consider proposals for new work in the SEC area and if the work is appropriate for the IETF and there is sufficient interest, identify, or help create, an appropriate venue for the work. In order to help the proposed new work succeed, the working group aims to assist the proposed new work in: 1. Providing a clear problem statement, motivation and deliverables. 2. Ensuring that there has been adequate mailing list discussion reflecting sufficient interest, a sufficient number of individuals have expressed a willingness to contribute, and there is WG consensus before the proposed new work can be dispatched. 3. Looking for and identifying commonalities and overlap amongst published or ongoing protocol work and the proposed new 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 existing 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. Precedence will be given to documents which have evidence of interest in the form of active drafts and list discussion. 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 SEC ADs, processing simple administrative documents. - Deferring the decision for the new work. - Rejecting the new work. The WG will attempt to come to a prompt resolution of the appropriate disposition of each proposal, either on the mailing list or or during the WG meeting where it is presented. 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 SECDISPATCH WG will not do any protocol work. Specifically, SECDISPATCH will always opt to find a location for technical work; the only work that SECDISPATCH 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 SECDISPATCH 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 SEC area is expected to be considered in the SECDISPATCH working group, there may be times where that is not appropriate. At the discretion of the area directors, new efforts may follow other paths beside SECDISPATCH. For example work may go directly to BoFs (this is appropriate in cases of major new work which would clearly need a new WG), 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: No Requests for Comments 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-16] (38 pages) - Human Readable ASPA Notation [draft-ietf-sidrops-aspa-notation-02] (6 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-19] (20 pages) - Guidance to Avoid Carrying RPKI Validation States in Transitive BGP Path Attributes [draft-ietf-sidrops-avoid-rpki-state-in-bgp-01] (14 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-02] (13 pages) - A Profile for Mapping Origin Authorizations (MOAs) [draft-ietf-sidrops-moa-profile-00] (11 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-01] (14 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-04] (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) - Tiebreaking Resource Public Key Infrastructure (RPKI) Trust Anchors [draft-ietf-sidrops-rpki-ta-tiebreaker-00] (7 pages) - RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation [draft-ietf-sidrops-rpki-tree-validation-03] (17 pages) - Revision of the RPKI Validation Algorithm [draft-ietf-sidrops-rpki-validation-update-01] (10 pages) - Detecting RRDP Session Desynchronization [draft-ietf-sidrops-rrdp-desynchronization-04] (9 pages) - Same-Origin Policy for the RPKI Repository Delta Protocol (RRDP) [draft-ietf-sidrops-rrdp-same-origin-04] (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-02] (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) - A Profile for Mapping Origin Authorizations (MOAs) [draft-xie-sidrops-moa-profile-06] (11 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) 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-02] (18 pages) No Requests for Comments Stub Network Auto Configuration for IPv6 (snac) ----------------------------------------------- Charter Last Modified: 2024-11-02 Current Status: Active Chairs: Darren Dukes Kiran Makhijani Zhe Lou 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-06] (38 pages) - Automatically Connecting Stub Networks to Unmanaged Infrastructure [draft-lemon-stub-networks-07] (21 pages) No Requests for Comments Secure Patterns for Internet CrEdentials (spice) ------------------------------------------------ Charter Last Modified: 2024-06-17 Current Status: Active Chairs: Heather Flanagan Martin Thomson Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Paul Wouters Mailing Lists: General Discussion: spice@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/spice Archive: https://mailarchive.ietf.org/arch/browse/spice/ Description of Working Group: # Introduction A digital credential expresses claims about a subject and links them with cryptographic keys. Some sets of claim names have already been defined by the IETF and other standards development groups (e.g., OpenID Foundation). Digital credentials typically involve at least three entities: issuer, holder, and verifier. An issuer constructs and secures a digital credential for a holder. Holders may be willing either to partially disclose some values of their attributes or to demonstrate some properties about their attributes without disclosing their values. Holders disclose credentials, attributes, or proofs regarding attributes in what is called a "digital presentation" to a verifier. Some holders may wish to carry more than one digital credential. These credentials, together with associated key material, can be stored in an identity digital wallet. # Goal The SPICE WG will analyze existing and emerging IETF technologies and address any remaining gaps to facilitate their application in digital credentials and presentations. - The JOSE WG is currently standardizing a token format for unlinkability and selective disclosure as specified in JWP/CWP (draft-ietf-jose-json-web-proof). The SPICE WG will profile these token formats for application in digital credentials. - The OAUTH WG is currently standardizing a token format for unlinkability and selective disclosure in the form of SD-JWT/SD-JWT-VC (draft-ietf-oauth-selective-disclosure-jwt and draft-ietf-oauth-sd-jwt-vc). The SPICE WG will define SD-CWT/SD-CWT-VC, which are analogous to these JWT-based tokens, but based on CWT. The SPICE WG will coordinate with RATS, OAuth, JOSE, COSE, and SCITT working groups that are working on documents pertinent to the identity and credential space. The SPICE WG will build upon existing cryptographic primitives and will not create new cryptographic primitives. The SPICE WG will develop digital credential profiles that support various use cases. Requirements for proposed standards in the program of work will be established in coordination with the aforementioned working groups. The profiles developed by the SPICE WG will enable digital credentials to leverage existing IETF technologies. Privacy by design, confidentiality, and consent will be considered, and implementation guidance will be given for each proposed standard in the program of work. Privacy and security considerations related to the use of confidential computing, remote attestation, trusted execution environments (TEE), and hardware security modules (HSM) on digital credentials will be developed in coordination with relevant IETF WGs (e.g., TEEP) and incorporate feedback from experts on the mailing list. Privacy and security considerations regarding redaction, linkability and selective disclosure will be developed for proposed standards in the program of work. SPICE will be inspired by the conceptual data model of the W3C VC but will not work on the Resource Description Framework (RDF) data models. # Out of Scope - General Key discovery is out of scope for this WG. There are several mechanisms for distributing or discovering key material (e.g., https://openid.net/specs/openid-connect-discovery-1_0.html). # Program of Work - An informational Architecture that defines the terminology (e.g., Issuer, Holder, Verifier, Claims, Credentials, Presentations) and the essential communication patterns between roles, such as credential issuance, where an issuer delivers a credential to a holder, and presentation, where a holder delivers a presentation to a verifier. - A Proposed Standard document defining SD-CWT, a profile of CWT inspired by SD-JWT (from OAuth) that enables digital credentials with unlinkability and selective disclosure. - A Proposed Standard Metadata & Capability Discovery protocol will be developed for JWT, CWT, SD-JWT, SD-CWT, CWP and JWP using HTTPS/CoAP. This protocol, intended for CBOR-based digital credentials will enable the three roles —issuers, holders and verifiers— to discover supported capabilities, protocols, and formats for keys, claims, credential types and proofs. The design will be inspired by the OAuth "vc-jwt-issuer" metadata work (draft-ietf-oauth-sd-jwt-vc), which supports ecosystems using JSON serialization. Goals and Milestones: Internet-Drafts: - SPICE SD-CWT [draft-ietf-spice-sd-cwt-01] (32 pages) - Use Cases for SPICE [draft-ietf-spice-use-cases-00] (6 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-03] (26 pages) - Distribute SRv6 Locator by DHCP [draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-04] (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-10] (13 pages) - Segment Protection for SR-TE Paths [draft-ietf-spring-segment-protection-sr-te-paths-07] (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-08] (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) - SRv6 and MPLS interworking [draft-ietf-spring-srv6-mpls-interworking-00] (24 pages) - Segment Routing over IPv6 (SRv6) Network Programming [draft-ietf-spring-srv6-network-programming-28] (40 pages) - Path Segment Identifier (PSID) in SRv6 (Segment Routing in IPv6) [draft-ietf-spring-srv6-path-segment-11] (14 pages) - Segment Routing IPv6 Security Considerations [draft-ietf-spring-srv6-security-01] (21 pages) - Compressed SRv6 Segment List Encoding [draft-ietf-spring-srv6-srh-compression-19] (77 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-17] (53 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) 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 Secure Shell Maintenance (sshm) ------------------------------- Charter Last Modified: 2024-09-27 Current Status: Active Chairs: Job Snijders Stephen Farrell Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Deb Cooley Mailing Lists: General Discussion: ssh@ietf.org To Subscribe: https://mailman3.ietf.org/mailman3/lists/ssh.ietf.org/ Archive: https://mailarchive.ietf.org/arch/browse/ssh/ Description of Working Group: The main goal of the working group is to maintain the Secure Shell (SSH) protocol. SSH provides support for secure remote login, file transfer, and forwarding UNIX-domain sockets, TCP/IP and X11. It can automatically encrypt, authenticate, and compress transmitted data. The SSHM working group facilitates discussion of clarifications, improvements, and extensions to the SSH protocol. The initial goals of this working group are: * to update the RFCs documenting SSH to reflect what is implemented and deployed in practice. In particular, the working group will document the OpenSSH certificate structure, the SSH agent protocol, and SFTP, as they are currently implemented. * to update and maintain the list of cryptographic algorithms used by SSH. This includes documenting currently deployed algorithms, deprecating unsafe algorithms, selecting new algorithms, and determining the set of recommended and mandatory-to-implement algorithms. Updating IANA SSH registries and changing their registration policies is in scope. While the development of formal verification proofs is out of scope, this working group can respond to emerging proofs, and to security issues found by formal verification tools. This can be done for example by defining new extensions to improve the security of SSH. This working group will strive for strong security, simplicity, and ease of implementation. In particular, proposals will only be adopted if there is evidence of significant existing deployment or broad interest in new implementation and deployment. Protocol documents should not be submitted to the IESG for publication before they have at least two demonstrably interoperable implementations. Out of scope includes: * defining new certificate types or trust mechanisms; * defining new transports for SSH; * designing cryptographic algorithms (but defining how SSH uses cryptographic algorithms is in scope). Goals and Milestones: Dec 2024 - Issue call for adoption for chacha20-poly1305 draft Dec 2024 - Issue call for adoption for sntrup761-x25519 draft Jan 2025 - Issue calls for drafts documenting existing and widely used SSH protocol features Mar 2025 - Issue call for adoption for SSH Agent Protocol draft Jul 2025 - Issue call for adoption for rfc9519bis draft Internet-Drafts: - Secure Shell (SSH) Key Exchange Method Using Hybrid Streamlined NTRU Prime sntrup761 and X25519 with SHA-512: sntrup761x25519-sha512 [draft-ietf-sshm-ntruprime-ssh-00] (10 pages) - SSH Agent Protocol [draft-ietf-sshm-ssh-agent-00] (25 pages) - Secure Shell (SSH) Key Exchange Method Using Hybrid Streamlined NTRU Prime sntrup761 and X25519 with SHA-512: sntrup761x25519-sha512 [draft-josefsson-ntruprime-ssh-03] (10 pages) - SSH Agent Protocol [draft-miller-ssh-agent-17] (24 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-02] (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-06] (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) Software Updates for Internet of Things (suit) ---------------------------------------------- Charter Last Modified: 2024-07-21 Current Status: Active Chairs: Akira Tsukamoto David Waltermire Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Deb Cooley Mailing Lists: General Discussion: suit@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/suit Archive: https://mailarchive.ietf.org/arch/browse/suit Description of Working Group: Vulnerabilities in Internet of Things (IoT) devices have raised the need for a secure firmware update mechanism that is also suitable for constrained devices. Security experts, researchers, and regulators recommend that all IoT devices be equipped with such a mechanism. While there are many proprietary firmware update mechanisms in use today, there is no modern interoperable approach allowing secure updates to firmware in IoT devices. In June 2016, the Internet Architecture Board organized a workshop on 'Internet of Things (IoT) Software Update (IOTSU)', and RFC 8240 documents various requirements and challenges that are specific to IoT devices. A firmware update solution consists of several components, including: * A mechanism to transport firmware images to compatible devices. * A manifest that provides meta-data about the firmware image (such as a firmware package identifier, the hardware the package needs to run, and dependencies on other firmware packages), as well as cryptographic information for protecting the firmware image in an end-to-end fashion. * The firmware image itself. The SUIT WG is defining a firmware update solution (taking into account past learning from RFC 4108 and other proprietary firmware update solutions) that are usable on Class 1 (as defined in RFC 7228) devices, i.e., devices with ~10 KiB RAM and ~100 KiB flash. The solution may apply to more capable devices as well. The SUIT WG is not defining any new transport or discovery mechanisms, but may describe how to use existing mechanisms within the architecture. The SUIT WG has already completed work on two documents: * An IoT firmware update architecture. * An information model for the SUIT manifest. Now that the information model is complete, the SUIT WG has selected the CBOR serialization format and the associated COSE cryptographic mechanisms to encode the SUIT manifest. The SUIT WG may consider a small number of additional formats in the future; however, to reduce the complexity of a firmware management solution, a very small number of formats is preferred to enable SUIT maifest integration and interoperability with other IoT technologies and ecosystems. To support a wide range of deployment scenarios, the formats are expected to be expressive enough to allow the use of different firmware sources and permission models. To enable SUIT Status Tracker functionality (per RFC9019), the SUIT WG is also defining extensions to determine if a particular manifest could be successfully deployed to a device and determine if an operation was successful. In addition, the SUIT WG will work with the RATS WG to specify claims related to the SUIT Status Tracker that can be used to provide evidence in support of the RATS architecture. The SUIT WG will continue to work with silicon vendors and OEMs that develop IoT operating systems to produce implementations based on SUIT WG specifications. In particular, the SUIT WG plans to continue to participate in IETF Hackathons. The SUIT WG document deliverables are: * A SUIT manifest format specification using CBOR. * Extensions to the SUIT manifest for optional capabilities, including: - firmware encryption, - trust domains, - update management, and - inclusion of a file in the MUD format (RFC 8520). * A secure method for an IoT device to report on firmware update status. In addition, either the SUIT WG or the RATS WG will produce: * A set of claims for attesting to firmware update status. Goals and Milestones: Aug 2022 - Submit firmware encryption document to the IESG for publication as a Proposed Standard Sep 2022 - Submit SUIT Status Tracker document to the IESG for publication as a Proposed Standard Nov 2022 - Submit SUIT Manifest update management document to the IESG for publication as a Proposed Standard Nov 2022 - Submit SUIT Manifest trust domains document to the IESG for publication as a Proposed Standard Dec 2022 - Submit SUIT Manifest MUD extension document to the IESG for publication as a Proposed Standard Done - Adopt SUIT Manifest MUD extension document as WG item Done - Adopt SUIT Manifest trust domains document as WG item Done - Adopt SUIT Manifest update management document as WG item Done - Decide with RATS WG in which working group the 'set of claims for attesting to firmware update status' document should be produced Internet-Drafts: - A Firmware Update Architecture for Internet of Things [draft-ietf-suit-architecture-16] (24 pages) - Encrypted Payloads in SUIT Manifests [draft-ietf-suit-firmware-encryption-21] (57 pages) - A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices [draft-ietf-suit-information-model-13] (40 pages) - A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest [draft-ietf-suit-manifest-29] (102 pages) - Mandatory-to-Implement Algorithms for Authors and Recipients of Software Update for the Internet of Things manifests [draft-ietf-suit-mti-08] (12 pages) - Strong Assertions of IoT Network Access Requirements [draft-ietf-suit-mud-09] (11 pages) - Secure Reporting of Update Status [draft-ietf-suit-report-10] (21 pages) - SUIT Manifest Extensions for Multiple Trust Domains [draft-ietf-suit-trust-domains-08] (36 pages) - Update Management Extensions for Software Updates for Internet of Things (SUIT) Manifests [draft-ietf-suit-update-management-07] (24 pages) - A Firmware Update Architecture for Internet of Things Devices [draft-moran-suit-architecture-03] (30 pages) - Mandatory-to-Implement Algorithms for Creators and Consumers of Software Update for the Internet of Things manifests [draft-moran-suit-mti-02] (6 pages) - Secure Reporting of Update Status [draft-moran-suit-report-01] (7 pages) - Firmware Encryption with SUIT Manifests [draft-tschofenig-suit-firmware-encryption-01] (16 pages) Requests for Comments: RFC9019: A Firmware Update Architecture for Internet of Things (24 pages) RFC9124: A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices (40 pages) Transport Services (taps) ------------------------- Charter Last Modified: 2024-01-17 Current Status: Active Chairs: Aaron Falk Reese Enghardt Web and Internet Transport Directors: Francesca Palombini Zaheduzzaman Sarker Web and Internet Transport Advisor: Zaheduzzaman Sarker Mailing Lists: General Discussion: taps@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/taps Archive: https://mailarchive.ietf.org/arch/browse/taps/ Description of Working Group: Most Internet applications make use of the Transport Services provided by TCP (a reliable, in-order stream protocol) or UDP (an unreliable datagram protocol). We use the term "Transport Service" to mean an end-to-end facility provided by the transport layer. That service can only be provided correctly if information is supplied from the application. The application may determine the information to be supplied at design time, compile time, or run time and may include guidance on whether the facility in question is required or simply a preference by the application. Four examples of Transport Services are reliable delivery, ordered delivery of data, content privacy to in-path devices, and minimal latency. Transport protocols such as SCTP, DCCP, WebSockets, MPTCP, and UDP-Lite and the LEDBAT congestion control mechanism extend the set of available Transport Services beyond those provided to applications by TCP and UDP. For example, SCTP provides potentially faster reliable delivery for applications than TCP because it can accept blocks of data out of order, and LEDBAT provides low-priority "scavenger" communication. However, application programmers face difficulty when they use protocols other than TCP or UDP. Most network stacks ship with only TCP and UDP as transport protocols. Many firewalls only pass TCP and UDP and some only allow TCP when it carries HTTP as its payload. As a result, using other transport protocols or building a new protocol over raw sockets risks having an application not work in many environments. Applications, therefore, must always be able to fall back to TCP or UDP, or even to using HTTP as a transport substrate in some cases, and once the application programmer has committed to making an application work on TCP or UDP or HTTP, there is little incentive to try other transport protocols before falling back. Further, different protocols can provide the same services in different ways. Layering decisions must also be made (for example, whether a protocol is used natively or tunneled through UDP). Because of these complications, programmers often resort to either using TCP or HTTP or implementing their own customized "transport services" over UDP. When application developers re-implement transport features already available elsewhere they open the door to problems that simply using TCP would have avoided and ensure that the applications can't benefit from other transport protocols as they become available. And, since even TCP and UDP are not guaranteed to work in all environments today, some programmers simply give up on using TCP or UDP directly, relying instead on "HTTP as a Substrate". BCP 56 identified many issues with this strategy, but assuming that if "any protocol is available on a given network path and on the hosts that will be communicating, that protocol will be HTTP" is a reasonable strategy for today's Internet. The IESG has agreed with this viewpoint enough to publish the WebSocket protocol on the standards track. The goal of the TAPS working group is to help application and network stack programmers by describing an (abstract) interface for applications to make use of Transport Services. The Working Group deliverables emphasize defining Transport Services that are important to applications followed by experimental mechanisms to a) determine if the protocols to provide the requested services are available on the end points and supported along the path in the network and b) fall back, i.e., select alternate, possibly less-preferred, protocols when desired protocols are not available. The Working Group will not define a richer set of Transport Services for applications, although the TAPS deliverables could inform proposals for future chartered work on Transport Services. The Working Group will: 1) Define a set of Transport Services, identifying the services provided by existing IETF protocols and congestion control mechanisms. As a starting point, the working group will consider services used between two endpoints. 2) Analyze, compare, and contrast properties and dependencies of selected IETF transport security protocols and other relevant security protocols as agreed upon by working group participants. Define a set of security-related Transport Services provided by such protocols. Engage with the Security area to solicit feedback and reviews on all relevant documents. 3) Specify the subset of Transport Services, as identified in items 1 and 2, that end systems supporting TAPS will provide, and give guidance on choosing among available mechanisms and protocols. Note that not all the capabilities of IETF Transport protocols need to be exposed as Transport Services. 4) Specify experimental support mechanisms to provide the Transport Services identified in work item 3. This document will explain how to select and engage an appropriate protocol and how to discover which protocols are available for the selected service between a given pair of end points. Further, it will provide a basis for incremental deployment. Work on this document will begin when the TAPS Transport Services have been specified. The following topics are out of scope for this Working Group: - Signaling-based Quality-of-Service (QoS) mechanisms - Definition of new encapsulations and tunneling mechanisms - Extension, modification, and creation of transport or security protocols - Language-specific APIs Goals and Milestones: Sep 2021 - Submit document(s) to be published as Proposed Standard to the IESG specifying one or more methods to provide applications with the Transport Services identified by the WG Sep 2021 - Recharter or conclude. Done - Submit an Informational document to the IESG recommending a minimal set of Transport Services that end systems should support Done - Submit an Informational document defining a set of security-related Transport Services Internet-Drafts: - Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- Lite) Transport Protocols [draft-fairhurst-taps-transports-usage-udp-03] (18 pages) - A Minimal Set of Transport Services for TAPS Systems [draft-gjessing-taps-minset-05] (44 pages) - Architecture and Requirements for Transport Services [draft-ietf-taps-arch-19] (35 pages) - Implementing Interfaces to Transport Services [draft-ietf-taps-impl-18] (55 pages) - An Abstract Application Layer Interface to Transport Services [draft-ietf-taps-interface-26] (98 pages) - A Minimal Set of Transport Services for End Systems [draft-ietf-taps-minset-11] (44 pages) - Services Provided by IETF Transport Protocols and Congestion Control Mechanisms [draft-ietf-taps-transports-14] (54 pages) - A Survey of the Interaction between Security Protocols and Transport Services [draft-ietf-taps-transport-security-12] (19 pages) - On the Usage of Transport Features Provided by IETF Transport Protocols [draft-ietf-taps-transports-usage-09] (56 pages) - Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite) [draft-ietf-taps-transports-usage-udp-07] (20 pages) Requests for Comments: RFC8095: Services Provided by IETF Transport Protocols and Congestion Control Mechanisms (54 pages) RFC8303: On the Usage of Transport Features Provided by IETF Transport Protocols (56 pages) RFC8304: Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite) (20 pages) RFC8922: A Survey of the Interaction between Security Protocols and Transport Services (19 pages) RFC8923: A Minimal Set of Transport Services for End Systems (44 pages) TCP Maintenance and Minor Extensions (tcpm) ------------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Ian Swett Michael Tüxen Yoshifumi Nishida Web and Internet Transport Directors: Francesca Palombini Zaheduzzaman Sarker Web and Internet Transport Advisor: Zaheduzzaman Sarker Mailing Lists: General Discussion: tcpm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tcpm Archive: https://mailarchive.ietf.org/arch/browse/tcpm/ Description of Working Group: TCP is currently one of the Internet's predominant transport protocols. TCPM is the working group within the IETF that handles small TCP changes, i.e., minor extensions to TCP algorithms and protocol mechanisms. The TCPM WG serves several purposes: * The WG mostly focuses on maintenance issues (e.g., bug fixes) and modest changes to the protocol, algorithms, and interfaces that maintain TCP's utility. * The WG is a venue for moving current TCP specifications along the standards track. * The WG maintains Multipath TCP (MPTCP) and is a home for minor MPTCP enhancements including updates to the existing multipath congestion control. The preferred venue for Congestion control work is generally CCWG or ICCRG. However, TCPM can take on such work in coordination with those groups, especially if it relies on TCP-specific protocol elements. New TCPM milestones that fall within the scope specified within the charter can be added after consensus on acceptance in the working group and approval by the responsible Area Director. Goals and Milestones: Sep 2024 - Submit specification of more accurate ECN feedback in TCP to the IESG for publication as a Proposed Standard RFC Oct 2024 - Submit RFC6937bis document to the IESG for publication as a Proposed Standard RFC Dec 2024 - Submit document on adding Explicit Congestion Notification (ECN) to TCP Control Packets to the IESG for publication as Experimental RFC Apr 2025 - Submit document on a TCP Extended Data Offset Option to the IESG as a Proposed Standard RFC Apr 2025 - Submit document on handling ghost ACKS to the IESG as a Proposed Standard RFC Aug 2025 - Submit document on adding acknowledgement rate handling for TCP to the IESG for publication as Experimental RFC Internet-Drafts: - Moving the Undeployed TCP Extensions RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693 to Historic Status [draft-eggert-tcpm-historicize-02] (4 pages) - TCP Extensions for High Performance [draft-ietf-tcpm-1323bis-21] (49 pages) - TCP Control Block Interdependence [draft-ietf-tcpm-2140bis-11] (29 pages) - A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP [draft-ietf-tcpm-3517bis-02] (15 pages) - Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback [draft-ietf-tcpm-accecn-reqs-08] (17 pages) - More Accurate Explicit Congestion Notification (ECN) Feedback in TCP [draft-ietf-tcpm-accurate-ecn-30] (72 pages) - TCP ACK Rate Request Option [draft-ietf-tcpm-ack-rate-request-06] (19 pages) - TCP Alternative Backoff with ECN (ABE) [draft-ietf-tcpm-alternativebackoff-ecn-12] (12 pages) - Support for Stronger Error Detection Codes in TCP for Jumbo Frames [draft-ietf-tcpm-anumita-tcp-stronger-checksum-00] (10 pages) - TCP Authentication Option (TCP-AO) Test Vectors [draft-ietf-tcpm-ao-test-vectors-09] (25 pages) - 0-RTT TCP Convert Protocol [draft-ietf-tcpm-converters-19] (47 pages) - CUBIC for Fast Long-Distance Networks [draft-ietf-tcpm-cubic-07] (18 pages) - Data Center TCP (DCTCP): TCP Congestion Control for Data Centers [draft-ietf-tcpm-dctcp-10] (17 pages) - Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP) [draft-ietf-tcpm-early-rexmt-04] (15 pages) - Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets [draft-ietf-tcpm-ecnsyn-10] (33 pages) - Shared Use of Experimental TCP Options [draft-ietf-tcpm-experimental-options-06] (11 pages) - TCP Fast Open [draft-ietf-tcpm-fastopen-10] (26 pages) - Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP) [draft-ietf-tcpm-frto-02] (23 pages) - ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets [draft-ietf-tcpm-generalized-ecn-16] (51 pages) - HyStart++: Modified Slow Start for TCP [draft-ietf-tcpm-hystartplusplus-14] (9 pages) - ICMP Attacks against TCP [draft-ietf-tcpm-icmp-attacks-12] (36 pages) - Increasing TCP's Initial Window [draft-ietf-tcpm-initcwnd-08] (24 pages) - Updating TCP to Support Rate-Limited Traffic [draft-ietf-tcpm-newcwv-13] (21 pages) - TCP Sender Clarification for Persist Condition [draft-ietf-tcpm-persist-07] (7 pages) - Proportional Rate Reduction for TCP [draft-ietf-tcpm-proportional-rate-reduction-04] (16 pages) - Proportional Rate Reduction for TCP [draft-ietf-tcpm-prr-rfc6937bis-13] (21 pages) - The RACK-TLP Loss Detection Algorithm for TCP [draft-ietf-tcpm-rack-15] (29 pages) - Defending against Sequence Number Attacks [draft-ietf-tcpm-rfc1948bis-02] (12 pages) - TCP Congestion Control [draft-ietf-tcpm-rfc2581bis-07] (18 pages) - The NewReno Modification to TCP's Fast Recovery Algorithm [draft-ietf-tcpm-rfc3782-bis-05] (16 pages) - Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP [draft-ietf-tcpm-rfc4138bis-04] (19 pages) - Transmission Control Protocol (TCP) [draft-ietf-tcpm-rfc793bis-28] (98 pages) - CUBIC for Fast and Long-Distance Networks [draft-ietf-tcpm-rfc8312bis-15] (28 pages) - Requirements for Time-Based Loss Detection [draft-ietf-tcpm-rto-consider-17] (12 pages) - TCP and Stream Control Transmission Protocol (SCTP) RTO Restart [draft-ietf-tcpm-rtorestart-10] (15 pages) - Using TCP Selective Acknowledgement (SACK) Information to Determine Duplicate Acknowledgements for Loss Recovery Initiation [draft-ietf-tcpm-sack-recovery-entry-01] (18 pages) - TCP SYN Flooding Attacks and Common Mitigations [draft-ietf-tcpm-syn-flood-05] (19 pages) - Defending TCP Against Spoofing Attacks [draft-ietf-tcpm-tcp-antispoof-06] (28 pages) - Cryptographic Algorithms for the TCP Authentication Option (TCP-AO) [draft-ietf-tcpm-tcp-ao-crypto-03] (15 pages) - The TCP Authentication Option [draft-ietf-tcpm-tcp-auth-opt-11] (48 pages) - Improving the Robustness of TCP to Non-Congestion Events [draft-ietf-tcpm-tcp-dcr-07] (18 pages) - TCP Extended Data Offset Option [draft-ietf-tcpm-tcp-edo-14] (23 pages) - Improve TCP Handling of Out-of-Window Packets to Mitigate Ghost ACKs [draft-ietf-tcpm-tcp-ghost-acks-01] (6 pages) - Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD) [draft-ietf-tcpm-tcp-lcd-03] (23 pages) - TCP Options and Maximum Segment Size (MSS) [draft-ietf-tcpm-tcpmss-05] (9 pages) - A Roadmap for Transmission Control Protocol (TCP) Specification Documents [draft-ietf-tcpm-tcp-rfc4614bis-08] (57 pages) - A Roadmap for Transmission Control Protocol (TCP) Specification Documents [draft-ietf-tcpm-tcp-roadmap-06] (33 pages) - Improving TCP's Robustness to Blind In-Window Attacks [draft-ietf-tcpm-tcpsecure-13] (19 pages) - Survey of Security Hardening Methods for Transmission Control Protocol (TCP) Implementations [draft-ietf-tcpm-tcp-security-03] (86 pages) - TCP's Reaction to Soft Errors [draft-ietf-tcpm-tcp-soft-errors-09] (13 pages) - Reducing the TIME-WAIT State Using TCP Timestamps [draft-ietf-tcpm-tcp-timestamps-04] (10 pages) - TCP User Timeout Option [draft-ietf-tcpm-tcp-uto-11] (14 pages) - Moving Outdated TCP Extensions and TCP-Related Documents to Historic or Informational Status [draft-ietf-tcpm-undeployed-03] (8 pages) - On the Implementation of the TCP Urgent Mechanism [draft-ietf-tcpm-urgent-data-07] (12 pages) - A YANG Model for Transmission Control Protocol (TCP) Configuration and State [draft-ietf-tcpm-yang-tcp-09] (29 pages) - Cryptographic Algorithms, Use, & Implementation Requirments for TCP Authentication Option [draft-lebovitz-ietf-tcpm-tcp-ao-crypto-02] (16 pages) - Computing TCP's Retransmission Timer [draft-paxson-tcpm-rfc2988bis-02] (11 pages) Requests for Comments: RFC4138: Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP) (23 pages) * Updates RFC5682 RFC4614: A Roadmap for Transmission Control Protocol (TCP) Specification Documents (33 pages) * Updates RFC6247 * Obsoletes RFC7414 RFC4653: Improving the Robustness of TCP to Non-Congestion Events (18 pages) RFC4953: Defending TCP Against Spoofing Attacks (28 pages) RFC4987: TCP SYN Flooding Attacks and Common Mitigations (19 pages) RFC5461: TCP's Reaction to Soft Errors (13 pages) RFC5482: TCP User Timeout Option (14 pages) RFC5562: Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets (33 pages) RFC5681: TCP Congestion Control (18 pages) * Updates RFC9438 RFC5682: Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP (19 pages) RFC5827: Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP) (15 pages) RFC5925: The TCP Authentication Option (48 pages) RFC5926: Cryptographic Algorithms for the TCP Authentication Option (TCP-AO) (15 pages) RFC5927: ICMP Attacks against TCP (36 pages) RFC5961: Improving TCP's Robustness to Blind In-Window Attacks (19 pages) * Updates RFC9293 RFC6069: Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD) (23 pages) RFC6093: On the Implementation of the TCP Urgent Mechanism (12 pages) * Obsoletes RFC9293 RFC6191: Reducing the TIME-WAIT State Using TCP Timestamps (10 pages) RFC6247: Moving the Undeployed TCP Extensions RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693 to Historic Status (4 pages) RFC6298: Computing TCP's Retransmission Timer (11 pages) RFC6429: TCP Sender Clarification for Persist Condition (7 pages) * Obsoletes RFC9293 RFC6528: Defending against Sequence Number Attacks (12 pages) * Obsoletes RFC9293 RFC6582: The NewReno Modification to TCP's Fast Recovery Algorithm (16 pages) RFC6675: A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP (15 pages) RFC6691: TCP Options and Maximum Segment Size (MSS) (9 pages) * Obsoletes RFC9293 RFC6928: Increasing TCP's Initial Window (24 pages) RFC6937: Proportional Rate Reduction for TCP (16 pages) RFC6994: Shared Use of Experimental TCP Options (11 pages) RFC7323: TCP Extensions for High Performance (49 pages) RFC7413: TCP Fast Open (26 pages) RFC7414: A Roadmap for Transmission Control Protocol (TCP) Specification Documents (57 pages) * Updates RFC7805 RFC7560: Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback (17 pages) RFC7661: Updating TCP to Support Rate-Limited Traffic (21 pages) RFC7765: TCP and Stream Control Transmission Protocol (SCTP) RTO Restart (15 pages) RFC7805: Moving Outdated TCP Extensions and TCP-Related Documents to Historic or Informational Status (8 pages) RFC8257: Data Center TCP (DCTCP): TCP Congestion Control for Data Centers (17 pages) RFC8312: CUBIC for Fast Long-Distance Networks (18 pages) * Obsoletes RFC9438 RFC8511: TCP Alternative Backoff with ECN (ABE) (12 pages) RFC8803: 0-RTT TCP Convert Protocol (47 pages) RFC8961: Requirements for Time-Based Loss Detection (12 pages) RFC8985: The RACK-TLP Loss Detection Algorithm for TCP (29 pages) RFC9040: TCP Control Block Interdependence (29 pages) RFC9235: TCP Authentication Option (TCP-AO) Test Vectors (25 pages) RFC9293: Transmission Control Protocol (TCP) (98 pages) RFC9406: HyStart++: Modified Slow Start for TCP (9 pages) RFC9438: CUBIC for Fast and Long-Distance Networks (28 pages) RFC9648: YANG Data Model for TCP (25 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-13] (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-14] (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-06] (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-03] (12 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-14] (154 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-16] (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-02] (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-37] (99 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-01] (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) - YANG Data Model for Topology Filter [draft-ietf-teas-yang-topology-filter-00] (17 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) Trusted Execution Environment Provisioning (teep) ------------------------------------------------- Charter Last Modified: 2022-05-06 Current Status: Active Chairs: Nancy Cam-Winget Tirumaleswar Reddy.K Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Paul Wouters Mailing Lists: General Discussion: teep@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/teep Archive: https://mailarchive.ietf.org/arch/browse/teep/ Description of Working Group: The Trusted Execution Environment (TEE) is a secure area of a processor. The TEE provides security features such as isolated execution and integrity of Trusted Applications, along with provisions for maintaining the confidentiality of their assets. In general terms, the TEE offers an execution space that provides a higher level of security than a "rich" operating system and more functionality than a secure element. For example, implementations of the TEE concept have been developed by ARM and Intel, using the TrustZone and the SGX technology, respectively. To programmatically install, update, and delete applications in a TEE, the Trusted Execution Environment Provisioning protocol runs between a service within the TEE on a given device, a relay application or service access point on the device's network stack and a server-side infrastructure that interacts with and optionally maintains the applications. Some tasks are security sensitive and the server side requires information about the device characteristics in the form of attestation and the device-side may require information about the server. Privacy considerations have to be taken into account with authentication features and attestation. This working group aims to develop an a protocol providing TEEs with lifecycle management and security domain management for trusted applications. A security domain allows a service provider's applications to be isolated so that one security domain cannot be influenced by another domain, unless the domain exposes an API to allow inter-domain interactions. The solution approach must take a wide range of TEE and relevant technologies into account and will focus on the use of public key cryptography. The group will produce the following deliverables. The first document is on architecture, describing the involved entities, their relationships, assumptions, the keying framework, and relevant use cases. Second, a solution document that includes the above-described functionality in a protocol will be developed. The choice of encoding format(s) will be decided in the working group. The group may document several attestation technologies considering the different hardware capabilities, performance, privacy, and operational properties. The group will maintain a close relationship with the IETF SUIT working group, GlobalPlatform, Trusted Computing Group, and other relevant standards groups to ensure interoperability, compatibility, and proper use of existing TEE-relevant application layer interfaces. Goals and Milestones: Sep 2020 - Progress Architecture document to the IESG for publication Sep 2020 - Progress HTTP transport for TEEP document to the IESG for publication Nov 2020 - Begin WGLC for Solution document Mar 2021 - Progress Solution document to the IESG for publication Done - Adopt an Architecture document Done - Adopt a solution document Done - Begin WGLC for Architecture document Internet-Drafts: - Trusted Execution Environment Provisioning (TEEP) Architecture [draft-ietf-teep-architecture-19] (31 pages) - The Open Trust Protocol (OTrP) [draft-ietf-teep-opentrustprotocol-03] (111 pages) - HTTP Transport for Trusted Execution Environment Provisioning: Agent Initiated Communication [draft-ietf-teep-otrp-over-http-15] (14 pages) - Trusted Execution Environment Provisioning (TEEP) Protocol [draft-ietf-teep-protocol-20] (73 pages) - TEEP Usecase for Confidential Computing in Network [draft-ietf-teep-usecase-for-cc-in-network-07] (13 pages) - Trusted Execution Environment Provisioning Protocol (teep-p) [draft-tschofenig-teep-protocol-01] (20 pages) - TEEP Usecase for Confidential Computing in Network [draft-yang-teep-usecase-for-cc-in-network-01] (12 pages) Requests for Comments: RFC9397: Trusted Execution Environment Provisioning (TEEP) Architecture (31 pages) 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) Transport Layer Security (tls) ------------------------------ Charter Last Modified: 2023-11-17 Current Status: Active Chairs: Deirdre Connolly Joseph A. Salowey Sean Turner Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Paul Wouters Mailing Lists: General Discussion: tls@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tls Archive: https://mailarchive.ietf.org/arch/browse/tls/ Description of Working Group: The TLS (Transport Layer Security) working group was established in 1996 to standardize a 'transport layer' security protocol. The basis for the work was SSL (Secure Socket Layer) v3.0 [RFC6101]. The TLS working group has completed a series of specifications that describe the TLS protocol v1.0 [RFC2246], v1.1 [RFC4346], v1.2 [RFC5246], and v1.3 [RFC8446], and DTLS (Datagram TLS) v1.0 [RFC4347], v1.2 [RFC6347], and v1.3 [draft-ietf-tls-dtls13], as well as extensions to the protocols and ciphersuites. The working group aims to achieve three goals. First, improve the applicability and suitability of the TLS family of protocols for use in emerging protocols and use cases. This includes extensions or changes that help protocols better use TLS as an authenticated key exchange protocol, or extensions that help protocols better leverage TLS security properties, such as Exported Authenticators. Extensions that focus specifically on protocol extensibility are also in scope. This goal also includes protocol changes that reduce TLS resource consumption without affecting security. Extensions that help reduce TLS handshake size meet this criterion. The second working group goal is to improve security, privacy, and deployability. This includes, for example, Delegated Credentials and Encrypted SNI. Security and privacy goals will place emphasis on the following: - Encrypt the ClientHello SNI (Server Name Indication) and other application-sensitive extensions, such as ALPN (Application-Layer Protocol Negotiation). - Identify and mitigate other (long-term) user tracking or fingerprinting vectors enabled by TLS deployments and implementations. The third goal is to maintain current and previous version of the (D)TLS protocol as well as to specify general best practices for use of (D)TLS, extensions to (D)TLS, and cipher suites. This includes recommendations as to when a particular version should be deprecated. Changes or additions to older versions of (D)TLS whether via extensions or ciphersuites are discouraged and require significant justification to be taken on as work items. The working group will also place a priority in minimizing gratuitous changes to (D)TLS. Goals and Milestones: Nov 2020 - Submit "A Flags Extension for TLS 1.3" to the IESG Mar 2021 - Submit "Encrypted Server Name Indication for TLS 1.3" to the IESG Jul 2021 - Submit "Compact TLS 1.3" to the IESG Jul 2021 - Submit "Semi-Static Diffie-Hellman Key Establishment for TLS 1.3" to the IESG Nov 2021 - Submit "Hybrid key exchange in TLS 1.3" to the IESG Done - Submit "Deprecating MD5 and SHA-1 signature hashes in TLS 1.2" to the IESG Done - Submit "Delegated Credentials for TLS" to the IESG Done - Submit "TLS Ticket Requests" to the IESG Done - Submit "Importing External PSKs for TLS" to the IESG Internet-Drafts: - Deprecating Obsolete Key Exchange Methods in TLS [draft-aviram-tls-deprecate-obsolete-kex-01] (20 pages) - Deprecating FFDH(E) Ciphersuites in TLS [draft-bartle-tls-deprecate-ffdhe-00] (9 pages) - Transport Layer Security (TLS) False Start [draft-bmoeller-tls-falsestart-01] (11 pages) - Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3 [draft-davidben-tls13-pkcs1-01] (7 pages) - Batch Signing for TLS [draft-davidben-tls-batch-signing-02] (10 pages) - Applying GREASE to TLS Extensibility [draft-davidben-tls-grease-01] (8 pages) - TLS Key Share Prediction [draft-davidben-tls-key-share-prediction-01] (7 pages) - TLS Trust Expressions [draft-davidben-tls-trust-expr-04] (36 pages) - Guidance for External PSK Usage in TLS [draft-dt-tls-external-psk-guidance-01] (12 pages) - A well-known URI for publishing ECHConfigList values. [draft-farrell-tls-wkesni-03] (7 pages) - Transport Layer Security (TLS) Certificate Compression [draft-ghedini-tls-certificate-compression-00] (6 pages) - TLS 1.2 Update for Long-term Support [draft-gutmann-tls-lts-14] (21 pages) - TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key [draft-housley-tls-tls13-cert-with-extern-psk-03] (10 pages) - SNI Encryption in TLS Through Tunneling [draft-huitema-tls-sni-encryption-02] (22 pages) - 56-bit Export Cipher Suites For TLS [draft-ietf-tls-56-bit-ciphersuites-01] (3 pages) - TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key [draft-ietf-tls-8773bis-02] (15 pages) - An Internet AttributeCertificate Profile for Authorization [draft-ietf-tls-ac509prof-00] (11 pages) - Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension [draft-ietf-tls-applayerprotoneg-05] (9 pages) - TLS extensions for AttributeCertificate based authorization [draft-ietf-tls-attr-cert-01] (11 pages) - Batch Signing for TLS [draft-ietf-tls-batch-signing-00] (10 pages) - Transport Layer Security (TLS) Cached Information Extension [draft-ietf-tls-cached-info-23] (19 pages) - Addition of Camellia Cipher Suites to Transport Layer Security (TLS) [draft-ietf-tls-camellia-06] (7 pages) - Abridged Compression for WebPKI Certificates [draft-ietf-tls-cert-abridge-02] (21 pages) - TLS Certificate Compression [draft-ietf-tls-certificate-compression-10] (8 pages) - ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS) [draft-ietf-tls-chacha20-poly1305-04] (8 pages) - Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) [draft-ietf-tls-ciphersuite-06] (7 pages) - Transport Layer Security Protocol Compression Methods [draft-ietf-tls-compression-07] (8 pages) - Transport Layer Security (TLS) Resumption across Server Names [draft-ietf-tls-cross-sni-resumption-02] (6 pages) - Compact TLS 1.3 [draft-ietf-tls-ctls-10] (26 pages) - AES Counter Mode Cipher Suites for TLS and DTLS [draft-ietf-tls-ctr-01] (10 pages) - Curve25519 and Curve448 for Transport Layer Security (TLS) [draft-ietf-tls-curve25519-01] (11 pages) - TLS Delegation Protocol [draft-ietf-tls-delegation-01] (10 pages) - Deprecating Obsolete Key Exchange Methods in TLS 1.2 [draft-ietf-tls-deprecate-obsolete-kex-05] (21 pages) - DES and IDEA Cipher Suites for Transport Layer Security (TLS) [draft-ietf-tls-des-idea-02] (4 pages) - A DANE Record and DNSSEC Authentication Chain Extension for TLS [draft-ietf-tls-dnssec-chain-extension-07] (24 pages) - TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks [draft-ietf-tls-downgrade-scsv-05] (8 pages) - The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 [draft-ietf-tls-dtls13-43] (61 pages) - Connection Identifier for DTLS 1.2 [draft-ietf-tls-dtls-connection-id-13] (14 pages) - Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension [draft-ietf-tls-dtls-heartbeat-04] (9 pages) - Return Routability Check for DTLS 1.2 and DTLS 1.3 [draft-ietf-tls-dtls-rrc-12] (23 pages) - Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) [draft-ietf-tls-ecc-12] (35 pages) - TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM) [draft-ietf-tls-ecc-new-mac-07] (6 pages) - ECDHE_PSK Cipher Suites for Transport Layer Security (TLS) [draft-ietf-tls-ecdhe-psk-05] (7 pages) - ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2 [draft-ietf-tls-ecdhe-psk-aead-05] (7 pages) - SSLKEYLOGFILE Extension for Encrypted Client Hello (ECH) [draft-ietf-tls-ech-keylogfile-01] (8 pages) - Update to Transport Layer Security (TLS) Extensions [draft-ietf-tls-emailaddr-00] (4 pages) - Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [draft-ietf-tls-encrypt-then-mac-03] (7 pages) - TLS Encrypted Client Hello [draft-ietf-tls-esni-22] (52 pages) - Exported Authenticators in TLS [draft-ietf-tls-exported-authenticator-15] (14 pages) - Extended Key Update for Transport Layer Security (TLS) 1.3 [draft-ietf-tls-extended-key-update-03] (16 pages) - Transport Layer Security (TLS) Extensions [draft-ietf-tls-extensions-06] (29 pages) - Guidance for External Pre-Shared Key (PSK) Usage in TLS [draft-ietf-tls-external-psk-guidance-06] (13 pages) - Importing External Pre-Shared Keys (PSKs) for TLS 1.3 [draft-ietf-tls-external-psk-importer-08] (11 pages) - Keying Material Exporters for Transport Layer Security (TLS) [draft-ietf-tls-extractor-07] (7 pages) - Transport Layer Security (TLS) False Start [draft-ietf-tls-falsestart-02] (11 pages) - Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility [draft-ietf-tls-grease-04] (12 pages) - HTTP Over TLS [draft-ietf-tls-https-03] (7 pages) - Upgrading to TLS Within HTTP/1.1 [draft-ietf-tls-http-upgrade-05] (13 pages) - Hybrid key exchange in TLS 1.3 [draft-ietf-tls-hybrid-design-11] (24 pages) - IANA Registry Updates for TLS and DTLS [draft-ietf-tls-iana-registry-updates-05] (20 pages) - Clientside interoperability experiences for the SSL and TLS protocols [draft-ietf-tls-interoperability-00] (30 pages) - Kerberos Cipher Suites in Transport Layer Security (TLS) [draft-ietf-tls-kerb-01] (0 pages) - Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) [draft-ietf-tls-kerb-cipher-suites-04] (7 pages) - The SSLKEYLOGFILE Format for TLS [draft-ietf-tls-keylogfile-02] (11 pages) - TLS Key Share Prediction [draft-ietf-tls-key-share-prediction-01] (7 pages) - Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2 [draft-ietf-tls-md5-sha1-deprecate-09] (5 pages) - Addition of MISTY1 to TLS [draft-ietf-tls-misty1-01] (3 pages) - The Transport Layer Security (TLS) Multiple Certificate Status Request Extension [draft-ietf-tls-multiple-cert-status-extension-08] (10 pages) - Negotiated Discrete Log Diffie-Hellman Ephemeral Parameters for TLS [draft-ietf-tls-negotiated-dl-dhe-00] (19 pages) - Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) [draft-ietf-tls-negotiated-ff-dhe-10] (29 pages) - NTRU Cipher Suites for TLS [draft-ietf-tls-ntru-00] (15 pages) - Deprecating TLS 1.0 and TLS 1.1 [draft-ietf-tls-oldversions-deprecate-12] (18 pages) - Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [draft-ietf-tls-oob-pubkey-11] (18 pages) - Extensions to TLS for OpenPGP keys [draft-ietf-tls-openpgp-02] (4 pages) - Using OpenPGP Keys for Transport Layer Security (TLS) Authentication [draft-ietf-tls-openpgp-keys-11] (8 pages) - A Transport Layer Security (TLS) ClientHello Padding Extension [draft-ietf-tls-padding-04] (4 pages) - Addition of Shared Key Authentication to Transport Layer Security (TLS) [draft-ietf-tls-passauth-00] (5 pages) - TLS Pathsec Protocol [draft-ietf-tls-pathsec-00] (50 pages) - Prohibiting RC4 Cipher Suites [draft-ietf-tls-prohibiting-rc4-01] (6 pages) - The TLS Protocol Version 1.0 [draft-ietf-tls-protocol-06] (80 pages) - Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) [draft-ietf-tls-psk-09] (15 pages) - Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode [draft-ietf-tls-psk-new-mac-aes-gcm-05] (7 pages) - Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS) [draft-ietf-tls-psk-null-03] (5 pages) - Secure Password Ciphersuites for Transport Layer Security (TLS) [draft-ietf-tls-pwd-07] (36 pages) - Record Size Limit Extension for TLS [draft-ietf-tls-record-limit-03] (8 pages) - Transport Layer Security (TLS) Renegotiation Indication Extension [draft-ietf-tls-renegotiation-03] (15 pages) - The Transport Layer Security (TLS) Protocol Version 1.1 [draft-ietf-tls-rfc2246-bis-13] (87 pages) - Transport Layer Security (TLS) Extensions [draft-ietf-tls-rfc3546bis-02] (30 pages) - The Transport Layer Security (TLS) Protocol Version 1.2 [draft-ietf-tls-rfc4346-bis-10] (104 pages) - Datagram Transport Layer Security Version 1.2 [draft-ietf-tls-rfc4347-bis-06] (32 pages) - Transport Layer Security (TLS) Extensions: Extension Definitions [draft-ietf-tls-rfc4366-bis-12] (25 pages) - Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier [draft-ietf-tls-rfc4492bis-17] (34 pages) - The Transport Layer Security (TLS) Protocol Version 1.3 [draft-ietf-tls-rfc5246-bis-00] (102 pages) - The Transport Layer Security (TLS) Protocol Version 1.3 [draft-ietf-tls-rfc8446bis-11] (160 pages) - IANA Registry Updates for TLS and DTLS [draft-ietf-tls-rfc8447bis-10] (18 pages) - AES Galois Counter Mode (GCM) Cipher Suites for TLS [draft-ietf-tls-rsa-aes-gcm-03] (8 pages) - TLS Extension for SEED and HAS-160 [draft-ietf-tls-seedhas-00] (4 pages) - Semi-Static Diffie-Hellman Key Establishment for TLS 1.3 [draft-ietf-tls-semistatic-dh-01] (7 pages) - Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension [draft-ietf-tls-session-hash-06] (15 pages) - Use of Shared Keys in the TLS Protocol [draft-ietf-tls-sharedkeys-02] (6 pages) - Issues and Requirements for Server Name Identification (SNI) Encryption in TLS [draft-ietf-tls-sni-encryption-09] (13 pages) - Secure Negotiation of Incompatible Protocols in TLS [draft-ietf-tls-snip-02] (12 pages) - Using the Secure Remote Password (SRP) Protocol for TLS Authentication [draft-ietf-tls-srp-14] (24 pages) - SSH Transport Layer Protocol [draft-ietf-tls-ssh-00] (19 pages) - Prohibiting Secure Sockets Layer (SSL) Version 2.0 [draft-ietf-tls-ssl2-must-not-04] (4 pages) - Modifications to the SSL protocol for TLS [draft-ietf-tls-ssl-mods-00] (4 pages) - Deprecating Secure Sockets Layer Version 3.0 [draft-ietf-tls-sslv3-diediedie-03] (7 pages) - The SSL Protocol Version 3.0 [draft-ietf-tls-ssl-version3-00] (63 pages) - Delegated Credentials for TLS and DTLS [draft-ietf-tls-subcerts-15] (17 pages) - Suite B Cipher Suites for TLS [draft-ietf-tls-suiteb-00] (8 pages) - Large Record Sizes for TLS and DTLS with Reduced Overhead [draft-ietf-tls-super-jumbo-record-limit-00] (8 pages) - Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings [draft-ietf-tls-svcb-ech-06] (9 pages) - TLS Ticket Requests [draft-ietf-tls-ticketrequests-07] (8 pages) - TLS 1.2 is in Feature Freeze [draft-ietf-tls-tls12-frozen-02] (5 pages) - The Transport Layer Security (TLS) Protocol Version 1.3 [draft-ietf-tls-tls13-28] (160 pages) - TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key [draft-ietf-tls-tls13-cert-with-extern-psk-07] (11 pages) - Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3 [draft-ietf-tls-tls13-pkcs1-01] (7 pages) - Example Handshake Traces for TLS 1.3 [draft-ietf-tls-tls13-vectors-07] (68 pages) - A Flags Extension for TLS 1.3 [draft-ietf-tls-tlsflags-14] (9 pages) - Wireless Extensions to TLS [draft-ietf-tls-wireless-00] (13 pages) - A well-known URI for publishing service parameters [draft-ietf-tls-wkech-06] (16 pages) - Abridged Compression for WebPKI Certificates [draft-jackson-tls-cert-abridge-00] (19 pages) - TLS Flag - Request mTLS [draft-jhoyla-req-mtls-flag-01] (4 pages) - Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 [draft-lvelvindron-tls-md5-sha1-deprecate-05] (5 pages) - Large Record Sizes for TLS and DTLS with Reduced Overhead [draft-mattsson-tls-super-jumbo-record-limit-05] (8 pages) - The ChaCha Stream Cipher for Transport Layer Security [draft-mavrogiannopoulos-chacha-tls-05] (8 pages) - Deprecating TLSv1.0 and TLSv1.1 [draft-moriarty-tls-oldversions-diediedie-01] (14 pages) - Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier [draft-nir-tls-rfc4492bis-00] (32 pages) - A Flags Extension for TLS 1.3 [draft-nir-tls-tlsflags-02] (6 pages) - Prohibiting RC4 Cipher Suites [draft-popov-tls-prohibiting-rc4-02] (4 pages) - Compact TLS 1.3 [draft-rescorla-tls-ctls-04] (17 pages) - The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 [draft-rescorla-tls-dtls13-01] (36 pages) - The Datagram Transport Layer Security (DTLS) Connection Identifier [draft-rescorla-tls-dtls-connection-id-02] (12 pages) - Encrypted Server Name Indication for TLS 1.3 [draft-rescorla-tls-esni-00] (19 pages) - Semi-Static Diffie-Hellman Key Establishment for TLS 1.3 [draft-rescorla-tls-semistatic-dh-02] (8 pages) - Delegated Credentials for TLS [draft-rescorla-tls-subcerts-02] (11 pages) - SSLKEYLOGFILE Extension for Encrypted Client Hello (ECH) [draft-rosomakho-tls-ech-keylogfile-00] (6 pages) - IANA Registry Updates for TLS and DTLS [draft-salowey-tls-rfc8447bis-01] (20 pages) - Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings [draft-sbn-tls-svcb-ech-00] (6 pages) - Exported Authenticators in TLS [draft-sullivan-tls-exported-authenticator-01] (6 pages) - Deprecating Secure Sockets Layer Version 3.0 [draft-thomson-sslv3-diediedie-00] (6 pages) - The SSLKEYLOGFILE Format for TLS [draft-thomson-tls-keylogfile-01] (9 pages) - Record Size Limit Extension for Transport Layer Security (TLS) [draft-thomson-tls-record-limit-00] (6 pages) - Secure Negotiation of Incompatible Protocols in TLS [draft-thomson-tls-snip-02] (12 pages) - Example Handshake Traces for TLS 1.3 [draft-thomson-tls-tls13-vectors-01] (28 pages) - Return Routability Check for DTLS 1.2 and DTLS 1.3 [draft-tschofenig-tls-dtls-rrc-01] (8 pages) - Extended Key Update for Transport Layer Security (TLS) 1.3 [draft-tschofenig-tls-extended-key-update-02] (14 pages) - Transport Layer Security (TLS) Resumption across Server Names [draft-vvv-tls-cross-sni-resumption-00] (5 pages) - Importing External PSKs for TLS [draft-wood-tls-external-psk-importer-01] (7 pages) - TLS Ticket Requests [draft-wood-tls-ticketrequests-01] (6 pages) Requests for Comments: RFC2246: The TLS Protocol Version 1.0 (80 pages) * Obsoletes RFC4346 * Updates RFC3546 * Updates RFC5746 * Updates RFC6176 * Updates RFC7465 * Updates RFC7507 * Updates RFC7919 RFC2712: Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) (7 pages) RFC2817: Upgrading to TLS Within HTTP/1.1 (13 pages) * Updates RFC7230 * Updates RFC7231 RFC2818: HTTP Over TLS (7 pages) * Updates RFC5785 * Updates RFC7230 * Obsoletes RFC9110 RFC3268: Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) (7 pages) * Obsoletes RFC5246 RFC3546: Transport Layer Security (TLS) Extensions (29 pages) * Obsoletes RFC4366 RFC3749: Transport Layer Security Protocol Compression Methods (8 pages) * Updates RFC8447 * Updates RFC8996 RFC4132: Addition of Camellia Cipher Suites to Transport Layer Security (TLS) (7 pages) * Obsoletes RFC5932 RFC4279: Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) (15 pages) * Updates RFC8996 RFC4346: The Transport Layer Security (TLS) Protocol Version 1.1 (87 pages) * Obsoletes RFC5246 * Updates RFC4366 * Updates RFC4680 * Updates RFC4681 * Updates RFC5746 * Updates RFC6176 * Updates RFC7465 * Updates RFC7507 * Updates RFC7919 RFC4366: Transport Layer Security (TLS) Extensions (30 pages) * Obsoletes RFC5246 * Obsoletes RFC6066 * Updates RFC5746 RFC4492: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) (35 pages) * Updates RFC5246 * Updates RFC7027 * Updates RFC7919 * Obsoletes RFC8422 RFC4785: Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS) (5 pages) * Updates RFC8996 RFC5054: Using the Secure Remote Password (SRP) Protocol for TLS Authentication (24 pages) * Updates RFC8996 RFC5081: Using OpenPGP Keys for Transport Layer Security (TLS) Authentication (8 pages) * Obsoletes RFC6091 RFC5246: The Transport Layer Security (TLS) Protocol Version 1.2 (104 pages) * Updates RFC5746 * Updates RFC5878 * Updates RFC6176 * Updates RFC7465 * Updates RFC7507 * Updates RFC7568 * Updates RFC7627 * Updates RFC7685 * Updates RFC7905 * Updates RFC7919 * Obsoletes RFC8446 * Updates RFC8447 * Updates RFC9155 RFC5288: AES Galois Counter Mode (GCM) Cipher Suites for TLS (8 pages) * Updates RFC9325 RFC5289: TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM) (6 pages) RFC5469: DES and IDEA Cipher Suites for Transport Layer Security (TLS) (4 pages) * Obsoletes RFC8996 RFC5487: Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode (7 pages) RFC5489: ECDHE_PSK Cipher Suites for Transport Layer Security (TLS) (7 pages) RFC5705: Keying Material Exporters for Transport Layer Security (TLS) (7 pages) * Updates RFC8446 * Updates RFC8447 RFC5746: Transport Layer Security (TLS) Renegotiation Indication Extension (15 pages) RFC6066: Transport Layer Security (TLS) Extensions: Extension Definitions (25 pages) * Updates RFC8446 * Updates RFC8449 * Updates RFC9325 RFC6176: Prohibiting Secure Sockets Layer (SSL) Version 2.0 (4 pages) * Updates RFC8996 RFC6347: Datagram Transport Layer Security Version 1.2 (32 pages) * Updates RFC7507 * Updates RFC7905 * Updates RFC8996 * Updates RFC9146 * Obsoletes RFC9147 RFC6520: Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension (9 pages) * Updates RFC8447 RFC6961: The Transport Layer Security (TLS) Multiple Certificate Status Request Extension (10 pages) * Obsoletes RFC8446 RFC7250: Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) (18 pages) RFC7301: Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension (9 pages) * Updates RFC8447 RFC7366: Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) (7 pages) RFC7465: Prohibiting RC4 Cipher Suites (6 pages) * Updates RFC8996 RFC7507: TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks (8 pages) * Obsoletes RFC8996 RFC7568: Deprecating Secure Sockets Layer Version 3.0 (7 pages) * Updates RFC8996 RFC7627: Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension (15 pages) RFC7685: A Transport Layer Security (TLS) ClientHello Padding Extension (4 pages) RFC7905: ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS) (8 pages) RFC7918: Transport Layer Security (TLS) False Start (11 pages) RFC7919: Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) (29 pages) RFC7924: Transport Layer Security (TLS) Cached Information Extension (19 pages) RFC8422: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier (34 pages) * Updates RFC8996 RFC8442: ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2 (7 pages) RFC8446: The Transport Layer Security (TLS) Protocol Version 1.3 (160 pages) RFC8447: IANA Registry Updates for TLS and DTLS (20 pages) RFC8448: Example Handshake Traces for TLS 1.3 (68 pages) RFC8449: Record Size Limit Extension for TLS (8 pages) RFC8701: Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility (12 pages) RFC8744: Issues and Requirements for Server Name Identification (SNI) Encryption in TLS (13 pages) RFC8773: TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key (11 pages) RFC8879: TLS Certificate Compression (8 pages) RFC8996: Deprecating TLS 1.0 and TLS 1.1 (18 pages) RFC9146: Connection Identifier for DTLS 1.2 (14 pages) RFC9147: The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 (61 pages) RFC9149: TLS Ticket Requests (8 pages) RFC9155: Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2 (5 pages) RFC9257: Guidance for External Pre-Shared Key (PSK) Usage in TLS (13 pages) RFC9258: Importing External Pre-Shared Keys (PSKs) for TLS 1.3 (11 pages) RFC9261: Exported Authenticators in TLS (14 pages) RFC9345: Delegated Credentials for TLS and DTLS (17 pages) Transport and Services Working Group (tsvwg) -------------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Gorry Fairhurst Marten Seemann Web and Internet Transport Directors: Francesca Palombini Zaheduzzaman Sarker Web and Internet Transport Advisor: Zaheduzzaman Sarker Mailing Lists: General Discussion: tsvwg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tsvwg Archive: https://mailarchive.ietf.org/arch/browse/tsvwg/ Description of Working Group: The Transport and Services Working Group (TSVWG) is the forum for development and publication of RFCs dealing with transport-layer topics that are not in scope of an existing working group or do not justify the formation of a new working group. A non-exhaustive list of transport topics includes mechanisms that deal with packetization and reassembly, ports, maximum transmission unit discovery, reordering, congestion control, loss detection and recovery, queue management, explicit congestion notification, multihoming, stream multiplexing, and quality of service (including DSCP and RSVP). Transport-layer protocols include TCP, QUIC, SCTP, UDP, and DCCP. TSVWG maintains these protocols and mechanisms in the absence of a specialized working group. The TSVWG mailing list is an open discussion forum for such work items, when they arise. The working group meets if there are active proposals that require discussion. The working group milestones are updated as needed to reflect the current work items and their associated milestones, with the approval of the responsible AD. The currently active TSVWG work items mostly fall under the following topics: (A) Maintenance and extension of the Stream Control Transmission Protocol (SCTP), User Datagram Protocol (UDP), and Datagram Congestion Control Protocol (DCCP), as these do not have dedicated working groups. (B) Explicit Congestion Notification (ECN), as the working group improves existing directives for tunnelling and observes the recently launched experiment with Low Latency, Low Loss, and Scalable Throughput (L4S). (C) Maintenance of IP Differentiated Services (DiffServ) mechanisms, which involves mostly advisory documents on the use of DiffServ in specific application scenarios. Other work items related to DiffServ require Area Director approval. Work in TSVWG must satisfy four conditions: (1) WG consensus on the suitability and projected quality of the proposed work item. (2) A core group of WG participants with sufficient energy and expertise to advance the work item according to the proposed schedule. (3) Commitment from the WG as a whole to provide sufficient and timely review of the proposed work item. (4) Agreement by the AD, who, depending on the scope of the proposed work item, may decide that an IESG review of adoption is needed first. Goals and Milestones: Nov 2024 - Submit "Careful convergence of congestion control from retained state" for publication as a Proposed Standard RFC. Nov 2024 - Submit "Datagram PLPMTUD for UDP Options" for publication as a Proposed Standard RFC. Nov 2024 - Submit "A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services" as a Proposed Standard RFC Dec 2024 - Submit "User Ports for Experiments " for publication as a Proposed Standard RFC. Mar 2025 - Submit "Authenticated Chunks for the SCTP" as a Proposed Standard RFC Mar 2025 - Submit "DTLS over SCTP" as a Proposed Standard RFC Apr 2025 - Submit "Operational Guidance for Deployment of L4S in the Internet" as an Informational RFC Done - Submit 'Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim' as a Proposed Standard RFC Done - Submit 'Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP' as a BCP RFC Done - Submit " DCCP Extensions for Multipath Operation with Multiple Addresses" as a Proposed Standard RFC Done - Submit " Transport Options for UDP" as a Proposed Standard RFC Internet-Drafts: - A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP [draft-allman-tcp-sack-13] (13 pages) - DCCP Extensions for Multipath Operation with Multiple Addresses [draft-amend-tsvwg-multipath-dccp-05] (29 pages) - Explicit Congestion Notification (ECN) Experimentation [draft-black-tsvwg-ecn-experimentation-04] (14 pages) - A Lower Effort Per-Hop Behavior (LE PHB) [draft-bless-tsvwg-le-phb-01] (7 pages) - DualQ Coupled AQM for Low Latency, Low Loss and Scalable Throughput [draft-briscoe-tsvwg-aqm-dualq-coupled-00] (24 pages) - Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing Delay [draft-briscoe-tsvwg-ecn-l4s-id-02] (25 pages) - Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture [draft-briscoe-tsvwg-l4s-arch-02] (34 pages) - Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim [draft-briscoe-tsvwg-rfc6040bis-01] (6 pages) - Configuring UDP Sockets for ECN for Common Platforms [draft-duke-tsvwg-udp-ecn-03] (9 pages) - UDP Usage Guidelines [draft-eggert-tsvwg-rfc5405bis-01] (37 pages) - Packetization Layer Path MTU Discovery for Datagram Transports [draft-fairhurst-tsvwg-datagram-plpmtud-02] (26 pages) - Datagram PLPMTUD for UDP Options [draft-fairhurst-tsvwg-udp-options-dplpmtud-05] (10 pages) - An Extension to the Selective Acknowledgement (SACK) Option for TCP [draft-floyd-sack-00] (17 pages) - DiffServ interconnection classes and practice [draft-geib-tsvwg-diffserv-intercon-08] (22 pages) - TCP Congestion Window Validation [draft-handley-tcp-cwv-01] (11 pages) - Stream Control Transmission Protocol [draft-ietf-tsvwg-2960bis-05] (152 pages) - Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration [draft-ietf-tsvwg-addip-sctp-22] (41 pages) - A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic [draft-ietf-tsvwg-admitted-realtime-dscp-07] (14 pages) - Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S) [draft-ietf-tsvwg-aqm-dualq-coupled-25] (52 pages) - Updates to Network Address Translation (NAT) Behavioral Requirements [draft-ietf-tsvwg-behave-requirements-update-08] (14 pages) - Byte and Packet Congestion Notification [draft-ietf-tsvwg-byte-pkt-congest-12] (41 pages) - Convergence of Congestion Control from Retained State [draft-ietf-tsvwg-careful-resume-11] (34 pages) - Specifying New Congestion Control Algorithms [draft-ietf-tsvwg-cc-alt-04] (10 pages) - Network Transport Circuit Breakers [draft-ietf-tsvwg-circuit-breaker-15] (24 pages) - Packetization Layer Path MTU Discovery for Datagram Transports [draft-ietf-tsvwg-datagram-plpmtud-22] (35 pages) - Aggregation of Diffserv Service Classes [draft-ietf-tsvwg-diffserv-class-aggr-07] (19 pages) - Diffserv-Interconnection Classes and Practice [draft-ietf-tsvwg-diffserv-intercon-14] (21 pages) - Configuration Guidelines for DiffServ Service Classes [draft-ietf-tsvwg-diffserv-service-classes-02] (57 pages) - Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions [draft-ietf-tsvwg-dsack-use-02] (9 pages) - Considerations for Assigning a New Recommended Differentiated Services Code Point (DSCP) [draft-ietf-tsvwg-dscp-considerations-13] (23 pages) - Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP) [draft-ietf-tsvwg-dtls-for-sctp-06] (9 pages) - Datagram Transport Layer Security (DTLS) over Stream Control Transmission Protocol (SCTP) [draft-ietf-tsvwg-dtls-over-sctp-bis-08] (45 pages) - The Addition of Explicit Congestion Notification (ECN) to IP [draft-ietf-tsvwg-ecn-04] (63 pages) - Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field [draft-ietf-tsvwg-ecn-alternates-02] (15 pages) - Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP [draft-ietf-tsvwg-ecn-encap-guidelines-22] (35 pages) - Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation [draft-ietf-tsvwg-ecn-experimentation-08] (20 pages) - An Open ECN Service in the IP layer [draft-ietf-tsvwg-ecn-ip-00] (15 pages) - The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S) [draft-ietf-tsvwg-ecn-l4s-id-29] (52 pages) - Explicit Congestion Marking in MPLS [draft-ietf-tsvwg-ecn-mpls-02] (21 pages) - Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets [draft-ietf-tsvwg-ecnsyn-00] (14 pages) - Tunnelling of Explicit Congestion Notification [draft-ietf-tsvwg-ecn-tunnel-10] (35 pages) - ECN Interactions with IP Tunnels [draft-ietf-tsvwg-ecn-tunnels-00] (13 pages) - RSVP Extensions for Admission Priority [draft-ietf-tsvwg-emergency-rsvp-15] (32 pages) - Forward Error Correction (FEC) Framework Extension to Sliding Window Codes [draft-ietf-tsvwg-fecframe-ext-08] (19 pages) - GRE-in-UDP Encapsulation [draft-ietf-tsvwg-gre-in-udp-encap-19] (27 pages) - HighSpeed TCP for Large Congestion Windows [draft-ietf-tsvwg-highspeed-01] (34 pages) - Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Codepoints (DSCP) Registry [draft-ietf-tsvwg-iana-dscp-registry-08] (7 pages) - Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry [draft-ietf-tsvwg-iana-ports-10] (33 pages) - Mapping Diffserv to IEEE 802.11 [draft-ietf-tsvwg-ieee-802-11-11] (37 pages) - Increasing TCP's Initial Window [draft-ietf-tsvwg-initwin-04] (15 pages) - Integrated Services (IntServ) Extension to Allow Signaling of Multiple Traffic Specifications and Multiple Flow Specifications in RSVPv1 [draft-ietf-tsvwg-intserv-multiple-tspec-02] (26 pages) - Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture [draft-ietf-tsvwg-l4s-arch-20] (36 pages) - Operational Guidance on Coexistence with Classic ECN during L4S Deployment [draft-ietf-tsvwg-l4sops-06] (22 pages) - A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services [draft-ietf-tsvwg-le-phb-10] (18 pages) - Enhancing TCP's Loss Recovery Using Limited Transmit [draft-ietf-tsvwg-limited-xmit-00] (9 pages) - MLEF Without Capacity Admission Does Not Satisfy MLPP Requirements [draft-ietf-tsvwg-mlef-concerns-00] (20 pages) - Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite [draft-ietf-tsvwg-mlpp-that-works-04] (42 pages) - DCCP Extensions for Multipath Operation with Multiple Addresses [draft-ietf-tsvwg-multipath-dccp-17] (53 pages) - Stream Control Transmission Protocol (SCTP) Network Address Translation Support [draft-ietf-tsvwg-natsupp-23] (52 pages) - The NewReno Modification to TCP's Fast Recovery Algorithm [draft-ietf-tsvwg-newreno-02] (19 pages) - A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services [draft-ietf-tsvwg-nqb-27] (38 pages) - Recommendations for Transport-Protocol Port Randomization [draft-ietf-tsvwg-port-randomization-09] (29 pages) - Recommendations on Using Assigned Transport Port Numbers [draft-ietf-tsvwg-port-use-11] (24 pages) - Stream Control Transmission Protocol (SCTP) Partial Reliability Extension [draft-ietf-tsvwg-prsctp-03] (22 pages) - Quick-Start for TCP and IP [draft-ietf-tsvwg-quickstart-07] (82 pages) - Stream Control Transmission Protocol [draft-ietf-tsvwg-rfc2960-bis-00] (116 pages) - Authenticated Chunks for the Stream Control Transmission Protocol (SCTP) [draft-ietf-tsvwg-rfc4895-bis-04] (24 pages) - Stream Control Transmission Protocol [draft-ietf-tsvwg-rfc4960-bis-19] (133 pages) - Stream Control Transmission Protocol: Errata and Issues in RFC 4960 [draft-ietf-tsvwg-rfc4960-errata-08] (94 pages) - UDP Usage Guidelines [draft-ietf-tsvwg-rfc5405bis-19] (55 pages) - Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim [draft-ietf-tsvwg-rfc6040update-shim-23] (24 pages) - Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME [draft-ietf-tsvwg-rlc-fec-scheme-16] (37 pages) - Resource Reservation Protocol (RSVP) Application-ID Profiles for Voice and Video Streams [draft-ietf-tsvwg-rsvp-app-id-vv-profiles-02] (15 pages) - A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow [draft-ietf-tsvwg-rsvp-bw-reduction-02] (21 pages) - Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels [draft-ietf-tsvwg-rsvp-dste-05] (31 pages) - Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations [draft-ietf-tsvwg-rsvp-ipsec-05] (32 pages) - Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs [draft-ietf-tsvwg-rsvp-l3vpn-07] (38 pages) - Extensions to Generic Aggregate RSVP for IPv4 and IPv6 Reservations over Pre-Congestion Notification (PCN) Domains [draft-ietf-tsvwg-rsvp-pcn-11] (36 pages) - Resource Reservation Protocol (RSVP) Proxy Approaches [draft-ietf-tsvwg-rsvp-proxy-approaches-09] (50 pages) - Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy [draft-ietf-tsvwg-rsvp-proxy-proto-11] (35 pages) - Applicability of Keying Methods for RSVP Security [draft-ietf-tsvwg-rsvp-security-groupkeying-11] (19 pages) - User-Defined Errors for RSVP [draft-ietf-tsvwg-rsvp-user-error-spec-08] (9 pages) - Differentiated Services Code Point (DSCP) Packet Markings for WebRTC QoS [draft-ietf-tsvwg-rtcweb-qos-18] (9 pages) - Authenticated Chunks for the Stream Control Transmission Protocol (SCTP) [draft-ietf-tsvwg-sctp-auth-08] (19 pages) - Stream Control Transmission Protocol (SCTP) Chunk Flags Registration [draft-ietf-tsvwg-sctp-chunk-flags-02] (8 pages) - Stream Control Transmission Protocol (SCTP) Checksum Change [draft-ietf-tsvwg-sctpcsum-07] (17 pages) - Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets [draft-ietf-tsvwg-sctp-dtls-encaps-09] (10 pages) - SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol [draft-ietf-tsvwg-sctp-failover-16] (23 pages) - Stream Control Transmission Protocol (SCTP) Specification Errata and Issues [draft-ietf-tsvwg-sctpimpguide-16] (109 pages) - Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol [draft-ietf-tsvwg-sctp-ndata-13] (23 pages) - Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP) [draft-ietf-tsvwg-sctp-padding-02] (6 pages) - Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension [draft-ietf-tsvwg-sctp-prpolicies-07] (11 pages) - SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol [draft-ietf-tsvwg-sctp-sack-immediately-04] (8 pages) - Sockets API Extensions for the Stream Control Transmission Protocol (SCTP) [draft-ietf-tsvwg-sctpsocket-32] (115 pages) - Stream Control Transmission Protocol (SCTP) Stream Reconfiguration [draft-ietf-tsvwg-sctp-strrst-13] (34 pages) - Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures [draft-ietf-tsvwg-sctpthreat-05] (14 pages) - UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication [draft-ietf-tsvwg-sctp-udp-encaps-14] (12 pages) - Zero Checksum for the Stream Control Transmission Protocol [draft-ietf-tsvwg-sctp-zero-checksum-11] (12 pages) - Limited Slow-Start for TCP with Large Congestion Windows [draft-ietf-tsvwg-slowstart-00] (7 pages) - Deprecation of ICMP Source Quench Messages [draft-ietf-tsvwg-source-quench-06] (8 pages) - TCP with ECN: The Treatment of Retransmitted Data Packets [draft-ietf-tsvwg-tcp-ecn-00] (9 pages) - The Eifel Detection Algorithm for TCP [draft-ietf-tsvwg-tcp-eifel-alg-07] (14 pages) - The Eifel Response Algorithm for TCP [draft-ietf-tsvwg-tcp-eifel-response-06] (13 pages) - F-RTO: An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and SCTP [draft-ietf-tsvwg-tcp-frto-01] (19 pages) - TCP Extended Statistics MIB [draft-ietf-tsvwg-tcp-mib-extension-15] (75 pages) - Robust Explicit Congestion Notification (ECN) Signaling with Nonces [draft-ietf-tsvwg-tcp-nonce-04] (13 pages) - ULP Framing for TCP [draft-ietf-tsvwg-tcp-ulp-frame-01] (30 pages) - TCP Friendly Rate Control (TFRC): Protocol Specification [draft-ietf-tsvwg-tfrc-05] (24 pages) - TinyMT32 Pseudorandom Number Generator (PRNG) [draft-ietf-tsvwg-tinymt32-06] (12 pages) - Transport Layer Security over Stream Control Transmission Protocol [draft-ietf-tsvwg-tls-over-sctp-00] (9 pages) - Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols [draft-ietf-tsvwg-transport-encrypt-21] (37 pages) - Unicast UDP Usage Guidelines for Application Designers [draft-ietf-tsvwg-udp-guidelines-11] (27 pages) - The Lightweight User Datagram Protocol (UDP-Lite) [draft-ietf-tsvwg-udp-lite-02] (12 pages) - MIB for the UDP-Lite protocol [draft-ietf-tsvwg-udplite-mib-03] (23 pages) - Transport Options for UDP [draft-ietf-tsvwg-udp-options-38] (56 pages) - Datagram PLPMTUD for UDP Options [draft-ietf-tsvwg-udp-options-dplpmtud-13] (17 pages) - User Ports for Experiments [draft-ietf-tsvwg-usr-exp-02] (7 pages) - Quality of Service (QoS) Signaling in a Nested Virtual Private Network [draft-ietf-tsvwg-vpn-signaled-preemption-02] (38 pages) - Careful convergence of congestion control from retained state [draft-kuhn-tsvwg-careful-resume-01] (18 pages) - Computing TCP's Retransmission Timer [draft-paxson-tcp-rto-01] (8 pages) - TinyMT32 Pseudo Random Number Generator (PRNG) [draft-roca-tsvwg-tinymt32-01] (10 pages) - Guidelines for DiffServ to IEEE 802.11 Mapping [draft-szigeti-tsvwg-ieee-802-11-02] (27 pages) - Transport Options for UDP [draft-touch-tsvwg-udp-options-09] (27 pages) - User Ports for Experiments [draft-touch-tsvwg-usr-exp-01] (5 pages) - Authenticated Chunks for the Stream Control Transmission Protocol (SCTP) [draft-tuexen-tsvwg-rfc4895-bis-06] (22 pages) - RFC 4960 Errata and Issues [draft-tuexen-tsvwg-rfc4960-errata-04] (44 pages) - Datagram Transport Layer Security (DTLS) over Stream Control Transmission Protocol (SCTP) [draft-westerlund-tsvwg-dtls-over-sctp-bis-01] (22 pages) - Operational Guidance for Deployment of L4S in the Internet [draft-white-tsvwg-l4sops-02] (13 pages) - Identifying and Handling Non Queue Building Flows in a Bottleneck Link [draft-white-tsvwg-nqb-02] (12 pages) - TCP Processing of the IPv4 Precedence Field [draft-xiao-tcp-prec-03] (8 pages) Requests for Comments: RFC2861: TCP Congestion Window Validation (11 pages) * Obsoletes RFC7661 RFC2873: TCP Processing of the IPv4 Precedence Field (8 pages) * Obsoletes RFC9293 RFC2883: An Extension to the Selective Acknowledgement (SACK) Option for TCP (17 pages) RFC2988: Computing TCP's Retransmission Timer (8 pages) * Obsoletes RFC6298 RFC3042: Enhancing TCP's Loss Recovery Using Limited Transmit (9 pages) RFC3168: The Addition of Explicit Congestion Notification (ECN) to IP (63 pages) * Updates RFC4301 * Updates RFC6040 * Updates RFC8311 RFC3309: Stream Control Transmission Protocol (SCTP) Checksum Change (17 pages) * Obsoletes RFC4960 RFC3390: Increasing TCP's Initial Window (15 pages) RFC3436: Transport Layer Security over Stream Control Transmission Protocol (9 pages) * Updates RFC8996 RFC3448: TCP Friendly Rate Control (TFRC): Protocol Specification (24 pages) * Obsoletes RFC5348 RFC3517: A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP (13 pages) * Obsoletes RFC6675 RFC3522: The Eifel Detection Algorithm for TCP (14 pages) RFC3540: Robust Explicit Congestion Notification (ECN) Signaling with Nonces (13 pages) RFC3649: HighSpeed TCP for Large Congestion Windows (34 pages) RFC3708: Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions (9 pages) RFC3742: Limited Slow-Start for TCP with Large Congestion Windows (7 pages) RFC3758: Stream Control Transmission Protocol (SCTP) Partial Reliability Extension (22 pages) RFC3782: The NewReno Modification to TCP's Fast Recovery Algorithm (19 pages) * Obsoletes RFC6582 RFC3828: The Lightweight User Datagram Protocol (UDP-Lite) (12 pages) * Updates RFC6335 RFC4015: The Eifel Response Algorithm for TCP (13 pages) RFC4460: Stream Control Transmission Protocol (SCTP) Specification Errata and Issues (109 pages) * Obsoletes RFC9260 RFC4495: A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow (21 pages) RFC4542: Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite (42 pages) * Updates RFC5865 RFC4594: Configuration Guidelines for DiffServ Service Classes (57 pages) * Updates RFC5865 * Updates RFC8622 RFC4774: Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field (15 pages) * Updates RFC6040 RFC4782: Quick-Start for TCP and IP (82 pages) RFC4804: Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels (31 pages) RFC4820: Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP) (6 pages) RFC4860: Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations (32 pages) RFC4895: Authenticated Chunks for the Stream Control Transmission Protocol (SCTP) (19 pages) RFC4898: TCP Extended Statistics MIB (75 pages) RFC4923: Quality of Service (QoS) Signaling in a Nested Virtual Private Network (38 pages) RFC4960: Stream Control Transmission Protocol (152 pages) * Updates RFC6096 * Updates RFC6335 * Updates RFC7053 * Updates RFC8899 * Obsoletes RFC9260 RFC5033: Specifying New Congestion Control Algorithms (10 pages) RFC5061: Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration (41 pages) RFC5062: Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures (14 pages) RFC5097: MIB for the UDP-Lite protocol (23 pages) RFC5127: Aggregation of Diffserv Service Classes (19 pages) RFC5129: Explicit Congestion Marking in MPLS (21 pages) * Updates RFC5462 RFC5284: User-Defined Errors for RSVP (9 pages) RFC5405: Unicast UDP Usage Guidelines for Application Designers (27 pages) * Obsoletes RFC8085 RFC5865: A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic (14 pages) RFC5945: Resource Reservation Protocol (RSVP) Proxy Approaches (50 pages) RFC5946: Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy (35 pages) RFC6016: Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs (38 pages) RFC6040: Tunnelling of Explicit Congestion Notification (35 pages) * Updates RFC9601 RFC6056: Recommendations for Transport-Protocol Port Randomization (29 pages) RFC6083: Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP) (9 pages) * Updates RFC8996 RFC6096: Stream Control Transmission Protocol (SCTP) Chunk Flags Registration (8 pages) * Obsoletes RFC9260 RFC6335: Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry (33 pages) RFC6401: RSVP Extensions for Admission Priority (32 pages) RFC6411: Applicability of Keying Methods for RSVP Security (19 pages) RFC6458: Sockets API Extensions for the Stream Control Transmission Protocol (SCTP) (115 pages) RFC6525: Stream Control Transmission Protocol (SCTP) Stream Reconfiguration (34 pages) RFC6633: Deprecation of ICMP Source Quench Messages (8 pages) RFC6951: UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication (12 pages) * Updates RFC8899 RFC7053: SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol (8 pages) * Obsoletes RFC9260 RFC7141: Byte and Packet Congestion Notification (41 pages) RFC7417: Extensions to Generic Aggregate RSVP for IPv4 and IPv6 Reservations over Pre-Congestion Notification (PCN) Domains (36 pages) RFC7496: Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension (11 pages) RFC7605: Recommendations on Using Assigned Transport Port Numbers (24 pages) RFC7829: SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol (23 pages) RFC7857: Updates to Network Address Translation (NAT) Behavioral Requirements (14 pages) RFC8084: Network Transport Circuit Breakers (24 pages) RFC8085: UDP Usage Guidelines (55 pages) * Updates RFC8899 RFC8086: GRE-in-UDP Encapsulation (27 pages) RFC8100: Diffserv-Interconnection Classes and Practice (21 pages) RFC8260: Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol (23 pages) RFC8261: Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets (10 pages) * Updates RFC8899 * Updates RFC8996 RFC8311: Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation (20 pages) RFC8325: Mapping Diffserv to IEEE 802.11 (37 pages) * Updates RFC8622 RFC8436: Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Codepoints (DSCP) Registry (7 pages) RFC8540: Stream Control Transmission Protocol: Errata and Issues in RFC 4960 (94 pages) * Obsoletes RFC9260 RFC8622: A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services (18 pages) RFC8680: Forward Error Correction (FEC) Framework Extension to Sliding Window Codes (19 pages) RFC8681: Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME (37 pages) RFC8682: TinyMT32 Pseudorandom Number Generator (PRNG) (12 pages) RFC8837: Differentiated Services Code Point (DSCP) Packet Markings for WebRTC QoS (9 pages) RFC8899: Packetization Layer Path MTU Discovery for Datagram Transports (35 pages) RFC9065: Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols (37 pages) RFC9260: Stream Control Transmission Protocol (133 pages) RFC9330: Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture (36 pages) RFC9331: The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S) (52 pages) RFC9332: Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S) (52 pages) RFC9435: Considerations for Assigning a New Recommended Differentiated Services Code Point (DSCP) (23 pages) RFC9599: Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP (28 pages) RFC9601: Propagating Explicit Congestion Notification across IP Tunnel Headers Separated by a Shim (19 pages) RFC9653: Zero Checksum for the Stream Control Transmission Protocol (11 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-03] (23 pages) - TVR (Time-Variant Routing) Use Cases [draft-ietf-tvr-use-cases-09] (18 pages) Requests for Comments: RFC9657: Time-Variant Routing (TVR) Use Cases (14 pages) Using TLS in Applications (uta) ------------------------------- Charter Last Modified: 2024-03-21 Current Status: Active Chairs: Alan DeKok Valery Smyslov Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Paul Wouters Mailing Lists: General Discussion: uta@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/uta Archive: https://mailarchive.ietf.org/arch/browse/uta/ Description of Working Group: There is a renewed and urgent interest in the IETF to increase the security of transmissions over the Internet. Many application protocols have defined methods for using TLS to authenticate the server (and sometimes the client), and to encrypt the connection between the client and server. However, there is a diversity of definitions and requirements, and that diversity has caused confusion for application developers and also has led to lack of interoperability or lack of deployment. Implementers and deployers are faced with multiple security issues in real-world usage of TLS, which currently does not preclude insecure ciphers and modes of operation. This WG has the following tasks: - Update the definitions for using TLS over a set of representative application protocols. This includes communication with proxies, between servers, and between peers, where appropriate, in addition to client/server communication. - Specify a set of best practices for TLS clients and servers, including but not limited to recommended versions of TLS, using forward secrecy, and one or more ciphersuites and extensions that are mandatory to implement. - Consider, and possibly define, a standard way for an application client and server to use unauthenticated encryption through TLS when server and/or client authentication cannot be achieved. - Create a document that helps application protocol developers use TLS in future application definitions. The initial set of representative application protocols is SMTP, POP, IMAP, XMPP, and HTTP 1.1. It is expected that other protocols that use TLS might later be updated using the guidelines from this WG, and that those updates will happen through other WGs or through individual submissions. The WG will make the fewest changes needed to achieve good interoperable security for the applications using TLS. No changes to TLS itself will be made in this WG, and the WG will ensure that changes to current versions of popular TLS libaries will not be required to conform to the WG's specifications. This WG will collaborate with other IETF WGs, in particular with the TLS and DANE WGs. Goals and Milestones: Mar 2024 - TLS/DTLS 1.3 Profiles for IoT to IETF LC Done - Use of TLS for Email Submission and Access to IETF LC Done - Recommendations for Secure Use of TLS and DTLS (rfc7525-bis) to IETF LC Done - Representation and Verification of Domain-Based Application Service Identity within Internet PKI Using X.509 Certificates in the Context of TLS (rfc6125-bis) to IETF LC Done - Updates to the Cipher Suites in Secure Syslog to IETF LC Internet-Drafts: - Updates to the Cipher Suites in Secure Syslog [draft-ciphersuites-in-sec-syslog-01] (8 pages) - Updates to the Cipher Suites in Secure Syslog [draft-ietf-uta-ciphersuites-in-sec-syslog-07] (8 pages) - Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access [draft-ietf-uta-email-deep-12] (26 pages) - Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols [draft-ietf-uta-email-tls-certs-09] (13 pages) - SMTP MTA Strict Transport Security (MTA-STS) [draft-ietf-uta-mta-sts-21] (29 pages) - New Protocols Must Require TLS 1.3 [draft-ietf-uta-require-tls13-02] (8 pages) - Service Identity in TLS [draft-ietf-uta-rfc6125bis-15] (25 pages) - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [draft-ietf-uta-rfc7525bis-11] (34 pages) - SMTP Require TLS Option [draft-ietf-uta-smtp-require-tls-09] (16 pages) - SMTP TLS Reporting [draft-ietf-uta-smtp-tlsrpt-23] (34 pages) - TLS/DTLS 1.3 Profiles for the Internet of Things [draft-ietf-uta-tls13-iot-profile-11] (28 pages) - Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS) [draft-ietf-uta-tls-attacks-05] (13 pages) - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [draft-ietf-uta-tls-bcp-11] (27 pages) - Deprecation of TLS 1.1 for Email Submission and Access [draft-ietf-uta-tls-for-email-05] (6 pages) - Update to Verifying TLS Server Identities with X.509 Certificates [draft-ietf-uta-use-san-00] (5 pages) - Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP) [draft-ietf-uta-xmpp-07] (9 pages) - Deployable Enhanced Email Privacy (DEEP) [draft-newman-email-deep-02] (35 pages) - Update to Verifying TLS Server Identities with X.509 Certificates [draft-rsalz-use-san-01] (5 pages) - New Protocols Must Require TLS 1.3 [draft-rsalz-uta-require-tls13-01] (8 pages) - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [draft-sheffer-uta-rfc7525bis-00] (26 pages) - TLS/DTLS 1.3 Profiles for the Internet of Things [draft-tschofenig-uta-tls13-profile-04] (9 pages) Requests for Comments: RFC7457: Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS) (13 pages) RFC7525: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) (27 pages) * Updates RFC8996 * Obsoletes RFC9325 RFC7590: Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP) (9 pages) RFC7817: Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols (13 pages) RFC8314: Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access (26 pages) * Updates RFC8997 RFC8460: SMTP TLS Reporting (34 pages) RFC8461: SMTP MTA Strict Transport Security (MTA-STS) (29 pages) RFC8689: SMTP Require TLS Option (16 pages) RFC8997: Deprecation of TLS 1.1 for Email Submission and Access (6 pages) RFC9325: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) (34 pages) RFC9525: Service Identity in TLS (25 pages) RFC9662: Updates to the Cipher Suites in Secure Syslog (7 pages) 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) - IPv6-Mostly Networks: Deployment and Operations Considerations [draft-ietf-v6ops-6mops-00] (22 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-02] (16 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-05] (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-08] (23 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-06] (26 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) - Basic Requirements for IPv6 Customer Edge Routers [draft-ietf-v6ops-rfc7084bis-01] (20 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) RFC9663: Using DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique IPv6 Prefixes per Client in Large Broadcast Networks (19 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 JSON format for vCon - Conversation Data Container [draft-ietf-vcon-vcon-container-01] (90 pages) No Requests for Comments WebTransport (webtrans) ----------------------- Charter Last Modified: 2024-01-17 Current Status: Active Chairs: David Schinazi Dr. Bernard D. Aboba Web and Internet Transport Directors: Francesca Palombini Zaheduzzaman Sarker Web and Internet Transport Advisor: Francesca Palombini Mailing Lists: General Discussion: webtransport@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/webtransport Archive: https://mailarchive.ietf.org/arch/browse/webtransport/ Description of Working Group: Description of Working Group The WebTransport working group will define new client-server protocols or protocol extensions in order to support the development of the WebTransport API https://wicg.github.io/web-transport. The WebTransport working group will define an application-layer protocol or suite of application-layer protocols that support a range of simple communication methods. These must include unreliable messages (that might be limited by the path MTU), reliable messages, and ordered streams of reliable messages. Attention will be paid to the performance of the protocol, with particular attention to the protocol’s overhead and the potential for head-of-line blocking; its ability to be deployed and used reliably under different network conditions; and its ability to integrate into the Web security model. The working group will not define new transport protocols but will instead use existing protocols such as QUIC and TLS/TCP. The group will pay attention to security issues arising from the above scenarios so as to protect against creation of new modes of attack. To assist in the coordination with owners of the WebTransport API, the group will initially develop an overview document containing use cases and requirements in order to clarify the goals of the effort. The requirements will include those arising from the WebTransport API. Feedback will also be solicited at various points along the way in order to ensure the best possible match between the protocol extensions and the needs of the WebTransport API. The group will also coordinate with related working groups within the IETF, such as QUIC and HTTPBIS, as appropriate. In particular, if the working group needs any changes to or extensions of the core protocols, those issues will be raised with the relevant working groups for decisions on how best to handle them. If those decisions result in work in WebTrans, the working group last calls for that work will again be sent to the relevant working groups. The group also needs to coordinate with TAPS, as they are working on related message-based APIs and it's important to make sure there aren't conflicts and/or duplications. Goals and Milestones: Jul 2024 - Issue WG last call of the WebTransport Overview document. Jul 2024 - Issue WG last call on the first WebTransport protocol document Done - Adopt a WebTransport Overview draft as a WG work item Done - Adopt a draft defining a WebTransport protocol as a WG work item Internet-Drafts: - WebTransport over HTTP/2 [draft-ietf-webtrans-http2-10] (37 pages) - WebTransport over HTTP/3 [draft-ietf-webtrans-http3-11] (23 pages) - The WebTransport Protocol Framework [draft-ietf-webtrans-overview-08] (12 pages) - WebTransport using HTTP/2 [draft-kinnear-webtransport-http2-02] (14 pages) - WebTransport over HTTP/3 [draft-vvv-webtransport-http3-03] (12 pages) - The WebTransport Protocol Framework [draft-vvv-webtransport-overview-01] (11 pages) No Requests for Comments Workload Identity in Multi System Environments (wimse) ------------------------------------------------------ Charter Last Modified: 2024-10-30 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-02] (15 pages) - WIMSE Service to Service Authentication [draft-ietf-wimse-s2s-protocol-01] (25 pages) - OAuth 2.0 Client Assertion in Workload Environments [draft-ietf-wimse-workload-identity-bcp-02] (19 pages) - Workload Identity in a Multi System Environment (WIMSE) Architecture [draft-salowey-wimse-arch-01] (11 pages) No Requests for Comments WebRTC Ingest Signaling over HTTPS (wish) ----------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Nils Ohlmeier Sean Turner Web and Internet Transport Directors: Francesca Palombini Zaheduzzaman Sarker Web and Internet Transport Advisor: Francesca Palombini Mailing Lists: General Discussion: wish@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/wish Archive: https://mailarchive.ietf.org/arch/browse/wish/ Description of Working Group: The WISH working group is chartered to specify a simple, extensible, HTTPS-based set of signaling protocols to establish one-way WebRTC-based audiovisual sessions between broadcasting tools, media players and real-time media broadcast networks. Background: WebRTC defines a set of wire protocols for real-time media transmission, as well as a profile of the Session Description Protocol (SDP) for setting up and controlling the associated media streams. Because of its typical use cases, and to increase overall flexibility, WebRTC did not specify a wire protocol for exchanging SDP messages, leaving the creation of such protocols up to the applications that use WebRTC. This works well when WebRTC clients are vertically integrated with the servers they communicate with, as it allows for rapid iteration of new features. At the same time, the use of WebRTC as a mechanism for large-scale media broadcast is gaining popularity, and unlike more vertically integrated uses of WebRTC, WebRTC-based media distribution networks would benefit immensely from being able to re-use the several broadcasting tools that have been developed over time. To date, these media distribution networks have employed their own proprietary signaling protocols to establish the connection between broadcasting tools and the network, generally requiring either bespoke software or customized modifications to existing tools. With the large number of available tools and the growing number of real-time media distribution networks, this ad-hoc approach to creating custom protocols for establishing sessions clearly does not scale. The real-time broadcasting ecosystem would benefit immensely from a set of common protocols to meet this goal. Deliverables: The product of this working group will be a specification for a simple, extensible, HTTPS-based signaling protocol set to establish one-way WebRTC-based audiovisual sessions between broadcasting tools and real-time media broadcast networks, and between those networks and the media players. This working group will use existing HTTPS, WebRTC, and SDP mechanisms to the extent possible. While no extensions to those core protocols is expected, the working group may consider such extensions if they are necessary to meet the requirements of broadcasting tools and networks. Any such work will be coordinated with the HTTPBIS, MMUSIC, and/or MOPS working groups, as appropriate. Additionally, this working group will coordinate with HTTPBIS and HTTPAPI to assure that the HTTP protocol is being used according to current best practice. While there may be other problems that the proposed mechanism may solve or nearly solve, such as general purpose bidirectional realtime communication (telephony, video conferencing etc), adding explicit protocol support for those use cases is not in scope for the WISH working group. Goals and Milestones: Dec 2024 - Submit WebRTC-HTTP egress protocol to IESG for publication Internet-Drafts: - WebRTC-HTTP Egress Protocol (WHEP) [draft-ietf-wish-whep-02] (38 pages) - WebRTC-HTTP ingestion protocol (WHIP) [draft-ietf-wish-whip-16] (34 pages) - WebRTC-HTTP Egress Protocol (WHEP) [draft-murillo-whep-03] (24 pages) No Requests for Comments