6lo 6man 6tisch ace acme add alto anima avtcore babel bess bfcpbis bfd bier bmwg calext capport cbor ccamp cdni cellar core cose curdle detnet dhc dime dispatch dmarc dmm dnsop dnssd dots dprive drip dtn ecrit emu extra gendispatch git grow hip homenet httpbis i2nsf i2rs ice idr intarea ippm ipsecme ipwave jmap kitten lake lamps lisp lpwan lsr lsvr lwig manet mboned mile mls mmusic mops mpls netconf netmod nfsv4 ntp nvo3 oauth opsawg opsec pals pce perc pim quic radext rats raw regext rift rmcat roll rtgwg rum sacm secdispatch secevent sfc sidrops sipbrandy sipcore spring stir suit taps tcpm teas teep tictoc tls tokbind tram trans tsvwg uta v6ops webtrans wpack IPv6 over Networks of Resource-constrained Nodes (6lo) ------------------------------------------------------ Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Carles Gomez Shwetha Bhandari Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Erik Kline Mailing Lists: General Discussion: 6lo@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/6lo Archive: https://mailarchive.ietf.org/arch/browse/6lo/ Description of Working Group: 6lo focuses on the work that facilitates IPv6 connectivity over constrained node networks with the characteristics of: * limited power, memory and processing resources * hard upper bounds on state, code space and processing cycles * optimization of energy and network bandwidth usage * lack of some layer 2 services like complete device connectivity and broadcast/multicast Specifically, 6lo will work on: 1. IPv6-over-foo adaptation layer specifications using 6LoWPAN technologies (RFC4944, RFC6282, RFC6775) for link layer technologies of interest in constrained node networks 2. Information and data models (e.g., MIB modules) for these adaptation layers for basic monitoring and troubleshooting. 3. Specifications, such as low-complexity header compression, that are applicable to more than one adaptation layer specification 4. Maintenance and informational documents required for the existing IETF specifications in this space. Only specifications targeting constrained node networks are in scope. 6lo will work closely with the 6man working group, which will continue to work on IP-over-foo documents outside the constrained node network space and will continue to be the focal point for IPv6 maintenance. For adaptation layer specifications that do not have implications on IPv6 architecture, 6man will be notified about 6lo's working group last call. Specifications that might have such an impact (e.g., by using IPv6 addresses in a specific way or by introducing new ND options or by exposing to IPv6 a link model different from either Ethernet or 6lowpan) will be closely coordinated with 6man, and/or specific parts will be fanned out to 6man documents. Beyond 6man, 6lo will also coordinate with LWIG and INTAREA. 6lo works on small, focused pieces of work, but does not take on larger cross-layer efforts. The working group will continue to reuse existing protocols and mechanisms whenever reasonable and possible. Security and management work that is not specific to the link layers being worked on is out of scope. Work related to routing is out of scope. 6lo will coordinate closely with the working groups in other areas that focus on constrained node networks, such as ROLL (RTG) and CoRE (APP). Goals and Milestones: Mar 2015 - WG LC for draft-ietf-6lo-dect-ule Mar 2015 - WG last call for draft-ietf-6lo-6lobac Apr 2015 - WG adoption call for 6lo security related draft 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] (32 pages) - IPv6 Backbone Router [draft-ietf-6lo-backbone-router-20] (37 pages) - IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP [draft-ietf-6lo-blemesh-07] (15 pages) - IPv6 over BLUETOOTH(R) Low Energy [draft-ietf-6lo-btle-17] (21 pages) - Packet Delivery Deadline time in 6LoWPAN Routing Header [draft-ietf-6lo-deadline-time-05] (21 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) - 6LoWPAN Selective Fragment Recovery [draft-ietf-6lo-fragment-recovery-21] (32 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 Multihop IPv6 Network [draft-ietf-6lo-minimal-fragment-15] (14 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) - Transmission of IPv6 Packets over Near Field Communication [draft-ietf-6lo-nfc-15] (17 pages) - IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch [draft-ietf-6lo-paging-dispatch-05] (8 pages) - Transmission of IPv6 Packets over PLC Networks [draft-ietf-6lo-plc-03] (19 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) - IPv6 over Constrained Node Networks (6lo) Applicability & Use cases [draft-ietf-6lo-use-cases-08] (25 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) IPv6 Maintenance (6man) ----------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Bob Hinden Ole Trøan 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: Done - Submit RH0 Deprecation specification to IESG as a Proposed Standard Done - Submit PPP Compression Negotiation specification to IESG as a Proposed Standard Done - Determine way forward for ULA-C specification Done - Resolve open issues with "U/G" bits in Interface Identifiers 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) - Analysis of the 64-bit Boundary in IPv6 Addressing [draft-carpenter-6man-why64-01] (20 pages) - IPv6 Node Requirements [draft-clw-rfc6434-bis-01] (34 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) - 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) - Considerations for IPv6 Address Selection Policy Changes [draft-ietf-6man-addr-select-considerations-05] (18 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) - 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) - IPv6 Router Advertisement Options for DNS Configuration [draft-ietf-6man-dns-options-bis-08] (19 pages) - Enhanced Duplicate Address Detection [draft-ietf-6man-enhanced-dad-15] (11 pages) - Transmission and Processing of IPv6 Extension Headers [draft-ietf-6man-ext-transmit-05] (10 pages) - A Uniform Format for IPv6 Extension Headers [draft-ietf-6man-exthdr-06] (6 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-00] (11 pages) - IPv6 Hop-by-Hop Options Extension Header [draft-ietf-6man-hbh-header-handling-03] (10 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] (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) - 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 Subnet Model: The Relationship between Links and Subnet Prefixes [draft-ietf-6man-ipv6-subnet-model-12] (11 pages) - IPv6 Router Advertisement IPv6-Only Flag [draft-ietf-6man-ipv6only-flag-05] (15 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-02] (15 pages) - First-Hop Router Selection by Hosts in a Multi-Prefix Network [draft-ietf-6man-multi-homed-host-10] (13 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) - Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery [draft-ietf-6man-nd-extension-headers-05] (10 pages) - Validation of IPv6 Neighbor Discovery Options [draft-ietf-6man-nd-opt-validation-00] (15 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) - 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) - Update to RFC 3484 Default Address Selection for IPv6 [draft-ietf-6man-rfc3484-revise-05] (12 pages) - Default Address Selection for Internet Protocol Version 6 (IPv6) [draft-ietf-6man-rfc3484bis-06] (32 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-09] (22 pages) - IPv6 Node Requirements [draft-ietf-6man-rfc6434-bis-09] (42 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 Neighbor Discovery Optional RS/RA Refresh [draft-ietf-6man-rs-refresh-02] (13 pages) - IPv6 Segment Routing Header (SRH) [draft-ietf-6man-segment-routing-header-26] (27 pages) - Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6) [draft-ietf-6man-spring-srv6-oam-04] (20 pages) - A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) [draft-ietf-6man-stable-privacy-addresses-17] (19 pages) - A Recommendation for IPv6 Address Text Representation [draft-ietf-6man-text-addr-representation-07] (14 pages) - IPv6 and UDP Checksums for Tunneled Packets [draft-ietf-6man-udpchecksums-08] (12 pages) - Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums [draft-ietf-6man-udpzero-12] (40 pages) - Significance of IPv6 Interface Identifiers [draft-ietf-6man-ug-06] (10 pages) - Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers [draft-ietf-6man-uri-zoneid-06] (10 pages) - Analysis of the 64-bit Boundary in IPv6 Addressing [draft-ietf-6man-why64-08] (24 pages) - Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol [draft-ietf-ipv6-compression-nego-v2-02] (7 pages) - Centrally Assigned Unique Local IPv6 Unicast Addresses [draft-ietf-ipv6-ula-central-02] (11 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) - Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers [draft-linkova-6man-grand-01] (10 pages) - Discovering PREF64 in Router Advertisements [draft-pref64folks-6man-ra-pref64-02] (8 pages) - IPv6 Segment Routing Header (SRH) [draft-previdi-6man-segment-routing-header-08] (30 pages) - IPv6 ND PIO Flags IANA considerations [draft-troan-6man-ndpioiana-01] (4 pages) Requests for Comments: BCP220: IPv6 Node Requirements (42 pages) 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) RFC6554: An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL) (13 pages) RFC6564: A Uniform Format for IPv6 Extension Headers (6 pages) RFC6724: Default Address Selection for Internet Protocol Version 6 (IPv6) (32 pages) RFC6788: The Line-Identification Option (17 pages) RFC6874: Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers (10 pages) RFC6935: IPv6 and UDP Checksums for Tunneled Packets (12 pages) RFC6936: Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums (40 pages) RFC6946: Processing of IPv6 "Atomic" Fragments (9 pages) RFC6957: Duplicate Address Detection Proxy (16 pages) RFC6980: Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery (10 pages) RFC7045: Transmission and Processing of IPv6 Extension Headers (10 pages) RFC7048: Neighbor Unreachability Detection Is Too Impatient (8 pages) RFC7078: Distributing Address Selection Policy Using DHCPv6 (12 pages) RFC7112: Implications of Oversized IPv6 Header Chains (8 pages) RFC7136: Significance of IPv6 Interface Identifiers (10 pages) RFC7217: A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) (19 pages) RFC7346: IPv6 Multicast Address Scopes (6 pages) RFC7371: Updates to the IPv6 Multicast Addressing Architecture (10 pages) RFC7421: Analysis of the 64-bit Boundary in IPv6 Addressing (24 pages) RFC7527: Enhanced Duplicate Address Detection (11 pages) RFC7559: Packet-Loss Resiliency for Router Solicitations (6 pages) RFC7721: Security and Privacy Considerations for IPv6 Address Generation Mechanisms (18 pages) RFC7739: Security Implications of Predictable Fragment Identification Values (20 pages) RFC8021: Generation of IPv6 Atomic Fragments Considered Harmful (12 pages) RFC8028: First-Hop Router Selection by Hosts in a Multi-Prefix Network (13 pages) RFC8064: Recommendation on Stable IPv6 Interface Identifiers (9 pages) RFC8096: The IPv6-Specific MIB Modules Are Obsolete (65 pages) RFC8106: IPv6 Router Advertisement Options for DNS Configuration (19 pages) RFC8200: Internet Protocol, Version 6 (IPv6) Specification (42 pages) RFC8201: Path MTU Discovery for IP version 6 (19 pages) RFC8319: Support for Adjustable Maximum Router Lifetimes per Link (7 pages) RFC8425: IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags (4 pages) RFC8504: IPv6 Node Requirements (42 pages) RFC8754: IPv6 Segment Routing Header (SRH) (27 pages) RFC8781: Discovering PREF64 in Router Advertisements (10 pages) STD86: Internet Protocol, Version 6 (IPv6) Specification (42 pages) STD87: Path MTU Discovery for IP version 6 (19 pages) IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) -------------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Pascal Thubert Thomas Watteyne Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Erik Kline Mailing Lists: General Discussion: 6tisch@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/6tisch Archive: https://mailarchive.ietf.org/arch/browse/6tisch/ Description of Working Group: 6TiSCH: "IPv6 over the TSCH mode of IEEE 802.15.4e". Background/Introduction: ------------------------ Low-power and Lossy Networks (LLNs) interconnect a possibly large number of resource-constrained nodes to form a wireless mesh network. The 6LoWPAN, ROLL and CoRE IETF Working Groups have defined protocols at various layers of the protocol stack, including an IPv6 adaptation layer, a routing protocol and a web transfer protocol. This protocol stack has been used with IEEE802.15.4 low-power radios. The Timeslotted Channel Hopping (TSCH) mode was introduced in 2012 as an amendment to the Medium Access Control (MAC) portion of the IEEE802.15.4 standard. TSCH is the emerging standard for industrial automation and process control LLNs, with a direct inheritance from WirelessHART and ISA100.11a. Defining IPv6 over TSCH, 6TiSCH is a key to enable the further adoption of IPv6 in industrial standards and the convergence of Operational Technology (OT) with Information Technology (IT). The nodes in a IEEE802.15.4 TSCH network communicate by following a Time Division Multiple Access (TDMA) schedule. A timeslot in this schedule provides a unit of bandwidth that is allocated for communication between neighbor nodes. The allocation can be programmed such that the predictable transmission pattern matches the traffic. This avoids idle listening, and extends battery lifetime for constrained nodes. Channel-hopping improves reliability in the presence of narrow- band interference and multi-path fading. These techniques enable a new range of use cases for LLNs, including: - Control loops in a wireless process control network, in which high reliability and a fully deterministic behavior are required. - Service Provider networks transporting data from different independent clients, and for which an operator needs flow isolation and traffic shaping. - Networks comprising energy harvesting nodes, which require an extremely low and predictable average power consumption. IEEE802.15.4 only defines the link-layer mechanisms. It does not define how the network communication schedule is built and matched to the traffic requirements of the network. Description of Working Group: ----------------------------- The Working Group will focus on enabling IPv6 over the TSCH mode of the IEEE802.15.4 standard. The extent of the problem space for the WG is one or more LLNs, possibly federated through a common backbone link via one or more LLN Border Routers (LBRs). The WG will rely on, and if necessary extend, existing mechanisms for authenticating LBRs. Initially, the WG has limited its scope to distributed routing over a static schedule using the Routing Protocol for LLNs (RPL) on the resulting network. This new charter allows for the dynamic allocation of cells and their exchange between adjacent peers to accommodate the available bandwidth to the variations of throughput in IP traffic. The WG will continue working on securing the join process and making that fit within the constraints of high latency, low throughput and small frame sizes that characterize IEEE802.15.4 TSCH. Additionally, IEEE802.15.4 TSCH being a deterministic MAC, it is envisioned that 6TiSCH will benefit from the work of DetNet WG to establish the so-called deterministic tracks. The group will define the objects and methods that need to be configured, and provide the associated requirements to DetNet. The WG will interface with other appropriate groups in the IETF Internet, Operations and Management, Routing and Security areas. Work Items: ----------- The group will: - Produce a specification of the 6top sublayer that describes the protocol for neighbor nodes to negotiate adding/removing cells. This work will leverage cross participation from IEEE members including the IEEE 6TiSCH Interest Group (IG 6T) to define protocol elements and associated frame formats. - Produce a specification for a default 6top Scheduling Function including the policy to enable distributed dynamic scheduling of timeslots for IP traffic. This may include the capability for nodes to appropriate chunks of the matrix without starving, or interfering with other 6TiSCH nodes. This particular work will focus on IP traffic since the work on tracks is not yet advanced enough to specify their requirements. - Produce requirements to the DetNet WG, detailing 6TiSCH chunks and tracks, and the data models to manipulate them from an external controller such as a PCE. - Produce a specification for a secure 6TiSCH network bootstrap, adapted to the constraints of 6TiSCH nodes and leveraging existing art when possible. - Keep updating the "6TiSCH architecture" that describes the design of 6TiSCH networks. This document highlights the different architectural blocks, signaling and data flows, including the operation of the network in the presence of multiple LBRs. The existing document will be augmented to cover dynamic scheduling and application of the DetNet work but will not be delivered within this round of chartering. - Producing YANG Data Models to manage 6tisch is foreseen, but left to a later phase. Non-milestone work items: ------------------------- The Working Group regularly organizes interoperability events with support from ETSI (i.e., ETSI 6TiSCH Plugtests) to get feedback from implementers early on in the standardization process, and produce better standards. Goals and Milestones: Oct 2018 - Initial submission of draft-ietf-6tisch-dtsecurity-zerotouch-join to the IESG Dec 2018 - Evaluate WG progress, propose new charter to the IESG Done - Second submission of draft-ietf-6tisch-minimal to the IESG Done - WG call to adopt draft-ietf-6tisch-6top-sf0 Done - WG call to adopt draft-ietf-6tisch-6top-sublayer Done - ETSI 6TiSCH #3 plugtests Done - Initial submission of draft-ietf-6tisch-6top-protocol to the IESG Done - Initial submission of draft-ietf-6tisch-minimal-security to the IESG Done - Initial submission of 6TiSCH architecture to the IESG Done - 6TiSCH architecture and terminology in RFC publication queue Internet-Drafts: - 6TiSCH Minimal Scheduling Function (MSF) [draft-chang-6tisch-msf-02] (19 pages) - 6TiSCH Operation Sublayer (6top) Interface [draft-ietf-6tisch-6top-interface-04] (34 pages) - 6TiSCH Operation Sublayer (6top) Protocol (6P) [draft-ietf-6tisch-6top-protocol-12] (50 pages) - 6TiSCH 6top Scheduling Function Zero (SF0) [draft-ietf-6tisch-6top-sf0-05] (14 pages) - 6TiSCH Experimental Scheduling Function (SFX) [draft-ietf-6tisch-6top-sfx-01] (12 pages) - An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4 [draft-ietf-6tisch-architecture-28] (69 pages) - 6TiSCH Resource Management and Interaction using CoAP [draft-ietf-6tisch-coap-03] (16 pages) - 6tisch Secure Join protocol [draft-ietf-6tisch-dtsecurity-secure-join-01] (16 pages) - 6tisch Zero-Touch Secure Join protocol [draft-ietf-6tisch-dtsecurity-zerotouch-join-04] (27 pages) - IEEE 802.15.4 Information Element encapsulation of 6TiSCH Join and Enrollment Information [draft-ietf-6tisch-enrollment-enhanced-beacon-14] (11 pages) - Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration [draft-ietf-6tisch-minimal-21] (28 pages) - Constrained Join Protocol (CoJP) for 6TiSCH [draft-ietf-6tisch-minimal-security-15] (53 pages) - 6TiSCH Minimal Scheduling Function (MSF) [draft-ietf-6tisch-msf-16] (22 pages) - Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e [draft-ietf-6tisch-terminology-10] (9 pages) - Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement [draft-ietf-6tisch-tsch-06] (23 pages) - IEEE802.15.4 Informational Element encapsulation of 6tisch Join and Enrollment Information [draft-richardson-6tisch-enrollment-enhanced-beacon-01] (8 pages) - Enabling secure network enrollment in RPL networks [draft-richardson-6tisch-roll-enrollment-priority-03] (6 pages) - 6TiSCH Resource Management and Interaction using CoAP [draft-sudhaakar-6tisch-coap-01] (14 pages) Requests for Comments: BCP210: Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration (28 pages) RFC7554: Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement (23 pages) RFC8180: Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration (28 pages) RFC8480: 6TiSCH Operation Sublayer (6top) Protocol (6P) (50 pages) Authentication and Authorization for Constrained Environments (ace) ------------------------------------------------------------------- Charter Last Modified: 2019-03-28 Current Status: Active Chairs: Daniel Migault Jim Schaad Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Benjamin Kaduk 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 IETF has recently developed protocols for use in constrained environments, where network nodes are limited in CPU, memory and power. REST architecture is widely used for such constrained environments. It has been observed that Internet protocols can be applied to these constrained environments, often only requiring minor tweaking and profiling. In other cases, new protocols have been defined to address the specific requirements of constrained environments. An example of such a protocol is the Constrained Application Protocol (CoAP). As in other environments, authentication and authorization questions also arise in constrained environments. For example, a door lock has to authorize the person seeking access using a "digital key". Where is the authorization policy stored? How does the digital key communicate with the lock? Does the lock interact with an authorization server to obtain authorization information? How can access be temporarily granted to other persons? How can access be revoked? These types of questions have been answered by existing protocols for use cases outside constrained environments, however in constrained environments, additional and different requirements pose challenges for the use of various security protocols. In particular, the need arises for a dynamic and fine grained access control mechanism, where clients and/or resource servers are constrained. The IETF has a long history in developing three-party authentication and authorization protocols for distributed environments. Examples include Kerberos, the Public Key Infrastructure (PKI), the Authentication, Authorization and Accounting (AAA) infrastructure, and the Web Authorization Protocol (OAuth). All these protocols enjoy widespread deployment on the Internet. Although they all aim to solve a similar goal, at an abstract level, they offer quite different functions and utilize different message exchanges. These differences result from the main deployment use cases they were designed for respectively. Requirements derived from use cases may indicate that existing work is useful as basis for a solution for constrained environments. These protocols, however, were not optimized for constrained environments. Additional requirements that need to be taken into account are the lack of a suitable user-interface and the inability of embedded devices to contact an authorization server in real-time with every resource access request due to intermittent connectivity, etc. This working group therefore aims to produce a standardized solution for authentication and authorization to enable authorized access (Get, Put, Post, Delete) to resources identified by a URI and hosted on a resource server in constrained environments. As a starting point, the working group will assume that access to resources at a resource server by a client device takes place using CoAP and is protected by DTLS. Both resource server and client may be constrained. This access will be mediated by an authorization server, which is not considered to be constrained. Existing authentication and authorization protocols will be evaluated and used where applicable to build the constrained-environment solution. This requires relevant specifications to be reviewed for suitability, selecting a subset of them and restricting the options within each of the specifications. Some functionality, however, may not be available in existing protocols, in which case the solution may also involve new protocol work. Leveraging existing work means the working group benefits from available security analysis, implementation, and deployment experience. Moreover, a standardized solution for federated authentication and authorization will help to stimulate the deployment of constrained devices that provide increased security. Once progress in identifying suitable candidate solutions has been made, the working group will verify whether the same mechanisms are also applicable beyond the use of CoAP and DTLS, which are the two main protocols the group will focus on for access to resources. In particular, the ability to use the developed solution over HTTP and TLS will be investigated. Note that the initial focus is on CoAP and HTTP with DTLS and TLS. Other security protocols may be considered as long as the primary focus is maintained. The group is scoped to work only on the web protocols and data carried within them. Furthermore, to guarantee smooth transition, the integration with existing deployments will be studied, particularly concerning the use of protocol translation proxies. This work does not make the assumption that the party offering application layer services is always the same party offering network access services. ACE will need to interact with CORE and LWIG to ensure coordination. The working group has the following tasks: 1) Produce use cases and requirements 2) Identify authentication and authorization mechanisms suitable for resource access in constrained environments. Goals and Milestones: Nov 2018 - Submit DTLS Profile for ACE to the IESG for publication as a proposed standard Done - Submit "Use cases and Requirements" as a WG item. Done - Submit "An Architecture for Authorization in Constrained Environments" as a WG item. Done - Optionally, submit "Use cases and Requirements" document to the IESG for publication as an Informational RFC. Done - Submit "Authentication and Authorization for ACE" specification as a WG item. Done - Submit CBOR Web Token draft to the IESG for publication Done - WGLC on CWT Proof of possession Done - Submit CWT Proof of Possession to IESG for publication as proposed standard Done - WGLC for OAuth Authentication and Authorization Solution draft Done - WGLC for DTLS Profile for ACE Done - WGLC on OSCORE Profile for ACE Done - Submit "Authentication and Authorization Solution" specification to the IESG for publication as a Proposed Standard. Done - Submit ACE profile for OSCORE to the IESG for publication as a Proposed Standard Internet-Drafts: - An architecture for authorization in constrained environments [draft-ietf-ace-actors-07] (31 pages) - CBOR Web Token (CWT) [draft-ietf-ace-cbor-web-token-15] (25 pages) - EST over secure CoAP (EST-coaps) [draft-ietf-ace-coap-est-18] (51 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-10] (26 pages) - Key Provisioning for Group Communication using ACE [draft-ietf-ace-key-groupcomm-06] (57 pages) - Key Management for OSCORE Groups in ACE [draft-ietf-ace-key-groupcomm-oscore-06] (40 pages) - MQTT-TLS profile of ACE [draft-ietf-ace-mqtt-tls-profile-04] (28 pages) - Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) [draft-ietf-ace-oauth-authz-33] (87 pages) - Additional OAuth Parameters for Authorization in Constrained Environments (ACE) [draft-ietf-ace-oauth-params-13] (11 pages) - OSCORE profile of the Authentication and Authorization for Constrained Environments Framework [draft-ietf-ace-oscore-profile-10] (30 pages) - Pub-Sub Profile for Authentication and Authorization for Constrained Environments (ACE) [draft-ietf-ace-pubsub-profile-00] (19 pages) - Use Cases for Authentication and Authorization in Constrained Environments [draft-ietf-ace-usecases-10] (30 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) - 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) Automated Certificate Management Environment (acme) --------------------------------------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Rich Salz Yoav Nir Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Roman Danyliw 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 2020 - TNAuthlist submitted to IESG Apr 2020 - SMIME submitted to IESG Done - Initial working group draft Done - Submit working group draft to IESG as Proposed Standard Internet-Drafts: - Automatic Certificate Management Environment (ACME) [draft-ietf-acme-acme-18] (95 pages) - ACME Challenges Using an Authority Token [draft-ietf-acme-authority-token-05] (12 pages) - TNAuthList profile of ACME Authority Token [draft-ietf-acme-authority-token-tnauthlist-06] (14 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-00] (14 pages) - Extensions to Automatic Certificate Management Environment for end user S/MIME certificates [draft-ietf-acme-email-smime-07] (10 pages) - Extensions to Automatic Certificate Management Environment for email TLS [draft-ietf-acme-email-tls-05] (8 pages) - ACME Integrations [draft-ietf-acme-integrations-00] (18 pages) - Automated Certificate Management Environment (ACME) IP Identifier Validation Extension [draft-ietf-acme-ip-08] (5 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 ACME Profile for Generating Delegated STAR Certificates [draft-ietf-acme-star-delegation-03] (26 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) 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) Adaptive DNS Discovery (add) ---------------------------- Charter Last Modified: 2020-02-21 Current Status: Active Chairs: David C Lawrence Glenn Deen Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Barry Leiba 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: No Requests for Comments Application-Layer Traffic Optimization (alto) --------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Jan Seedorf Vijay K. Gurbani Transport Area Directors: Martin Duke Magnus Westerlund Transport Area Advisor: Martin Duke Mailing Lists: General Discussion: alto@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/alto Archive: https://mailarchive.ietf.org/arch/browse/alto/ Description of Working Group: The ALTO working group was established in 2008 to devise a request/response protocol for allowing a host to benefit from a server that is more cognizant of the network infrastructure than the host would be. The working group has developed an HTTP-based protocol to allow hosts to benefit from the network infrastructure by having access to a pair of maps: a topology map and a cost map. The origins of the ALTO protocol lie in peer-to-peer (P2P) applications, where the host is a peer in a P2P network and desires a rendezvous with other peers for file sharing, real-time communications, etc. ALTO is now being considered as a solution for problems outside the P2P domain, such as in datacenter networks and in content distribution networks (CDN) where exposing abstract topologies helps applications. To support the emerging new uses of ALTO, certain extensions are being sought. These extensions can be classified as follows: o Protocol extensions for reducing the volume of on-the-wire data exchange required to align the ALTO server and clients. Extensions under consideration are mechanisms for delivering server-initiated notifications and partial updates of maps. Efforts developed in other working groups such as Websockets and JSON-patch will be considered, as well as bespoke mechanisms specific to the ALTO protocol. o One or more alternatives to the base ALTO server discovery mechanism (RFC-to-be) to accommodate environments where (1) timely deployment of existing mechanisms, including the base ALTO server discovery mechanism, is unlikely, and/or (2) it is desirable for an ALTO client to be able to discover an ALTO server outside its own domain. The WG will consider mechanisms that are in use or defined by other WGs. If such discovery mechanisms can be reused, the WG will produce one or more documents to specify how they may be adopted as additional or alternative ALTO server discovery mechanisms. In the absence of such existing work, the WG will develop one or more ALTO-specific server discovery mechanisms. However, developing a general-purpose service discovery mechanism is not in scope. o Protocol extensions to convey a richer set of attributes to allow applications to determine not only "where" to connect but also "when" to connect. Such additional information will be related both to endpoints (e.g. conveying server load and cache geo-location information for CDN use cases) and to endpoint-to-endpoint costs (e.g. bandwidth calendaring to represent time-averaged cost values in datacenter networks). The working group will specify such extension in coordination with other working groups that have a focus on the related use cases. The scope of extensions is not limited to those identified by the WGs, but is limited by the criteria set out below. o A document specifying how a graph representation format (originating, say, from a YANG data model) can be used in ALTO and optionally be exported by an ALTO server in addition to network and cost maps. The graph representation will be based on existing ALTO abstraction (e.g., PIDs) and complement existing path-based ALTO cost map representation. Together, they provide a more complete, potentially more compact, but still abstract representation of networks for informed traffic optimization among endpoints. In settings with multiple application source- destination pairs with shared links, such a representation will help avoid bottleneck (or failed) links. The WG will not consider, nor will it model, topology internals not affecting endpoints (e.g., routing protocol internals or RIB data). When the WG considers standardizing information that the ALTO server could provide, the following criteria are important to ensure real feasibility: - Can the ALTO service realistically discover that information? - Is the distribution of that information allowed by the operators of that service? - Can a client get that information without excessive privacy and information leakage concerns? Extensions defining new endpoint properties should focus on exposing attributes of endpoints that are related to the goals of ALTO -- optimization of application-layer traffic -- as opposed to more general properties of endpoints. privacy and information leakage aspects of new endpoint properties will in any case be evaluated to the guidelines provided in the IANA considerations and Security Considerations of the ALTO protocol specification (RFC-to-be, sections 14.3 and 15.4 at IESG review time). - Is it information that a client cannot find easily some other way? After these criteria are met, the importance of the data will be considered for prioritizing standardization work, for example the number of operators and clients that are likely to be able to provide or use that particular data. In any case, this WG will not propose standards on how congestion is signaled, remediated, or avoided, and will not deal with information representing instantaneous network state. Issues related to the specific content exchanged in systems that make use of ALTO are also excluded from the WG's scope, as is the issue dealing with enforcing the legality of the content. Goals and Milestones: Jul 2020 - Submit network graph format document Jul 2020 - Submit endpoint property extension document Jul 2020 - Submit cost property extension document Jul 2020 - Submit alto service for CDNI FCI objects Nov 2020 - Recharter or dissolve working group Done - Submit deployment considerations document to IESG as Informational Done - Submit partial updates document Done - Submit server-initiated notifications document Done - Submit alternative server discovery document Internet-Drafts: - Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO [draft-ietf-alto-cdni-request-routing-alto-11] (39 pages) - Application-Layer Traffic Optimization (ALTO) Cost Calendar [draft-ietf-alto-cost-calendar-21] (35 pages) - Application-Layer Traffic Optimization (ALTO) Deployment Considerations [draft-ietf-alto-deployments-16] (77 pages) - ALTO Incremental Updates Using Server-Sent Events (SSE) [draft-ietf-alto-incr-update-sse-22] (58 pages) - Multi-Cost Application-Layer Traffic Optimization (ALTO) [draft-ietf-alto-multi-cost-10] (29 pages) - ALTO Extension: Path Vector [draft-ietf-alto-path-vector-10] (37 pages) - ALTO Performance Cost Metrics [draft-ietf-alto-performance-metrics-10] (30 pages) - Application-Layer Traffic Optimization (ALTO) Problem Statement [draft-ietf-alto-problem-statement-04] (14 pages) - Application-Layer Traffic Optimization (ALTO) Protocol [draft-ietf-alto-protocol-27] (91 pages) - Application-Layer Traffic Optimization (ALTO) Requirements [draft-ietf-alto-reqs-16] (20 pages) - Application-Layer Traffic Optimization (ALTO) Server Discovery [draft-ietf-alto-server-discovery-10] (15 pages) - Unified Properties for the ALTO Protocol [draft-ietf-alto-unified-props-new-11] (50 pages) - Application-Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery [draft-ietf-alto-xdom-disc-06] (34 pages) Requests for Comments: RFC5693: Application-Layer Traffic Optimization (ALTO) Problem Statement (14 pages) RFC6708: Application-Layer Traffic Optimization (ALTO) Requirements (20 pages) RFC7285: Application-Layer Traffic Optimization (ALTO) Protocol (91 pages) RFC7286: Application-Layer Traffic Optimization (ALTO) Server Discovery (15 pages) RFC7971: Application-Layer Traffic Optimization (ALTO) Deployment Considerations (77 pages) RFC8189: Multi-Cost Application-Layer Traffic Optimization (ALTO) (29 pages) RFC8686: Application-Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery (34 pages) Autonomic Networking Integrated Model and Approach (anima) ---------------------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Sheng Jiang Toerless Eckert Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Robert Wilton Tech Advisor: Nancy Cam-Winget 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: - An Autonomic Control Plane (ACP) [draft-ietf-anima-autonomic-control-plane-24] (150 pages) - Bootstrapping Remote Secure Key Infrastructures (BRSKI) [draft-ietf-anima-bootstrapping-keyinfra-41] (122 pages) - Constrained Voucher Artifacts for Bootstrapping Protocols [draft-ietf-anima-constrained-voucher-07] (40 pages) - A Generic Autonomic Signaling Protocol (GRASP) [draft-ietf-anima-grasp-15] (81 pages) - Generic Autonomic Signaling Protocol Application Program Interface (GRASP API) [draft-ietf-anima-grasp-api-05] (29 pages) - Information Distribution over GRASP [draft-ietf-anima-grasp-distribution-00] (22 pages) - Autonomic IPv6 Edge Prefix Management in Large-scale Networks [draft-ietf-anima-prefix-management-07] (22 pages) - A Reference Model for Autonomic Networking [draft-ietf-anima-reference-model-10] (30 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) - 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) Audio/Video Transport Core Maintenance (avtcore) ------------------------------------------------ Charter Last Modified: 2019-12-19 Current Status: Active Chairs: Jonathan Lennox Roni Even Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba 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: Mar 2019 - Submit RTP Payload Format for the TETRA Audio Codec 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 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: - 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) - Explicit Congestion Notification (ECN) for RTP over UDP [draft-ietf-avt-ecn-for-rtp-03] (44 pages) - Forward-Shifted RTP Redundancy Payload Support [draft-ietf-avt-forward-shifted-red-08] (13 pages) - Port Mapping Between Unicast and Multicast RTP Sessions [draft-ietf-avt-ports-for-ucast-mcast-rtp-11] (35 pages) - AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) [draft-ietf-avt-srtp-aes-gcm-02] (19 pages) - Encrypted Key Transport for Secure RTP [draft-ietf-avt-srtp-ekt-03] (53 pages) - Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution [draft-ietf-avt-srtp-not-mandatory-16] (10 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-06] (15 pages) - RTP Clock Source Signalling [draft-ietf-avtcore-clksrc-11] (30 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) - 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] (16 pages) - RTP-mixer formatting of multi-party Real-time text [draft-ietf-avtcore-multi-party-rtt-mix-01] (31 pages) - Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams [draft-ietf-avtcore-multiplex-guidelines-11] (43 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) - Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions [draft-ietf-avtcore-rtp-circuit-breakers-18] (25 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 RTCP Reception Statistics and Other Feedback [draft-ietf-avtcore-rtp-multi-stream-optimisation-12] (18 pages) - Options for Securing RTP Sessions [draft-ietf-avtcore-rtp-security-options-10] (37 pages) - RTP Topologies [draft-ietf-avtcore-rtp-topologies-update-10] (48 pages) - RTP Payload Format for Versatile Video Coding (VVC) [draft-ietf-avtcore-rtp-vvc-01] (39 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) - Frame Marking RTP Header Extension [draft-ietf-avtext-framemarking-10] (13 pages) - RTP Payload Format for ISO/IEC 21122 (JPEG XS) [draft-ietf-payload-rtp-jpegxs-03] (23 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 TSVCIS Codec [draft-ietf-payload-tsvcis-05] (20 pages) - RTP Payload Format for VP9 Video [draft-ietf-payload-vp9-09] (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) 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) 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) Babel routing protocol (babel) ------------------------------ Charter Last Modified: 2018-03-21 Current Status: Active Chairs: Donald E. Eastlake 3rd Russ White Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Martin Vigoureux 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: Jun 2019 - IESG Submission of Babel Management draft (Proposed Standard) Done - WG adoption of Babel Applicability draft Done - WG adoption of RFC6126bis 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) 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] (11 pages) - Babel Routing Protocol over Datagram Transport Layer Security [draft-ietf-babel-dtls-09] (10 pages) - MAC authentication for the Babel routing protocol [draft-ietf-babel-hmac-10] (21 pages) - Babel Information Model [draft-ietf-babel-information-model-10] (21 pages) - The Babel Routing Protocol [draft-ietf-babel-rfc6126bis-17] (69 pages) - Delay-based Metric Extension for the Babel Routing Protocol [draft-ietf-babel-rtt-extension-00] (9 pages) - Source-Specific Routing in Babel [draft-ietf-babel-source-specific-05] (11 pages) - YANG Data Model for Babel [draft-ietf-babel-yang-model-05] (38 pages) - Babel HMAC Cryptographic Authentication [draft-ovsienko-babel-rfc7298bis-00] (55 pages) No Requests for Comments BGP Enabled ServiceS (bess) --------------------------- Charter Last Modified: 2019-08-20 Current Status: Active Chairs: Matthew Bocci Stephane Litkowski Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Martin Vigoureux 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 RFC4364 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 L2VPN to IESG as PS Dec 2020 - Submit a YANG datamodel for mVPN 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 of a multicast VPN MIB to IESG as PS Done - Submit specification for the use of E-VPN for datacenter overlays 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) - 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-01] (23 pages) - Controller Based BGP Multicast Signaling [draft-ietf-bess-bgp-multicast-controller-00] (12 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 Segment Routing Enabled Domain Interconnection [draft-ietf-bess-datacenter-gateway-05] (12 pages) - Interconnect Solution for EVPN Overlay networks [draft-ietf-bess-dci-evpn-overlay-10] (29 pages) - Requirements for Extending BGP/MPLS VPNs to End-Systems [draft-ietf-bess-end-system-requirements-00] (16 pages) - AC-Influenced Designated Forwarder Election for EVPN [draft-ietf-bess-evpn-ac-df-03] (10 pages) - Fault Management for EVPN networks [draft-ietf-bess-evpn-bfd-00] (20 pages) - Updates on EVPN BUM Procedures [draft-ietf-bess-evpn-bum-procedure-updates-08] (19 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) - 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 DF Election [draft-ietf-bess-evpn-fast-df-recovery-01] (19 pages) - EVPN control plane for Geneve [draft-ietf-bess-evpn-geneve-00] (10 pages) - IGMP and MLD Proxy for EVPN [draft-ietf-bess-evpn-igmp-mld-proxy-05] (33 pages) - Integrated Routing and Bridging in EVPN [draft-ietf-bess-evpn-inter-subnet-forwarding-08] (33 pages) - EVPN Interworking with IPVPN [draft-ietf-bess-evpn-ipvpn-interworking-02] (24 pages) - Extended Mobility Procedures for EVPN-IRB [draft-ietf-bess-evpn-irb-extended-mobility-03] (25 pages) - EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding [draft-ietf-bess-evpn-irb-mcast-04] (77 pages) - LSP-Ping Mechanisms for EVPN and PBB-EVPN [draft-ietf-bess-evpn-lsp-ping-01] (15 pages) - EVPN multi-homing port-active load-balancing [draft-ietf-bess-evpn-mh-pa-00] (11 pages) - Seamless Multicast Interoperability between EVPN and MVPN PEs [draft-ietf-bess-evpn-mvpn-seamless-interop-00] (36 pages) - Propagation of ARP/ND Flags in EVPN [draft-ietf-bess-evpn-na-flags-04] (8 pages) - EVPN Operations, Administration and Maintenance Requirements and Framework [draft-ietf-bess-evpn-oam-req-frmwk-02] (19 pages) - Optimized Ingress Replication solution for EVPN [draft-ietf-bess-evpn-optimized-ir-06] (26 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-02] (12 pages) - Preference-based EVPN DF Election [draft-ietf-bess-evpn-pref-df-05] (15 pages) - IP Prefix Advertisement in EVPN [draft-ietf-bess-evpn-prefix-advertisement-11] (36 pages) - Operational Aspects of Proxy-ARP/ND in EVPN Networks [draft-ietf-bess-evpn-proxy-arp-nd-08] (23 pages) - Weighted Multi-Path Procedures for EVPN All-Active Multi-Homing [draft-ietf-bess-evpn-unequal-lb-04] (18 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-06] (22 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-01] (16 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-00] (13 pages) - Extensions to BGP-Signaled Pseudowires to Support Flow-Aware Transport Labels [draft-ietf-bess-fat-pw-bgp-04] (9 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-04] (23 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-03] (14 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-10] (21 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) - MVPN and MSDP SA Interoperation [draft-ietf-bess-mvpn-msdp-sa-interoperation-04] (7 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-02] (39 pages) - BGP Control Plane for NSH SFC [draft-ietf-bess-nsh-bgp-control-plane-13] (59 pages) - Covering Prefixes Outbound Route Filter for BGP-4 [draft-ietf-bess-orf-covering-prefixes-06] (21 pages) - PBB-EVPN ISID-based CMAC-Flush [draft-ietf-bess-pbb-evpn-isid-cmacflush-00] (10 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 with an IPv6 Next Hop [draft-ietf-bess-rfc5549revision-03] (13 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) - SRv6 BGP based Overlay services [draft-ietf-bess-srv6-services-02] (27 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) - 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 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) - 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) - 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-01] (24 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 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) Binary Floor Control Protocol Bis (bfcpbis) ------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Charles Eckel Keith Drage Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: bfcpbis@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/bfcpbis Archive: https://mailarchive.ietf.org/arch/browse/bfcpbis/ Description of Working Group: The BFCPBIS working group is chartered to specify a revision of BFCP (RFC 4582) to support using both TCP and UDP as transports. The current version of BFCP only supports TCP, which when both endpoints are behind NATs or firewalls, has a lower success rate than using the ICE techniques with a UDP based transport for BFCP. The need for video endpoints to work in these types of environments is driving a strong need to support a UDP based transport as well as TCP. This WG will create a revision of RFC 4582 which adds optional support for UDP to BFCP. The security when using UDP will be based on DTLS. The updated protocol will use an existing approach (e.g., stop and wait with a single outstanding transaction) to provide a reliable, congestion safe, and TCP friendly transport. In addition to providing a way for dealing with the reliable delivery of client-initiated transactions, the updated protocol will also be able to deliver server-initiated transactions reliably when needed. The WG will research the size of messages used and decide if fragmenting a request or response over multiple UDP packets is required. The new protocol will be backwards compatible with RFC 4582 when used in TCP mode. The BFCPBIS WG will coordinate closely with the MMUSIC WG to create a revision of RFC 4583 specifying how BFCP is signaled in SDP so that it supports UDP as well as TCP transports. This WG would ask the MMUSIC WG to add a milestone to create a revisions of RFC 4583 to address signaling the use of UDP in SDP. The WG will coordinate with International Multimedia Telecommunications Consortium (IMTC) and other industry fora. Goals and Milestones: Done - Draft revision of RFC 4582 to IESG as Proposed Standard Done - Draft revision of RFC 4583 to IESG as Proposed Standard Done - Draft for BFCP over WebSocket to IESG as Proposed Standard Done - Draft for SDP WebSocket Connection URI Attribute to IESG as Proposed Standard C Internet-Drafts: - The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP) [draft-ietf-bfcpbis-bfcp-websocket-15] (14 pages) - The Binary Floor Control Protocol (BFCP) [draft-ietf-bfcpbis-rfc4582bis-16] (90 pages) - Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams [draft-ietf-bfcpbis-rfc4583bis-27] (25 pages) - The Session Description Protocol (SDP) WebSocket Connection URI Attribute [draft-ietf-bfcpbis-sdp-ws-uri-09] (12 pages) Requests for Comments: RFC8124: The Session Description Protocol (SDP) WebSocket Connection URI Attribute (12 pages) Bidirectional Forwarding Detection (bfd) ---------------------------------------- Charter Last Modified: 2018-03-21 Current Status: Active Chairs: Jeffrey Haas Reshad Rahman Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Martin Vigoureux Tech Advisors: Dave Katz David Ward Mailing Lists: General Discussion: rtg-bfd@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/rtg-bfd Archive: https://mailarchive.ietf.org/arch/browse/rtg-bfd/ Description of Working Group: The BFD Working Group is chartered to standardize and support the bidirectional forwarding detection protocol (BFD) and its extensions. A core goal of the working group is to standardize BFD in the context of IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations. The Working Group will also provide advice and guidance on BFD to other working groups or standards bodies as requested. BFD is a protocol intended to detect faults in the bidirectional path between two forwarding engines, including physical interfaces, subinterfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of detection times and overhead, to avoid a proliferation of different methods. Important characteristics of BFD include: - Simple, fixed-field encoding to facilitate implementations in hardware. - Independence of the data protocol being forwarded between two systems. BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network. - Path independence: BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS LSPs, multihop routed paths, and unidirectional links (so long as there is some return path, of course). - Ability to be bootstrapped by any other protocol that automatically forms peer, neighbor or adjacency relationships to seed BFD endpoint discovery. The working group is currently chartered to complete the following work items: 1. Develop further MIB modules for BFD and submit them to the IESG for publication as Proposed Standards. 2a. Provide a generic keying-based cryptographic authentication mechanism for the BFD protocol developing the work of the KARP working group. This mechanism will support authentication through a key identifier for the BFD session's Security Association rather than specifying new authentication extensions. 2b. Provide extensions to the BFD MIB in support of the generic keying- based cryptographic authentication mechanism. 2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check value but not beyond commonly accepted lengths to ensure security) using the generic keying-based cryptographic authentication mechanism. 3. Provide an extension to the BFD core protocol in support of point-to- multipoint links and networks. 4. Provide an informational document to recommend standardized timers and timer operations for BFD when used in different applications. 5. Define a mechanism to perform single-ended path (i.e. continuity) verification based on the BFD specification. Allow such a mechanism to work both proactively and on-demand, without prominent initial delay. Allow the mechanism to maintain multiple sessions to a target entity and between the same pair of network entities. In doing this work, the WG will work closely with at least the following other WGs: ISIS, OSPF, SPRING. The working group will maintain a relationship with the MPLS working group. Goals and Milestones: Jan 2015 - Submit the generic keying based cryptographic authentication mechanism to the IESG to be considered as a Proposed Standard Jan 2015 - Submit the cryptographic authentication procedures for BFD to the IESG to be considered as a Proposed Standard Dec 2018 - Submit BFD for VxLAN to the IESG to be considered as a Proposed Standard Done - Submit the base protocol specification to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for single-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for MPLS LSPs to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for multi-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Done - Submit the BFD MIB to the IESG to be considered as a Proposed Standard Done - Submit the BFD over LAG mechanism to the IESG to be considered as a Proposed Standard Done - Submit the BFD Seamless Use Case document to the IESG to be considered as a Proposed Standard Done - Submit the BFD Common Intervals document to the IESG to be considered as an Informational RFC Done - Submit the BFD Seamless Base draft to the IESG to be considered as a Proposed Standard Done - Submit the BFD Seamless IP draft to the IESG to be considered as a Proposed Standard Done - Submit the the document on BFD point-to-multipoint support to the IESG to be considered as a Proposed Standard Done - Submit a BFD Yang module to the IESG to be considered as a Proposed Standard Internet-Drafts: - BFD Stability [draft-ashesh-bfd-stability-05] (6 pages) - Unsolicited BFD for Sessionless Applications [draft-chen-bfd-unsolicited-03] (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-02] (7 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-09] (7 pages) - Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs) [draft-ietf-bfd-rfc5884-clarifications-04] (7 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) - Secure BFD Sequence Numbers [draft-ietf-bfd-secure-sequence-numbers-05] (6 pages) - BFD Stability [draft-ietf-bfd-stability-05] (5 pages) - Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management [draft-ietf-bfd-tc-mib-08] (11 pages) - Unsolicited BFD for Sessionless Applications [draft-ietf-bfd-unsolicited-01] (13 pages) - Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) [draft-ietf-bfd-v4v6-1hop-11] (7 pages) - BFD for VXLAN [draft-ietf-bfd-vxlan-11] (11 pages) - YANG Data Model for Bidirectional Forwarding Detection (BFD) [draft-ietf-bfd-yang-17] (79 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 Point-to-Point MPLS LSP [draft-mirsky-bfd-mpls-demand-06] (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) Bit Indexed Explicit Replication (bier) --------------------------------------- Charter Last Modified: 2020-03-20 Current Status: Active Chairs: Greg Shepherd Tony Przygienda Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Alvaro Retana 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 Mar 2018 - IETF 101 discuss and target mechanisms for BIER transition 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) - Multicast Using Bit Index Explicit Replication (BIER) [draft-ietf-bier-architecture-08] (43 pages) - BIER Underlay Path Calculation Algorithm and Constraints [draft-ietf-bier-bar-ipa-06] (6 pages) - BGP Link-State extensions for BIER [draft-ietf-bier-bgp-ls-bier-ext-06] (10 pages) - YANG Data Model for BIER Protocol [draft-ietf-bier-bier-yang-06] (17 pages) - Use of BIER Entropy for Data Center Clos Networks [draft-ietf-bier-entropy-staged-dc-clos-03] (9 pages) - EVPN BUM Using BIER [draft-ietf-bier-evpn-03] (14 pages) - BGP Extensions for BIER [draft-ietf-bier-idr-extensions-07] (7 pages) - BIER IPv6 Requirements [draft-ietf-bier-ipv6-requirements-04] (14 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-01] (13 pages) - BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery Protocols [draft-ietf-bier-mld-04] (16 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) - Applicability of BIER Multicast Overlay for Adaptive Streaming Services [draft-ietf-bier-multicast-http-response-03] (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-02] (6 pages) - Operations, Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer [draft-ietf-bier-oam-requirements-09] (6 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-01] (10 pages) - Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Replication (BIER) Layer [draft-ietf-bier-path-mtu-discovery-07] (8 pages) - BIER Penultimate Hop Popping [draft-ietf-bier-php-04] (7 pages) - PIM Signaling Through BIER Core [draft-ietf-bier-pim-signaling-08] (15 pages) - BIER Ping and Trace [draft-ietf-bier-ping-07] (25 pages) - Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer [draft-ietf-bier-pmmm-oam-07] (9 pages) - Bit Indexed Explicit Replication (BIER) Problem Statement [draft-ietf-bier-problem-statement-00] (13 pages) - Tree Engineering for Bit Index Explicit Replication (BIER-TE) [draft-ietf-bier-te-arch-07] (45 pages) - A YANG data model for Traffic Engineering for Bit Index Explicit Replication (BIER-TE) [draft-ietf-bier-te-yang-01] (17 pages) - BIER Use Cases [draft-ietf-bier-use-cases-11] (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) 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) RFC8444: OSPFv2 Extensions for Bit Index Explicit Replication (BIER) (12 pages) RFC8556: Multicast VPN Using Bit Index Explicit Replication (BIER) (17 pages) Benchmarking Methodology (bmwg) ------------------------------- Charter Last Modified: 2017-10-03 Current Status: Active Chairs: Al Morton Sarah Banks Operations and Management Area Directors: Warren Kumari Robert Wilton 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: Aug 2019 - Methodology for Next-Gen Firewall Benchmarking to IESG Review Dec 2019 - Update to RFC2544 Back-to-back Frame Benchmarking to IESG Review Dec 2019 - Methodology for EVPN Benchmarking to IESG Review Dec 2019 - Draft on Selecting and Applying Model(s) for Benchmarking to IESG Review Dec 2019 - Draft on General VNF Benchmarking Automation to IESG Review Dec 2019 - Considerations for Benchmarking Network Virtualization Platforms to IESG Review Internet-Drafts: - 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-01] (13 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) - Basic BGP Convergence Benchmarking Methodology for Data-Plane Convergence [draft-ietf-bmwg-bgp-basic-convergence-05] (35 pages) - Benchmarking Methodology for Basic BGP Convergence [draft-ietf-bmwg-bgpbas-01] (16 pages) - Benchmarking Methodology for Content-Aware Network Devices [draft-ietf-bmwg-ca-bench-meth-04] (19 pages) - Terminology for Cell/Call Benchmarking [draft-ietf-bmwg-call-04] (29 pages) - Terminology for Benchmarking BGP Device Convergence in the Control Plane [draft-ietf-bmwg-conterm-06] (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-05] (28 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) - 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) - Benchmarking Methodology for Network Security Device Performance [draft-ietf-bmwg-ngfw-performance-03] (58 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 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) 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) 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) Calendaring Extensions (calext) ------------------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Bron Gondwana Daniel Migault Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba 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 Calendaring Extensions working group is chartered to develop extensions to the iCalendar (RFC 5545), iTIP (RFC 5546), and CalDAV (RFC 4791) standards. This working group will do the following: - Develop an extension to iCalendar to support non-Gregorian recurrence rules, without the need to support new calendar scale values in iCalendar as a whole. This will allow for easy implementation of the primary use case for non-Gregorian support in calendar systems, without the need for significant changes to the iCalendar format. The non-Gregorian calendar system should be based on the International Components for Unicode work by the Unicode Consortium (http://site.icu-project.org). - Develop an extension to iCalendar to support a new component type that allows users to express arbitrary, possibly repeating, periods of "available" time. The primary use case for this is for users to express their "office hours" (e.g., Monday-Friday, 9am-5pm) in a standard way to ensure free busy lookups show the correct periods of availability. - Define a set of new iCalendar properties and parameters to standardise some existing experimental X- properties in common use, based on a survey of existing implementations. - Define a set of new iCalendar properties and parameters to cover key uses cases that implementers have identified, including, but not limited to, a new "IMAGE" property (to allow embedding/linking of images tied to a specific event), and a "CONFERENCE" property (to allow embedding information about dial-in numbers and similar multi-party communication options for an event). The working group will work under the following parameters: - The extensions developed are expected to be backwards-compatible with the existing calendar standards. Incompatibilities must be identified, minimized, and justified. - For each set of extensions, examine their impact on the iTIP protocol (RFC 5546), and define any necessary extensions to iTIP to accommodate such impact. - For each set of extensions, examine their impact on the CalDAV protocol (RFC 4791), and define any necessary extensions to CalDAV to accommodate such impact. Interface with the httpbis working group to ensure that any CalDAV changes are consistent with good http practices. The working group will use the following drafts as initial input for its work: draft-daboo-icalendar-rscale-03 draft-daboo-calendar-availability-05 draft-daboo-icalendar-extensions-08 The following are out of scope for the working group: - Any change that impacts backwards compatibility with existing deployed iCalendar/iTIP/CalDAV clients and servers will be discussed by the working group with a view to minimizing disruption to deployed implementations without compromising desirable new function. - Any attempt to develop non-Gregorian calendar systems/calculations. Goals and Milestones: May 2020 - Submit scheduling controls document to IESG for publication May 2020 - Submit valarm document to IESG for publication May 2020 - Adopt a draft for Server Side Subscription Jun 2020 - Send JSCalendar draft to IESG Jun 2020 - Submit calendar series document to IESG for publication Jul 2020 - Submit Subscription Upgrade document to IESG for publication Oct 2020 - Submit vpoll document to IESG for publication Oct 2020 - Submit Serverside Subscription draft to IESG for publication Done - Submit non-Gregorian recurrence rule draft to IESG for publication Done - WG adoption of an availability draft Done - WG adoption of an extensions draft Done - Submit availability draft to IESG for publication Done - Submit extensions draft to IESG for publication Done - Send attachment dratf to IESG Done - Adopt a document for subscription upgrade Done - Send Event Publication draft to IESG Done - Send iCal relation draft to IESG Done - Adopt a document for consensus scheduling Done - Update charter/milestones to reflect current and planned work Internet-Drafts: - Calendar Availability [draft-daboo-calendar-availability-05] (22 pages) - New Properties for iCalendar [draft-daboo-icalendar-extensions-09] (21 pages) - Non-Gregorian Recurrence Rules in iCalendar [draft-daboo-icalendar-rscale-04] (15 pages) - Calendar Availability [draft-ietf-calext-availability-04] (24 pages) - Calendaring Extensions to WebDAV (CalDAV): Managed Attachments [draft-ietf-calext-caldav-attachments-04] (34 pages) - CalDAV Extension for scheduling controls [draft-ietf-calext-caldav-scheduling-controls-00] (6 pages) - Event Publishing Extensions to iCalendar [draft-ietf-calext-eventpub-extensions-15] (33 pages) - New Properties for iCalendar [draft-ietf-calext-extensions-05] (23 pages) - Support for iCalendar Relationships [draft-ietf-calext-ical-relations-04] (19 pages) - Support for Series in iCalendar [draft-ietf-calext-icalendar-series-00] (27 pages) - JSCalendar: A JSON representation of calendar data [draft-ietf-calext-jscalendar-26] (77 pages) - JSCalendar: Converting from and to iCalendar [draft-ietf-calext-jscalendar-icalendar-01] (13 pages) - JSContact: A JSON representation of contact data [draft-ietf-calext-jscontact-00] (17 pages) - Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar) [draft-ietf-calext-rscale-04] (21 pages) - Calendar subscription upgrades [draft-ietf-calext-subscription-upgrade-01] (16 pages) - VALARM Extensions for iCalendar [draft-ietf-calext-valarm-extensions-01] (16 pages) - VPOLL: Consensus Scheduling Component for iCalendar [draft-ietf-calext-vpoll-00] (57 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) Captive Portal Interaction (capport) ------------------------------------ Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Erik Kline Martin Thomson Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba Mailing Lists: General Discussion: captive-portals@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/captive-portals Archive: https://mailarchive.ietf.org/arch/search/?email_list=captive-portals Description of Working Group: Some networks require interaction from users prior to authorizing network access. Before that authorization is granted, network access might be limited in some fashion. Frequently, this authorization process requires human interaction to arrange for payment or to accept some legal terms. Currently, network providers use a number of interception techniques to reach a human user (such as intercepting cleartext HTTP to force a redirect to a web page of their choice), and these interceptions are indistinguishable from man-in-the-middle attacks. As endpoints become inherently more secure, existing interception techniques will become less effective or will fail entirely. This will result in a poor user experience as well as a lower rate of success for the Captive Portal operator. The CAPPORT Working Group will define secure mechanisms and protocols to - allow endpoints to discover that they are in this sort of limited environment, - provide a URL to interact with the Captive Portal, - allow endpoints to learn about the parameters of their confinement, - interact with the Captive Portal to obtain information such as status and remaining access time, and - optionally, advertise a service whereby devices can enable or disable access to the Internet without human interaction. (RFC 7710 may be a full or partial solution to the first two bullets) The working group may produce working documents to define taxonomy and to survey existing portals and solutions. These might or might not be published as RFCs, and might or might not be combined in some way. Out of scope are "roaming" (federation of credentials), network selection, or the on-boarding/provisioning of clients onto secure (or any alternate) networks. These are not really captive portals, and have largely been solved in other ways. Initially, the working group will focus on simplifying captive portal interactions where a user is present. A secondary goal is to look at the problem posed to or by devices that have little or no recourse to human interaction. Goals and Milestones: Jul 2019 - Protocol to discover and interact with a Captive Portal Jul 2019 - API for Captive Portal Interaction Jul 2019 - API for Captive Portal Interaction Internet-Drafts: - Captive Portal API [draft-ietf-capport-api-07] (11 pages) - CAPPORT Architecture [draft-ietf-capport-architecture-08] (19 pages) - Captive-Portal Identification in DHCP / RA [draft-ietf-capport-rfc7710bis-06] (12 pages) No Requests for Comments Concise Binary Object Representation Maintenance and Extensions (cbor) ---------------------------------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Francesca Palombini Jim Schaad Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba 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 will update RFC 7049 to deal with existing errata. Security issues and clarifications may be addressed, but changes to the document will ensure backward compatibility for widespread deployed codebases. The resulting document will be targeted at becoming 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 add to a second edition of the specification where warranted. 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 will be asked to adopt and publish these proposals. The working group will evaluate such requests individually and decide about adoption and milestones as such requests arise. Proposals that are deemed to be out of scope for the working group, for example because they are too narrow-purpose of a specification, may still be published as individual submissions or in other groups if there is a specific need. The CBOR group will review these proposals on request. Goals and Milestones: Oct 2018 - Submit rfc7049bis to IESG as a Proposed Standard Internet-Drafts: - Concise Binary Object Representation (CBOR) [draft-ietf-cbor-7049bis-13] (74 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) - Concise Binary Object Representation (CBOR) Tags for Date [draft-ietf-cbor-date-tag-00] (5 pages) - Concise Binary Object Representation (CBOR) Sequences [draft-ietf-cbor-sequence-02] (10 pages) - Concise Binary Object Representation (CBOR) Tags for Date [draft-jones-cbor-date-tag-01] (5 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) Common Control and Measurement Plane (ccamp) -------------------------------------------- Charter Last Modified: 2015-10-07 Current Status: Active Chairs: Daniele Ceccarelli Fatai Zhang Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Deborah Brungard Secretary: Oscar de Dios 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: Feb 2015 - Submit OTN signal types update and sub registry drafts to IESG for review Apr 2015 - Submit flexi grid framework to IESG for review Apr 2015 - First draft of G.698.2 LMP and MIBs working group draft Jun 2015 - First draft of technology specific version of signaling and routing bandwidth availability working group draft. Jun 2015 - First draft of Information Encoding for WSON with Impairments Validation working group draft Jul 2015 - First version of YANG modelling for flexi grid Working Group draft Sep 2015 - Submit flexi grid label, signaling and routing extensions to IESG for review Oct 2015 - Submit flexi grid LMP to IESG for review Nov 2015 - First versions of impairments related solutions Working Group drafts Dec 2015 - Submit Info Model for WSON with impairments validation to IESG for review Feb 2016 - Submit G.698.2 LMP and MIBs drafts to IESG for review Mar 2016 - Submit technology specific version of signaling and routing bandwidth availability draft to IESG for review May 2016 - Submit Information Encoding for WSON with Impairments Validation draft to IESG for review May 2016 - Submit YANG modelling for flexi grid draft to IESG for review Jul 2016 - Recharter or close Working Group Jul 2016 - Submit impairments related solutions for IESG review Done - Post strawman WG goals and charter Done - Identify and document a limited set of candidate solutions for signalling and for measurement. Among candidate control solutions to be considered are the existing GMPLS drafts. Done - Build appropriate design teams Done - Submit WG document defining path setup portions of common control plane protocol Done - Submit WG document defining common measurement plane protocol Done - Submit LMP MIB to IESG Done - Submit GMPLS MIBs to IESG Done - Submit protection & restoration documents to IESG Done - Submit ASON signaling requirements doc to IESG Done - Produce CCAMP WG document for multi-area/AS signaling and routing Done - Produce CCAMP WG document for generic tunnel tracing protocol Done - Submit ASON routing requirements doc to IESG Done - Submit revised charter and milestones to IESG for IESG consideration of more detailed deliverables and determination of usefulness of continuation of WG Done - First version WG I-D for Advertising TE Node Capabilities in ISIS and OSPF Done - First version WG I-D for Automatic discovery of MPLS-TE mesh membership Done - Submit ASON Routing evaluation I-D for IESG review Done - Cross-WG review of I-D for Advertising TE Node Capabilities in ISIS and OSPF Done - First version WG I-D MPLS to GMPLS migration strategies Done - Submit RSVP-TE extensions for inter-domain signaling I-D for IESG review Done - Submit Per-domain path computation signaling I-D for IESG review Done - First version of WG I-D for ASON Routing solutions Done - First version WG I-D Requirements for Multi-Layer and Multi-Region Networks Done - First version WG I-D for Evaluation of existing protocols for MLN/MRN Done - Submit GMPLS signaling in support of Call Management I-D for IESG review Done - Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF for IESG review Done - First version WG I-D for Protocol solutions for MLN/MRN Done - First version of WG I-D for OSPF-TE/GMPLS MIB module Done - First version WG Informational I-D for Analysis of inter-domain issues for disjoint and protected paths Done - Submit GMPLS/ASON lexicography I-D for IESG review Done - Submit LSP Stitching I-D for IESG review Done - First version WG I-D MPLS-GMPLS interworking requirements and solutions Done - Submit I-D for Automatic discovery of MPLS-TE mesh membership for IESG review Done - First version WG I-D GMPLS OAM Requirements Done - Submit GMPLS routing and signaling interoperability advice I-D for IESG review Done - Submit MPLS to GMPLS migration strategies I-D for IESG review Done - Submit Requirements for Multi-Layer and Multi-Region Networks I-D for IESG review Done - Submit MPLS-GMPLS interworking requirements and solutions I-D for IESG review Done - Submit Evaluation of existing protocols for MLN/MRN for IESG review Done - Submit Informational I-D for Analysis of inter-domain issues for disjoint and protected paths for IESG review Done - First version WG I-Ds for GMPLS source-controlled and explicitly-routed Ethernet networks Done - Submit Protocol solutions for MLN/MRN I-D for IESG review Done - First version of WSON routing related Working Group drafts Done - Submit Ethernet related drafts for IESG review Done - Submit hierarchy bis for IESG review Done - First version of LMP Negotiation Working Group draft Done - First version of G.709 enhancements framework Working Group drafts Done - First version of Working Group draft providing Control Plane Framework for MPLS-TP Done - Submit TE MIB module IESG review Done - Submit VCAT/LCAS with GMPLS for IESG review Done - Submit Lambda labels draft for IESG review Done - Submit WSON framework draft for IESG review Done - Submit WSON impairment framework draft for IESG review Done - First version of OAM configuration solutions Working Group draft 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 OAM configuration framework for IESG review Done - Submit LMP Negotiation for IESG review Done - Submit G.709 enhancements framework for IESG review Done - Submit G.709 enhancements solutions for IESG review Done - First version flexigrid requirements/framework Working Group draft Done - Submit first set of OAM configuration solutions for IESG review Done - Submit last OAM configuration solutions for IESG review Done - Submit WSON routing related drafts for IESG review Done - Submit WSON signaling related draft for IESG 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) - 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) - 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 Transport Network Client Signals [draft-ietf-ccamp-client-signal-yang-02] (55 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-02] (16 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-04] (25 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) - 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) - 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) - Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers [draft-ietf-ccamp-flexigrid-lambda-label-05] (14 pages) - YANG data model for Flexi-Grid media-channels [draft-ietf-ccamp-flexigrid-media-channel-yang-02] (36 pages) - YANG data model for Flexi-Grid Optical Networks [draft-ietf-ccamp-flexigrid-yang-05] (75 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 MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching [draft-ietf-ccamp-gmpls-ether-svcs-04] (15 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 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 B100G Optical Transport Network [draft-ietf-ccamp-gmpls-otn-b100g-applicability-02] (19 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) - Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base [draft-ietf-ccamp-gmpls-te-mib-16] (60 pages) - Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS [draft-ietf-ccamp-gmpls-ted-mib-15] (40 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 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-11] (18 pages) - A YANG Data Model for Layer 0 Types [draft-ietf-ccamp-layer0-types-05] (20 pages) - A YANG Data Model for Layer 1 Types [draft-ietf-ccamp-layer1-types-06] (38 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-01] (27 pages) - A YANG Data Model for Microwave Radio Link [draft-ietf-ccamp-mw-yang-13] (53 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-03] (58 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) - 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-10] (71 pages) - OTN Tunnel YANG Model [draft-ietf-ccamp-otn-tunnel-model-10] (37 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) - 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-10] (100 pages) - Transport Northbound Interface Applicability Statement and Use Cases [draft-ietf-ccamp-transport-nbi-use-cases-01] (28 pages) - Generic Tunnel Tracing Protocol (GTTP) Specification [draft-ietf-ccamp-tunproto-01] (36 pages) - Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) [draft-ietf-ccamp-wavelength-switched-framework-01] (37 pages) - A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments [draft-ietf-ccamp-wson-impairments-10] (31 pages) - 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-11] (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-05] (40 pages) - A YANG Data Model for WSON (Wavelength Switched Optical Networks) [draft-ietf-ccamp-wson-yang-24] (60 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions [draft-ietf-mpls-generalized-cr-ldp-07] (23 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions [draft-ietf-mpls-generalized-rsvp-te-09] (42 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description [draft-ietf-mpls-generalized-signaling-09] (34 pages) - A framework for Management and Control of DWDM optical interface parameters [draft-kdkgall-ccamp-dwdm-if-mng-ctrl-fwk-01] (29 pages) - A Yang Data Model for WSON Optical Networks [draft-lee-ccamp-wson-yang-04] (17 pages) - Link Management Protocol Extensions for Grid Property Negotiation [draft-li-ccamp-grid-property-lmp-03] (12 pages) - OSPF Routing Extension for Links with Variable Discrete Bandwidth [draft-long-ccamp-ospf-availability-extension-04] (8 pages) - RSVP-TE Signaling Extension for Links with Variable Discrete Bandwidth [draft-long-ccamp-rsvp-te-bandwidth-availability-05] (11 pages) - Information Encoding for WSON with Impairments Validation [draft-martinelli-ccamp-wson-iv-encode-09] (12 pages) - Information Model for Wavelength Switched Optical Networks (WSONs) with Impairments Validation [draft-martinelli-ccamp-wson-iv-info-05] (19 pages) - A YANG Data Model for Microwave Radio Link [draft-mwdt-ccamp-mw-yang-01] (37 pages) - Framework and Requirements for GMPLS based control of Flexi-grid DWDM networks [draft-ogrcetal-ccamp-flexi-grid-fwk-03] (30 pages) - OTN Tunnel YANG Model [draft-sharma-ccamp-otn-tunnel-model-02] (21 pages) - Transport Northbound Interface Applicability Statement and Use Cases [draft-tnbidt-ccamp-transport-nbi-use-cases-03] (28 pages) - YANG Alarm Module [draft-vallin-ccamp-alarm-module-01] (58 pages) - 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) 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 RFC4873: GMPLS Segment Recovery (25 pages) 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) 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) Content Delivery Networks Interconnection (cdni) ------------------------------------------------ Charter Last Modified: 2019-03-27 Current Status: Active Chairs: François Le Faucheur Kevin J. Ma Phil Sorber Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba 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: Jun 2020 - Recharter or dissolve Jun 2020 - Submit specification of CDNI Control Triggers Interface Extensions to IESG as Proposed Standard Jun 2020 - Submit specification of CDNI Extensions for HTTPS Delegation to IESG as Proposed Standard 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 Internet-Drafts: - CDNI SVA Request Routing Extensions [draft-finkelman-cdni-rr-sva-extensions-01] (11 pages) - Content Delivery Network Interconnection (CDNI) Control Interface / Triggers [draft-ietf-cdni-control-triggers-15] (49 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 extensions for HTTPS delegation [draft-ietf-cdni-interfaces-https-delegation-03] (11 pages) - Content Distribution Network Interconnection (CDNI) Logging Interface [draft-ietf-cdni-logging-27] (63 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 Distribution Network Interconnection (CDNI) Problem Statement [draft-ietf-cdni-problem-statement-08] (32 pages) - Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection [draft-ietf-cdni-redirection-20] (35 pages) - CDNI Request Routing Extensions [draft-ietf-cdni-request-routing-extensions-08] (19 pages) - Content Distribution Network Interconnection (CDNI) Requirements [draft-ietf-cdni-requirements-17] (23 pages) - CDNI Control Triggers Interface Extensions [draft-ietf-cdni-triggers-extensions-04] (42 pages) - URI Signing for CDN Interconnection (CDNI) [draft-ietf-cdni-uri-signing-19] (42 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) Codec Encoding for LossLess Archiving and Realtime transmission (cellar) ------------------------------------------------------------------------ Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Michael Richardson Spencer Dawkins Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Murray Kucherawy 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: Apr 2019 - Submit specification for Matroska container format version 4 to IESG (Standards Track) Jun 2020 - Submit informational specification for Matroska container format versions 1, 2 and 3 to IESG for publication Sep 2020 - Submit specification for FFV1 video codec version 4 to IESG (Standards Track) Apr 2021 - Submit specification for FLAC audio codec 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 Internet-Drafts: - Matroska Media Container Codec Specifications [draft-ietf-cellar-codec-04] (50 pages) - Extensible Binary Meta Language [draft-ietf-cellar-ebml-17] (59 pages) - FFV1 Video Coding Format Version 0, 1, and 3 [draft-ietf-cellar-ffv1-13] (51 pages) - FFV1 Video Coding Format Version 4 [draft-ietf-cellar-ffv1-v4-10] (53 pages) - Free Lossless Audio Codec [draft-ietf-cellar-flac-00] (31 pages) - Matroska Media Container Format Specifications [draft-ietf-cellar-matroska-05] (170 pages) - Matroska Media Container Tag Specifications [draft-ietf-cellar-tags-04] (22 pages) - FF Video Codec 1 [draft-niedermayer-cellar-ffv1-02] (36 pages) - Free Lossless Audio Codec [draft-weaver-cellar-flac-00] (31 pages) No Requests for Comments Constrained RESTful Environments (core) --------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Jaime Jimenez Marco Tiloca Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba 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: Dec 2017 - Media Types for Sensor Measurement Lists (SenML) submitted to IESG for PS Dec 2017 - CBOR Encoding of Data Modeled with YANG submitted to IESG for PS Dec 2017 - Object Security for Constrained RESTful Environments (OSCORE) Jan 2018 - Management over CoAP submitted to IESG for PS Mar 2018 - CoRE Resource Directory submitted to IESG for PS Dec 2099 - CoRE Interfaces submitted to IESG Done - Blockwise transfers in CoAP submitted to IESG Done - Best Practices for HTTP-CoAP Mapping Implementation submitted to IESG Done - Representing CoRE Link Collections in JSON submitted to IESG Done - Patch and Fetch Methods for CoAP submitted to IESG for PS Done - WG adoption for Management over CoAP Done - CoAP over TCP, TLS, and WebSockets submitted to IESG for PS Internet-Drafts: - SenML Features and Versions [draft-bormann-core-senml-versions-01] (5 pages) - Problem Details For CoAP APIs [draft-fossati-core-coap-problem-02] (12 pages) - Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP) [draft-hartke-core-stateless-02] (16 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) - Publish-Subscribe Broker for the Constrained Application Protocol (CoAP) [draft-ietf-core-coap-pubsub-09] (25 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 [draft-ietf-core-comi-09] (51 pages) - The Constrained RESTful Application Language (CoRAL) [draft-ietf-core-coral-03] (40 pages) - Uniform Resource Names for Device Identifiers [draft-ietf-core-dev-urn-04] (17 pages) - Dynamic Resource Linking for Constrained RESTful Environments [draft-ietf-core-dynlink-10] (24 pages) - CoAP: Echo, Request-Tag, and Token Processing [draft-ietf-core-echo-request-tag-09] (31 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-00] (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-00] (38 pages) - Constrained Application Protocol (CoAP) Hop-Limit Option [draft-ietf-core-hop-limit-07] (8 pages) - Constrained Resource Identifiers [draft-ietf-core-href-03] (12 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) - 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) - Group OSCORE - Secure Group Communication for CoAP [draft-ietf-core-oscore-groupcomm-08] (65 pages) - Problem Details For CoAP APIs [draft-ietf-core-problem-details-00] (13 pages) - CoRE Resource Directory: DNS-SD mapping [draft-ietf-core-rd-dns-sd-05] (14 pages) - CoRE Resource Directory [draft-ietf-core-resource-directory-24] (79 pages) - Sensor Measurement Lists (SenML) [draft-ietf-core-senml-16] (54 pages) - SenML Data Value Content-Format Indication [draft-ietf-core-senml-data-ct-01] (7 pages) - FETCH & PATCH with Sensor Measurement Lists (SenML) [draft-ietf-core-senml-etch-07] (11 pages) - Additional Units for SenML [draft-ietf-core-senml-more-units-06] (9 pages) - SenML Features and Versions [draft-ietf-core-senml-versions-00] (5 pages) - YANG Schema Item iDentifier (SID) [draft-ietf-core-sid-12] (35 pages) - Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP) [draft-ietf-core-stateless-06] (16 pages) - "Too Many Requests" Response Code for the Constrained Application Protocol [draft-ietf-core-too-many-reqs-06] (6 pages) - CBOR Encoding of Data Modeled with YANG [draft-ietf-core-yang-cbor-12] (44 pages) - Constrained YANG Module Library [draft-ietf-core-yang-library-01] (15 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) - 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 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) RFC8428: Sensor Measurement Lists (SenML) (54 pages) 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) CBOR Object Signing and Encryption (cose) ----------------------------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Ivaylo Petrov Matthew A. Miller Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Benjamin Kaduk 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) as well as outside of the IETF (i.e. W3C and FIDO). There are a number of implementations, both open source and private, now in existence. The specification is now sufficiently mature that it makes sense to try and advance it to STD status. The standards progression work will focus on: 1. Should the document be split in two? The first document would contain the definitions of the structures and rules for processing them. The second document would contain the set of original algorithms that were defined. 2. What areas in the document need clarification before the document can be progressed? 3. What implementations exist and do they cover all of the major sections of the document? 4. Resolution of any Errata or ambiguities in the document There are a small number of COSE related documents that will also be addressed by the working group dealing with additional attributes and algorithms that need to be reviewed and published. The first set are listed below in the deliverables. A re-charter will be required to expand this list. The SUIT working group has identified a need for the use of hash-based signatures in the form of Leighton-Micali Signatures (LMS) (draft-mcgrew-hash-sigs). This signature form is resistant to quantum computer attacks and is low-cost for validation. The SUIT working group additionally has identified a need for registering hash functions for indirect packaging. The W3C Web Authentication working group has identified a need for the ability to use algorithms which are currently part of TPMs which are widely deployed. At the time COSE was developed, there was a sense that X.509 certificates were not a feature that needed to be transferred from the JOSE key document (RFC 7517). Since that time a better sense of how X.509 certificates would be used both in the IoT sphere and with COSE outside of the IoT sphere has been developed. The ability to identify or carry X.509 certificates now needs to be provided. This will require the definition of a small number of hash functions for compact references to X.509 certificates. 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 we are 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 will have five deliverables: 1. Republishing a version of RFC 8152 suitable for advancement to Internet Standard. 2. Use of Hash-based Signature algorithms in COSE using draft-housley-suit-cose-hash-sig as a starting point (Informational). 3. Placement of X.509 certificates in COSE messages and keys using draft-schaad-cose-x509 as a starting point (Informational). 4. Define the algorithms needed for W3C Web Authentication for COSE using draft-jones-webauthn-cose-algorithms and draft-jones-webauthn-secp256k1 as a starting point (Informational). 5. Define a small number of hash functions for X.509 certificate thumbprints and for indirect signing (for SUIT) (Informational). Goals and Milestones: Internet-Drafts: - CBOR Object Signing and Encryption (COSE): Hash Algorithms [draft-ietf-cose-hash-algs-03] (10 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) - CBOR Object Signing and Encryption (COSE) [draft-ietf-cose-msg-24] (121 pages) - CBOR Object Signing and Encryption (COSE): Initial Algorithms [draft-ietf-cose-rfc8152bis-algs-08] (49 pages) - CBOR Object Signing and Encryption (COSE): Structures and Process [draft-ietf-cose-rfc8152bis-struct-09] (86 pages) - COSE and JOSE Registrations for WebAuthn Algorithms [draft-ietf-cose-webauthn-algorithms-06] (13 pages) - CBOR Object Signing and Encryption (COSE): Header parameters for carrying and referencing X.509 certificates [draft-ietf-cose-x509-06] (10 pages) - CBOR Encoded Message Syntax [draft-schaad-cose-msg-01] (48 pages) Requests for Comments: RFC8152: CBOR Object Signing and Encryption (COSE) (121 pages) RFC8778: Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE) (15 pages) CURves, Deprecating and a Little more Encryption (curdle) --------------------------------------------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Daniel Migault Rich Salz Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Benjamin Kaduk Mailing Lists: General Discussion: curdle@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/curdle Archive: https://mailarchive.ietf.org/arch/browse/curdle/ Description of Working Group: CURDLE - CURves, Deprecating and a Little more Encryption The CURDLE working group is chartered to add a small set of cryptographic mechanisms to some IETF protocols, and to make implementation requirements including deprecation of old algorithms where there is IETF consensus to do so. The focus with regards to adding mechanisms is for those mechanisms that enjoy broad support from implementers. The set of cryptographic mechanisms that can be introduced are limited to key agreement (ECDH) and digital signatures (EdDSA) with Curve25519 and Curve448 as defined by CFRG [1] [2], and the AEAD mode ciphers consisting of ChaCha20 and Poly1305 also defined by CFRG [3]. Other variants of mechanisms, such as the ChaCha20-Poly1305 construct deployed for SSH, may also be considered as well as AES-CCM[4] and AES-GCM [5] where those are not already defined and where there is implementer interest. Related specifications such as private and public key formats are also within scope. The protocols the WG intends to work on are Secure Shell (SSH), DNSSEC, PKIX, CMS, XML Digital Signatures and potentially XML Encryption, Kerberos and JSON. Where initial drafts for this work have been produced those will be immediately considered for adoption as working group documents. These include, for SSH, Curve25519/Curve448 digital signatures [6] and key exchange [7]; for DNSSEC, Ed25519 [8] and Curve448 [9]; for PKIX, Curve25519/448 NamedCurve [10] and EdDSA signatures [11]; for JSON curves and signatures [12]. The CURDLE working group will be handling changes to protocols and registries some of which include what are now considered outdated algorithm options, and may propose deprecation of such algorithms. Such deprecation needs to be done with care, ensuring that interoperability and the needs of existing implementers and deployments are properly considered. Where deprecation is practical, the working group is encouraged to deprecate. Where there is an IETF working group or area group with expertise in a relevant topic the CURDLE working group will defer to the consensus of the more specific working group as to where work will be done. For example, the TLS, OpenPGP and IPSECME WGs are actively considering some of these topics. The CURDLE working group will liaise with W3C to ensure that XML digital signature and XML encryption work does not conflict with W3C. The CURDLE working group is expected to be a short-lived working group that may not need to ever meet face-to-face. Once the work on the initially adopted set of drafts has completed the working group will close or re-charter. The CURDLE working group is not chartered to consider allocating new codepoints for any algorithms or modes other than those mentioned above. Should someone wish to propose such work, a re-charter will be required. At this time, there is no expectation that such a re-charter will be requested. [1] https://tools.ietf.org/html/draft-irtf-cfrg-curves [2] https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-00 [3] RFC 7539 [4] RFC 3610 [5] RFC5288 [6] https://tools.ietf.org/html/draft-bjh21-ssh-ed25519-02 [7] https://tools.ietf.org/html/draft-josefsson-ssh-curves-00 [8] https://tools.ietf.org/html/draft-sury-dnskey-ed25519-03 [9] https://tools.ietf.org/html/draft-sury-dnskey-ed448-00 [10] https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-01 [11] https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04 [12] http://www.ietf.org/mail-archive/web/jose/current/msg05357.html Goals and Milestones: Jan 2016 - Decision on which drafts to adopt Jun 2016 - Send last draft to IESG Internet-Drafts: - Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS) [draft-ietf-curdle-cms-chacha20-poly1305-06] (9 pages) - Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS) [draft-ietf-curdle-cms-ecdh-new-curves-10] (18 pages) - Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS) [draft-ietf-curdle-cms-eddsa-signatures-08] (9 pages) - Deprecate Triple-DES (3DES) and RC4 in Kerberos [draft-ietf-curdle-des-des-des-die-die-die-05] (10 pages) - Ed25519 for DNSSEC [draft-ietf-curdle-dnskey-ed25519-01] (7 pages) - Ed448 for DNSSEC [draft-ietf-curdle-dnskey-ed448-00] (7 pages) - Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC [draft-ietf-curdle-dnskey-eddsa-03] (7 pages) - Generic Security Service Application Program Interface (GSS-API) Key Exchange with SHA-2 [draft-ietf-curdle-gss-keyex-sha2-10] (12 pages) - Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure [draft-ietf-curdle-pkix-10] (20 pages) - Using EdDSA with Ed25519/Ed448 in the Internet X.509 Public Key Infrastructure [draft-ietf-curdle-pkix-eddsa-00] (10 pages) - Using Curve25519 and Curve448 in PKIX [draft-ietf-curdle-pkix-newcurves-00] (4 pages) - Deprecating RC4 in Secure Shell (SSH) [draft-ietf-curdle-rc4-die-die-die-18] (5 pages) - Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol [draft-ietf-curdle-rsa-sha2-12] (9 pages) - Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448 [draft-ietf-curdle-ssh-curves-12] (6 pages) - Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits [draft-ietf-curdle-ssh-dh-group-exchange-06] (5 pages) - Ed25519 public key algorithm for the Secure Shell (SSH) protocol [draft-ietf-curdle-ssh-ed25519-02] (5 pages) - Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol [draft-ietf-curdle-ssh-ed25519-ed448-11] (7 pages) - Extension Negotiation in the Secure Shell (SSH) Protocol [draft-ietf-curdle-ssh-ext-info-15] (14 pages) - Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH) [draft-ietf-curdle-ssh-kex-sha2-10] (16 pages) - More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH) [draft-ietf-curdle-ssh-modp-dh-sha2-09] (8 pages) - IANA Registration for the Cryptographic Algorithm Object Identifier Range [draft-schaad-curdle-oid-registry-03] (5 pages) Requests for Comments: BCP218: Deprecate Triple-DES (3DES) and RC4 in Kerberos (10 pages) BCP227: Deprecating RC4 in Secure Shell (SSH) (5 pages) RFC8080: Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC (7 pages) RFC8103: Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS) (9 pages) RFC8268: More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH) (8 pages) RFC8270: Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits (5 pages) RFC8308: Extension Negotiation in the Secure Shell (SSH) Protocol (14 pages) RFC8332: Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol (9 pages) RFC8410: Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure (20 pages) RFC8411: IANA Registration for the Cryptographic Algorithm Object Identifier Range (5 pages) RFC8418: Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS) (18 pages) RFC8419: Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS) (9 pages) RFC8429: Deprecate Triple-DES (3DES) and RC4 in Kerberos (10 pages) RFC8709: Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol (7 pages) RFC8731: Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448 (6 pages) RFC8732: Generic Security Service Application Program Interface (GSS-API) Key Exchange with SHA-2 (12 pages) RFC8758: Deprecating RC4 in Secure Shell (SSH) (5 pages) Deterministic Networking (detnet) --------------------------------- Charter Last Modified: 2018-07-14 Current Status: Active Chairs: János Farkas Lou Berger Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Deborah Brungard Tech Advisor: David Black Secretary: Ethan Grossman 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 latency, loss, and packet delay variation (jitter), and high reliability. 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 can include 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 encompasses 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 from 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 explicitly excludes modifications of transport protocols, OAM, Layer 3 forwarding, and encapsulations, but it may discuss requirements for such modifications and the work will be done in 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 document how to use IP and/or MPLS, and related OAM, to support a data plane method of flow identification and packet forwarding 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 from 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 from the protocol(s) which 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. 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: Apr 2020 - Submit security considerations document for publications Apr 2020 - Submit data flow information model (informational) Jun 2020 - Adopt controller plane framework Aug 2020 - Submit YANG model (Standards Track) Aug 2020 - Submit TSN data plane documents (Standards track) Aug 2020 - Adopt DetNet IP OAM document Mar 2021 - Submit first OAM document for publication May 2021 - Submit controller plane framework Jun 2021 - Submit DetNet IP OAM document Done - Finalize use cases (informational) Done - Submit architecture (Standards Track) Done - WG adoption of YANG model Done - Finalize problem statement (informational) Done - Submit data plane specification (Standards Track) Done - Initial OAM WG document 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) - DetNet Bounded Latency [draft-ietf-detnet-bounded-latency-01] (28 pages) - DetNet Data Plane Framework [draft-ietf-detnet-data-plane-framework-06] (26 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) - DetNet Flow Information Model [draft-ietf-detnet-flow-information-model-10] (21 pages) - DetNet Data Plane: IP [draft-ietf-detnet-ip-06] (23 pages) - DetNet Data Plane: IP over MPLS [draft-ietf-detnet-ip-over-mpls-06] (13 pages) - DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN) [draft-ietf-detnet-ip-over-tsn-02] (11 pages) - DetNet Data Plane: MPLS [draft-ietf-detnet-mpls-06] (30 pages) - Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with MPLS Data Plane [draft-ietf-detnet-mpls-oam-00] (11 pages) - DetNet Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking (TSN) [draft-ietf-detnet-mpls-over-tsn-02] (13 pages) - DetNet Data Plane: MPLS over UDP/IP [draft-ietf-detnet-mpls-over-udp-ip-06] (9 pages) - Deterministic Networking Problem Statement [draft-ietf-detnet-problem-statement-09] (11 pages) - Deterministic Networking (DetNet) Security Considerations [draft-ietf-detnet-security-09] (40 pages) - Deterministic Networking (DetNet) Topology YANG Model [draft-ietf-detnet-topology-yang-00] (18 pages) - DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS [draft-ietf-detnet-tsn-vpn-over-mpls-02] (15 pages) - Deterministic Networking Use Cases [draft-ietf-detnet-use-cases-20] (97 pages) - Deterministic Networking (DetNet) Configuration YANG Model [draft-ietf-detnet-yang-05] (39 pages) - Deterministic Networking (DetNet) Security Considerations [draft-sdt-detnet-security-01] (35 pages) Requests for Comments: RFC8557: Deterministic Networking Problem Statement (11 pages) RFC8578: Deterministic Networking Use Cases (97 pages) RFC8655: Deterministic Networking Architecture (38 pages) Dynamic Host Configuration (dhc) -------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Bernie Volz Tomek Mrugalski 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: Nov 2019 - WGLC Link-Layer Addresses Assignment Mechanism for DHCPv6 Nov 2019 - WGLC SLAP quadrant selection options for DHCPv6 Apr 2020 - WGLC IPv6-Only-Preferred Option for DHCP Apr 2020 - WGLC DHCPv6 Prefix Delegating relay Jun 2020 - WGLC draft-ietf-dhc-dhcpv6-yang Nov 2020 - Advance 3315bis RFC to Internet Standard Nov 2020 - Recharter or close down WG Done - WGLC draft-ietf-dhc-dhcp4o6-saddr-opt Done - Adopt DHCPv6 Prefix Delegating relay Done - Adopt IPv6-Only-Preferred Option for DHCP 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) - 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 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) - 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) - 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) - 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) - 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) - DHCP RSA/DSA Authentication using DNS KEY records [draft-ietf-dhc-auth-sigzero-00] (0 pages) - The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option [draft-ietf-dhc-auth-suboption-05] (15 pages) - Authentication for DHCP Messages [draft-ietf-dhc-authentication-16] (17 pages) - DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients [draft-ietf-dhc-autoconfig-04] (9 pages) - Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers [draft-ietf-dhc-bcmc-options-05] (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) - Interaction between DHCP and DNS [draft-ietf-dhc-dhcp-dns-12] (19 pages) - Privacy Considerations for DHCP [draft-ietf-dhc-dhcp-privacy-05] (14 pages) - Softwire Provisioning Using DHCPv4 over DHCPv6 [draft-ietf-dhc-dhcp4o6-saddr-opt-08] (18 pages) - Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications [draft-ietf-dhc-dhcpinform-clarify-06] (9 pages) - Extensions to DHCP for Roaming Users [draft-ietf-dhc-dhcproam-00] (15 pages) - 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) - 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-load-balancing-02] (6 pages) - Load Balancing for DHCPv6 [draft-ietf-dhc-dhcpv6-loadb-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 [draft-ietf-dhc-dhcpv6-pd-relay-requirements-00] (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) - YANG Data Model for DHCPv6 Configuration [draft-ietf-dhc-dhcpv6-yang-10] (74 pages) - Extensions for the Dynamic Host Configuration Protocol for IPv6 [draft-ietf-dhc-dhcpv6exts-12] (39 pages) - DHCPv6 Leasequery [draft-ietf-dhc-dhcvp6-leasequery-01] (21 pages) - Detecting Network Attachment in IPv4 (DNAv4) [draft-ietf-dhc-dna-ipv4-18] (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) - Subnet Configuration Option Set for DHCP [draft-ietf-dhc-dyn-subnet-conf-02] (14 pages) - Dynamic Allocation of Shared IPv4 Addresses [draft-ietf-dhc-dynamic-shared-v4allocation-09] (15 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 Addresses Assignment Mechanism for DHCPv6 [draft-ietf-dhc-mac-assign-06] (19 pages) - Multicast address allocation extensions to the Dynamic Host Configuration Protocol [draft-ietf-dhc-mdhcp-03] (14 pages) - The Migration Agent List Option for DHCP [draft-ietf-dhc-migagntlist-00] (4 pages) - DHCP Option for Mobile IP Mobility Agents [draft-ietf-dhc-mipadvert-opt-02] (15 pages) - Multicast Address Allocation Configuration Options [draft-ietf-dhc-multopt-03] (5 pages) - The Named Pool Request Option for DHCP [draft-ietf-dhc-namedpool-00] (4 pages) - NetWare/IP Domain Name and Information [draft-ietf-dhc-netware-options-00] (6 pages) - Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types [draft-ietf-dhc-new-opt-msg-02] (7 pages) - New Option Review Guidelines for DHCP [draft-ietf-dhc-new-opt-review-00] (8 pages) - Procedure for Defining New DHCP Options [draft-ietf-dhc-new-options-05] (5 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-05] (12 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 (DHCP) Options for the Intel Preboot eXecution Environment (PXE) [draft-ietf-dhc-pxe-options-03] (7 pages) - Dynamic Host Configuration Protocol Options Used by PXELINUX [draft-ietf-dhc-pxelinux-03] (14 pages) - The Server Range Option for DHCP [draft-ietf-dhc-range-00] (2 pages) - Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4) [draft-ietf-dhc-rapid-commit-opt-05] (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) - 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) - SLAP quadrant selection options for DHCPv6 [draft-ietf-dhc-slap-quadrant-08] (17 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) - Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis [draft-ietf-dhc-v4-threat-analysis-03] (20 pages) - Provisioning IPv4 Configuration Over IPv6 Only Networks [draft-ietf-dhc-v4configuration-06] (17 pages) - DHCPv6 Relay agent RADIUS Attribute Option [draft-ietf-dhc-v6-relay-radius-02] (12 pages) - IPv6-Only-Preferred Option for DHCP [draft-ietf-dhc-v6only-00] (12 pages) - Options for DHCPv6 [draft-ietf-dhc-v6opts-00] (15 pages) - Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4) [draft-ietf-dhc-vendor-03] (9 pages) - Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option [draft-ietf-dhc-vendor-suboption-00] (7 pages) - Virtual Subnet Selection Options for DHCPv4 and DHCPv6 [draft-ietf-dhc-vpn-option-15] (26 pages) - Privacy considerations for DHCP [draft-jiang-dhc-dhcp-privacy-00] (12 pages) - Secure DHCPv6 with Public Key [draft-jiang-dhc-sedhcpv6-02] (16 pages) - Privacy considerations for DHCPv6 [draft-krishnan-dhc-dhcpv6-privacy-00] (14 pages) - Customizing DHCP Configuration on the Basis of Network Topology [draft-lemon-dhc-topo-conf-01] (9 pages) - secure DHCPv6 deployment [draft-li-dhc-secure-dhcpv6-deployment-03] (7 pages) - IPv6-Only-Preferred Option for DHCP [draft-link-dhc-v6only-01] (10 pages) - DHCP Options for Novell Directory Services [draft-provan-dhcp-options-dir-serv-01] (5 pages) - Provisioning IPv4 Configuration Over IPv6 Only Networks [draft-rajtar-dhc-v4configuration-02] (13 pages) - Problem Statement of Multi-requirement Extensions for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ren-dhc-problem-statement-of-mredhcpv6-01] (11 pages) - DHCPv4 over DHCPv6 Transport [draft-scskf-dhc-dhcpv4-over-dhcpv6-01] (8 pages) - Generalized Source UDP Port of DHCP Relay [draft-shen-dhc-client-port-03] (7 pages) - 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) Requests for Comments: BCP180: DHCPv6 Redundancy Deployment Considerations (16 pages) BCP187: Guidelines for Creating New DHCPv6 Options (35 pages) BCP29: Procedure for Defining New DHCP Options (5 pages) BCP43: Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types (7 pages) 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) 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 RFC7283 * Updates RFC7227 * 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) 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) 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) Diameter Maintenance and Extensions (dime) ------------------------------------------ Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Jouni Korhonen Lionel Morand Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Robert Wilton Mailing Lists: General Discussion: dime@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dime Archive: https://mailarchive.ietf.org/arch/browse/dime/ Description of Working Group: The Diameter Maintenance and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use for authentication, authorization, accounting, charging in network access, provisioning of configuration information within the network, and for new AAA session management uses within the extensibility rules of the Diameter base protocol. The DIME working group plans to address the following items: - Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes. - Diameter application design guideline. This document will provide guidelines for design of Diameter extensions. It will detail when to consider reusing an existing application and when to develop a new application. - Protocol extensions for bulk and grouped AAA session management. The aim of this work is to study and standardize a solution for handling groups of AAA sessions within the Diameter base protocol context. The solution would define how to identify and handle grouped AAA sessions in commands and operations. - Diameter overload control. The aim of this work is to identify the limitations of the Diameter protocol level overload control provided by the current Diameter Base protocol. A set of requirements will be provided to define a new Diameter level overload control mechanism. Additionally, Diameter-based systems require interoperability in order to work. The working group, along with the AD, will need to evaluate any potential extensions and require verification that the proposed extension is needed, and is within the extensibility rules of Diameter and AAA scope. Coordination with other IETF working groups and other SDOs (e.g. 3GPP) will be used to ensure this. Goals and Milestones: Aug 2013 - Submit a document on 'Protocol extension for bulk and group signaling' to the IESG for consideration as a Proposed Standard Jan 2016 - Submit I-D 'Diameter Overload Control Rate Abatement Algorithm' to the IESG for consideration as a Proposed Standard Oct 2016 - Submit RFC4006bis as a working group document. Aug 2017 - Submit RFC4006bis to the IESG. Done - Submit the following two Diameter Mobility documents to the IESG for consideration as a Proposed Standards:* 'Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction' * 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction' Done - Submit 'Diameter API' to the IESG for consideration as an Informational RFC Done - Submit 'Quality of Service Parameters for Usage with Diameter' to the IESG for consideration as a Proposed Standard. Done - Submit 'Diameter QoS Application' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Support for EAP Re-authentication Protocol' as DIME working group item Done - Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' as DIME working group item Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group item Done - Submit 'Quality of Service Attributes for Diameter' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter NAT Control Application' as DIME working group item Done - Submit 'Diameter Capabilities Update' as DIME working group item Done - Submit 'Diameter Credit Control Application MIB' to the IESG for consideration as an Informational RFC Done - Submit 'Diameter Base Protocol MIB' to the IESG for consideration as an Informational RFC Done - Submit 'Diameter Capabilities Update' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Extended NAPTR' as DIME working group item Done - Submit 'Realm-Based Redirection In Diameter' as DIME working group item Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized Routing' as DIME working group item Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' as DIME working group item Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME working group item Done - Submit 'Diameter IKEv2 PSK' as DIME working group item Done - Submit Revision of 'Diameter Base Protocol' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Priority Attribute Value Pairs' to the IESG for consideration as a Proposed Standard Done - Submit Revision of 'Diameter Network Access Server Application - RFC 4005bis' as DIME working group item Done - Submit 'Diameter NAT Control Application' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter IKEv2 PSK' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Extended NAPTR' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized Routing' to the IESG for consideration as a Proposed Standard Done - Submit 'Realm-Based Redirection In Diameter' to the IESG for consideration as a Proposed Standard Done - Submit Revision of 'Diameter Network Access Server Application - RFC 4005bis' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document Done - Submit 'Diameter Support for EAP Re-authentication Protocol' to the IESG for consideration as a Proposed Standard Done - Submit 'problem statement and requirements for Diameter end-to-end security framework' as Dime working group item Done - Submit a document on 'Protocol extension for bulk and group signaling' as a working group item Done - Submit I-D 'Diameter Overload Control Requirements' as a working group document. To be Informational RFC Done - Submit I-D 'Diameter Overload Control' as a working group document. To be Standards Track RFC Done - Submit I-D 'Diameter Overload Control Requirements' to the IESG for consideration as a Informational Done - Submit 'problem statement and requirements for Diameter end-to-end security framework' to the IESG for consideration as an Informational RFC Done - Submit I-D 'Diameter Overload Control' to the IESG for consideration as a Proposed Standard Done - Submit I-D 'Diameter Congestion and Filter Attributes' to the IESG for considerations as a Proposed Standard Done - Submit a document on 'Diameter Agent Overload' as a working group item Done - Submit a document on 'Diameter Overload Control Rate Abatement Algorithm' as a working group item Done - Submit a document on 'Diameter Load Information' as a working group item Done - Submit I-D 'Diameter Agent Overload' to the IESG for consideration as a Proposed Standard Done - Submit I-D 'Diameter Load Information' to the IESG for consideration as a Proposed Standard Done - Submit I-D 'Diameter Routing Message Priority' to the IESG for considerations as a Proposed Standard Done - Submit 'problem statement and requirements for Diameter end-to-end security framework' to the IESG for consideration as an Informational RFC Internet-Drafts: - Diameter Credit-Control Application [draft-bertz-dime-rfc4006bis-01] (113 pages) - Diameter Overload Indication Conveyance [draft-docdt-dime-ovli-01] (41 pages) - Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions [draft-ietf-dime-4over6-provisioning-06] (23 pages) - Diameter Agent Overload and the Peer Overload Report [draft-ietf-dime-agent-overload-11] (19 pages) - Diameter Applications Design Guidelines [draft-ietf-dime-app-design-guide-28] (29 pages) - The Diameter Capabilities Update Application [draft-ietf-dime-capablities-update-07] (6 pages) - Diameter Congestion and Filter Attributes [draft-ietf-dime-congestion-flow-attributes-02] (9 pages) - The Diameter API [draft-ietf-dime-diameter-api-08] (46 pages) - Diameter Base Protocol MIB [draft-ietf-dime-diameter-base-protocol-mib-06] (51 pages) - Diameter Credit Control Application MIB [draft-ietf-dime-diameter-cc-appl-mib-03] (21 pages) - Updated IANA Considerations for Diameter Command Code Allocations [draft-ietf-dime-diameter-cmd-iana-01] (5 pages) - Diameter Quality-of-Service Application [draft-ietf-dime-diameter-qos-15] (51 pages) - Diameter Overload Rate Control [draft-ietf-dime-doic-rate-control-11] (20 pages) - Diameter Routing Message Priority [draft-ietf-dime-drmp-07] (18 pages) - Security at the Attribute-Value Pair (AVP) Level for Non-neighboring Diameter Nodes: Scenarios and Requirements [draft-ietf-dime-e2e-sec-req-05] (11 pages) - Diameter Support for the EAP Re-authentication Protocol (ERP) [draft-ietf-dime-erp-17] (18 pages) - Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage [draft-ietf-dime-extended-naptr-09] (14 pages) - Diameter Group Signaling [draft-ietf-dime-group-signaling-13] (26 pages) - Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers [draft-ietf-dime-ikev2-psk-diameter-11] (17 pages) - Diameter Load Information Conveyance [draft-ietf-dime-load-09] (23 pages) - Diameter Attribute-Value Pairs for Cryptographic Key Transport [draft-ietf-dime-local-keytran-14] (7 pages) - Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction [draft-ietf-dime-mip6-integrated-12] (17 pages) - Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction [draft-ietf-dime-mip6-split-17] (34 pages) - Clarifications on the Routing of Diameter Requests Based on the Username and the Realm [draft-ietf-dime-nai-routing-04] (11 pages) - Diameter Network Address and Port Translation Control Application [draft-ietf-dime-nat-control-17] (58 pages) - Diameter Overload Control Requirements [draft-ietf-dime-overload-reqs-13] (29 pages) - Diameter Overload Indication Conveyance [draft-ietf-dime-ovli-10] (42 pages) - Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server [draft-ietf-dime-pmip6-04] (20 pages) - Diameter Support for Proxy Mobile IPv6 Localized Routing [draft-ietf-dime-pmip6-lr-18] (11 pages) - Diameter Priority Attribute-Value Pairs [draft-ietf-dime-priority-avps-06] (10 pages) - Traffic Classification and Quality of Service (QoS) Attributes for Diameter [draft-ietf-dime-qos-attributes-15] (43 pages) - Quality of Service Parameters for Usage with Diameter [draft-ietf-dime-qos-parameters-11] (12 pages) - Realm-Based Redirection In Diameter [draft-ietf-dime-realm-based-redirect-13] (10 pages) - Diameter Base Protocol [draft-ietf-dime-rfc3588bis-34] (152 pages) - Diameter Network Access Server Application [draft-ietf-dime-rfc4005bis-14] (70 pages) - Diameter Credit-Control Application [draft-ietf-dime-rfc4006bis-12] (130 pages) - Diameter AVP Level Security: Scenarios and Requirements [draft-tschofenig-dime-e2e-sec-req-01] (8 pages) - Attribute-Value Pairs For Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions [draft-zhou-dime-4over6-provisioning-05] (19 pages) Requests for Comments: BCP193: Diameter Applications Design Guidelines (29 pages) RFC5447: Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction (17 pages) RFC5624: Quality of Service Parameters for Usage with Diameter (12 pages) RFC5719: Updated IANA Considerations for Diameter Command Code Allocations (5 pages) * Obsoletes RFC6733 RFC5729: Clarifications on the Routing of Diameter Requests Based on the Username and the Realm (11 pages) RFC5777: Traffic Classification and Quality of Service (QoS) Attributes for Diameter (43 pages) RFC5778: Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction (34 pages) RFC5779: Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server (20 pages) RFC5866: Diameter Quality-of-Service Application (51 pages) RFC6408: Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage (14 pages) RFC6733: Diameter Base Protocol (152 pages) * Updates RFC7075 * Updates RFC8553 RFC6734: Diameter Attribute-Value Pairs for Cryptographic Key Transport (7 pages) RFC6735: Diameter Priority Attribute-Value Pairs (10 pages) RFC6736: Diameter Network Address and Port Translation Control Application (58 pages) RFC6737: The Diameter Capabilities Update Application (6 pages) RFC6738: Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers (17 pages) RFC6942: Diameter Support for the EAP Re-authentication Protocol (ERP) (18 pages) RFC7068: Diameter Overload Control Requirements (29 pages) RFC7075: Realm-Based Redirection In Diameter (10 pages) RFC7155: Diameter Network Access Server Application (70 pages) RFC7156: Diameter Support for Proxy Mobile IPv6 Localized Routing (11 pages) RFC7423: Diameter Applications Design Guidelines (29 pages) RFC7660: Diameter Congestion and Filter Attributes (9 pages) RFC7678: Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions (23 pages) RFC7683: Diameter Overload Indication Conveyance (42 pages) * Updates RFC8581 RFC7944: Diameter Routing Message Priority (18 pages) RFC7966: Security at the Attribute-Value Pair (AVP) Level for Non-neighboring Diameter Nodes: Scenarios and Requirements (11 pages) RFC8506: Diameter Credit-Control Application (130 pages) RFC8581: Diameter Agent Overload and the Peer Overload Report (19 pages) RFC8582: Diameter Overload Rate Control (20 pages) RFC8583: Diameter Load Information Conveyance (23 pages) Dispatch (dispatch) ------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Ben Campbell Patrick McManus Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba 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: Apr 2018 - EMCAscript Media Type Updates to IESG for publication as Informational Internet-Drafts: - ECMAScript Media Types Updates [draft-ietf-dispatch-javascript-mjs-07] (27 pages) No Requests for Comments Domain-based Message Authentication, Reporting & Conformance (dmarc) -------------------------------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Alexey Melnikov Seth Blank Tim Wicinski Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba 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: - Interoperability Issues Between DMARC and Indirect Email Flows [draft-dmarc-interoperability-00] (16 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) - Email Authentication for Internationalized Mail [draft-ietf-dmarc-eaiauth-06] (6 pages) - Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows [draft-ietf-dmarc-interoperability-18] (27 pages) - DMARC (Domain-based Message Authentication, Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) [draft-ietf-dmarc-psd-08] (15 pages) - Message Header Field for Indicating Message Authentication Status [draft-ietf-dmarc-rfc7601bis-06] (54 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) Distributed Mobility Management (dmm) ------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Dapeng Liu 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: Nov 2015 - Submit 'Enhanced mobility anchoring' submitted to the IESG. Nov 2015 - Submit 'Forwarding path and signaling management' submitted to the IESG. Feb 2016 - Submit 'Exposing mobility state to mobile nodes and network nodes' submitted to the IESG. Mar 2016 - 'RFC4283bis on MN-IDs as a working group document' submitted to the IESG. Nov 2016 - RFC5149bis on Service Selection as a working group document Mar 2017 - RFC5149bis submitted to IESG. Done - Submit 'Enhanced mobility anchoring' as a working group document. Done - Submit 'Forwarding path and signaling management' 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-03] (39 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] (21 pages) - Protocol for Forwarding Policy Configuration (FPC) in DMM [draft-ietf-dmm-fpc-cpdp-13] (33 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] (29 pages) - Requirements for Distributed Mobility Management [draft-ietf-dmm-requirements-17] (24 pages) - Segment Routing IPv6 for Mobile User Plane [draft-ietf-dmm-srv6-mobile-uplane-07] (29 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) 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) Domain Name System Operations (dnsop) ------------------------------------- Charter Last Modified: 2020-04-20 Current Status: Active Chairs: Benno Overeinder Suzanne Woolf Tim Wicinski Operations and Management Area Directors: Warren Kumari Robert Wilton 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) - The .onion Special-Use Domain Name [draft-appelbaum-dnsop-onion-tld-01] (6 pages) - DNS Multiple QTYPEs [draft-bellis-dnsext-multi-qtypes-06] (7 pages) - DNS Session Signaling [draft-bellis-dnsop-session-signal-02] (13 pages) - DNS query name minimisation to improve privacy [draft-bortzmeyer-dns-qname-minimisation-02] (6 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-rfc7816bis-00] (12 pages) - DNS Scoped Data Through '_Underscore' Attribute Leaves [draft-crocker-dns-attrleaf-07] (13 pages) - DNS Transport over TCP - Implementation Requirements [draft-dickinson-dnsop-5966-bis-00] (12 pages) - C-DNS: A DNS Packet Capture Format [draft-dickinson-dnsop-dns-capture-format-00] (37 pages) - Providing Minimal-Sized Responses to DNS Queries with QTYPE=ANY [draft-dnsop-refuse-any-00] (16 pages) - Secret Key Transaction Authentication for DNS (TSIG) [draft-dupont-dnsop-rfc2845bis-01] (23 pages) - 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) - Security Considerations for RFC5011 Publishers [draft-hardaker-rfc5011-security-considerations-04] (9 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-dnsop-ip6rdns-00] (14 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) - Multi Provider DNSSEC models [draft-huque-dnsop-multi-provider-dnssec-04] (11 pages) - A Sentinel for Detecting Trusted Keys in DNSSEC [draft-huston-kskroll-sentinel-04] (8 pages) - Domain Name System (DNS) Security Key Rollover [draft-ietf-dnsind-rollover-00] (11 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] (13 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-12] (11 pages) - Address-specific DNS aliases (ANAME) [draft-ietf-dnsop-aname-04] (17 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) - Observed DNS Resolution Misbehavior [draft-ietf-dnsop-bad-dns-res-06] (18 pages) - Child-to-Parent Synchronization in DNS [draft-ietf-dnsop-child-syncronization-07] (15 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-00] (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 Response Policy Zones (RPZ) [draft-ietf-dnsop-dns-rpz-00] (30 pages) - DNS Transport over TCP - Operational Requirements [draft-ietf-dnsop-dns-tcp-requirements-06] (27 pages) - DNS Terminology [draft-ietf-dnsop-dns-terminology-05] (27 pages) - An Proxy Use Case of DNS over HTTPS [draft-ietf-dnsop-dns-wireformat-http-03] (6 pages) - Message Digest for DNS Zones [draft-ietf-dnsop-dns-zone-digest-07] (33 pages) - A Framework for DNSSEC Policies and DNSSEC Practice Statements [draft-ietf-dnsop-dnssec-dps-framework-11] (27 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) - DNSSEC Trust Anchor Configuration and Maintenance [draft-ietf-dnsop-dnssec-trust-anchor-04] (14 pages) - DNSSEC Trust Anchor History Service [draft-ietf-dnsop-dnssec-trust-history-02] (11 pages) - DNSSEC Implementation in the CAIRN Testbed [draft-ietf-dnsop-dnsseccairn-00] (22 pages) - IP Addresses that should never appear in the public DNS [draft-ietf-dnsop-dontpublish-unreachable-03] (0 pages) - 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] (15 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-01] (13 pages) - Encouraging the use of DNS IN-ADDR Mapping [draft-ietf-dnsop-inaddr-required-07] (7 pages) - An Interim Scheme for Signing the Public DNS Root [draft-ietf-dnsop-interim-signed-root-01] (0 pages) - Reverse DNS in IPv6 for Internet Service Providers [draft-ietf-dnsop-ip6rdns-00] (16 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) - Requirements for Automated Key Rollover in DNSsec [draft-ietf-dnsop-key-rollover-requirements-02] (8 pages) - Handling of DNS Zone Signing Keys [draft-ietf-dnsop-keyhand-04] (9 pages) - A Root Key Trust Anchor Sentinel for DNSSEC [draft-ietf-dnsop-kskroll-sentinel-17] (19 pages) - Let 'localhost' be localhost. [draft-ietf-dnsop-let-localhost-be-localhost-02] (10 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] (15 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] (26 pages) - Aggressive Use of DNSSEC-Validated Cache [draft-ietf-dnsop-nsec-aggressiveuse-10] (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) - Root Name Servers with Inter Domain Anycast Addresses [draft-ietf-dnsop-ohta-shared-root-server-03] (5 pages) - Testing Root Name Servers with Inter Domain Anycast Addresses [draft-ietf-dnsop-ohta-shared-root-server-test-00] (3 pages) - The ".onion" Special-Use Domain Name [draft-ietf-dnsop-onion-tld-01] (7 pages) - Parent's SIG over child's KEY [draft-ietf-dnsop-parent-sig-00] (0 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) - DNS Resolver Information Self-publication [draft-ietf-dnsop-resolver-information-01] (9 pages) - Initializing a DNS Resolver with Priming Queries [draft-ietf-dnsop-resolver-priming-11] (7 pages) - Rollover of statically configured resolver keys [draft-ietf-dnsop-resolver-rollover-00] (9 pages) - DNS Referral Response Size Issues [draft-ietf-dnsop-respsize-15] (21 pages) - Considerations for the use of DNS Reverse Mapping [draft-ietf-dnsop-reverse-mapping-considerations-06] (15 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-08] (29 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) - 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-04] (16 pages) - Domain Name System (DNS) Security Key Rollover [draft-ietf-dnsop-rollover-01] (11 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) - Serving Stale Data to Improve DNS Resiliency [draft-ietf-dnsop-serve-stale-10] (12 pages) - Interoperable Domain Name System (DNS) Server Cookies [draft-ietf-dnsop-server-cookies-02] (16 pages) - Requirements for a Mechanism Identifying a Name Server Instance [draft-ietf-dnsop-serverid-08] (8 pages) - DNS Stateful Operations [draft-ietf-dnsop-session-signal-20] (64 pages) - Distributing Root Name Servers via Shared Unicast Addresses [draft-ietf-dnsop-shared-root-server-01] (4 pages) - Special-Use Domain Names Problem Statement [draft-ietf-dnsop-sutld-ps-08] (25 pages) - Service binding and parameter specification via the DNS (DNS SVCB and HTTPSSVC) [draft-ietf-dnsop-svcb-httpssvc-02] (36 pages) - DNS Terminology [draft-ietf-dnsop-terminology-bis-14] (50 pages) - Terminology for DNS Transports and Location [draft-ietf-dnsop-terminology-ter-01] (3 pages) - IPv4-to-IPv6 migration and DNS name space fragmentation [draft-ietf-dnsop-v6-name-space-fragmentation-01] (0 pages) - Ordering of RRSets in DNS Messages [draft-jabley-dnsop-ordered-answers-00] (12 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) - 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) - Definition and Use of DNSSEC Negative Trust Anchors [draft-livingood-dnsop-negative-trust-anchors-01] (17 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) - DNS message checksums [draft-muks-dnsop-dns-message-checksums-01] (9 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) - DNS Resolver Information Self-publication [draft-sah-resolver-information-02] (9 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) - DNS Response Policy Zones (RPZ) [draft-vixie-dns-rpz-04] (30 pages) - DNS Delegation Requirements [draft-wallstrom-dnsop-dns-delegation-requirements-03] (20 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) - 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) - Returning extra answers in DNS responses. [draft-wkumari-dnsop-multiple-responses-05] (9 pages) - Decreasing Access Time to Root Servers by Running One on Loopback [draft-wkumari-dnsop-root-loopback-02] (9 pages) - BULK DNS Resource Records [draft-woodworth-bulk-rr-09] (16 pages) - Algorithm Implementation Requirements and Usage Guidance for DNSSEC [draft-wouters-sury-dnsop-algorithm-update-02] (9 pages) - A DNS Query including A Main Question with Accompanying Questions [draft-yao-dnsop-accompanying-questions-04] (11 pages) Requests for Comments: BCP123: Observed DNS Resolution Misbehavior (18 pages) BCP140: Preventing Use of Recursive Nameservers in Reflector Attacks (7 pages) BCP163: Locally Served DNS Zones (10 pages) BCP207: DNSSEC Roadblock Avoidance (19 pages) BCP209: Initializing a DNS Resolver with Priming Queries (7 pages) BCP219: DNS Terminology (50 pages) BCP222: Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves (15 pages) BCP40: Root Name Server Operational Requirements (10 pages) BCP91: DNS IPv6 Transport Operational Guidelines (5 pages) 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) 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 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) RFC7719: DNS Terminology (27 pages) * Obsoletes RFC8499 RFC7766: DNS Transport over TCP - Implementation Requirements (19 pages) * Updates RFC8490 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) 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) 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) 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) 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) 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) RFC8749: Moving DNSSEC Lookaside Validation (DLV) to Historic Status (6 pages) RFC8767: Serving Stale Data to Improve DNS Resiliency (12 pages) Extensions for Scalable DNS Service Discovery (dnssd) ----------------------------------------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Barbara Stark David Schinazi Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: dnssd@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dnssd Archive: https://mailarchive.ietf.org/arch/browse/dnssd/ Description of Working Group: Background ---------- Zero configuration networking protocols are currently well suited to discover services within the scope of a single link. In particular, the DNS-SD [RFC 6763] and mDNS [RFC6762] protocol suite (sometimes referred to using Apple Computer Inc.'s trademark, Bonjour) are widely used for DNS-based service discovery and host name resolution on a single link. The DNS-SD/mDNS protocol suite is used in many scenarios including home, campus, and enterprise networks. However, the zero configuration mDNS protocol is constrained to link-local multicast scope by design, and therefore cannot be used to discover services on remote links. In a home network that consists of a single (possibly bridged) link, users experience the expected discovery behavior; available services appear because all devices share a common link. However, in multi-link home networks (as envisaged by the homenet WG) or in routed campus or enterprise networks, devices and users can only discover services on the same link, which is a significant limitation. This has led to calls, such as the Educause petition, to develop an appropriate service discovery solution to span multiple links or to perform discovery across a wide area, not necessarily on directly connected links. In addition, the "Smart Energy Profile 2 Application Protocol Standard", published by ZigBee Alliance and HomePlug Powerline Alliance specifies the DNS-SD/mDNS protocol suite as the basis for its method of zero configuration service discovery. However, its use of wireless mesh multi-link subnets in conjunction with traditional routed networks will require extensions to the DNS-SD/mDNS protocols to allow operation across multiple links. The scenarios in which multi-link service discovery is required may be zero configuration environments, environments where administrative configuration is supported, or a mixture of the two. As demand for service discovery across wider area routed networks grows, some vendors are beginning to ship proprietary solutions. It is thus both timely and important that efforts to develop improved, scalable, autonomous service discovery solutions for routed networks are coordinated towards producing a single, standards-based solution. Working Group Description ------------------------- The focus of the WG is to develop a solution for extended, scalable DNS-SD. This work is likely to highlight problems and challenges with naming protocols, as some level of coexistence will be required between local zero configuration name services and those forming part of the global DNS. It is important that these issues are captured and documented for further analysis; solving those problems is however not within the scope of this WG. The WG will consider the tradeoffs between reusing/extending existing protocols and developing entirely new ones. It is highly desirable that any new solution is backwardly compatible with existing DNS-SD/mDNS deployments. Any solution developed by the dnssd WG must not conflict or interfere with the operation of other zero-configuration service and naming protocols such as uPnP or LLMNR. Integration with such protocols is out of scope for this WG. Current zero configuration discovery protocols are constrained to operate within a single link, which implicitly limits the scope of discovery. In extending service discovery protocols to operate over multiple links, devices will inherently become discoverable over a wider area, which may introduce security or privacy concerns. The WG will consider such concerns when exploring the solution space for multi-link service discovery. To that end, the primary goals of the dnssd WG are as follows: 1. To document a set of requirements for scalable, autonomous DNS-based service discovery in routed, multi-link networks in the following five scenarios: (A) Personal Area networks, e.g., one laptop and one printer. This is the simplest example of a service discovery network, and may or may not have external connectivity. (B) Home networks, as envisaged by the homenet WG, consisting of one or more exit routers, with one or more upstream providers or networks, and an arbitrary internal topology with heterogeneous media where routing is automatically configured. The home network would typically be a single zero configuration administrative domain with a relatively limited number of devices. (C) Wireless 'hotspot' networks, which may include wireless networks made available in public places, or temporary or permanent infrastructures targeted towards meeting or conference style events, e.g., as provided for IETF meetings. In such environments other devices may be more likely to be 'hostile' to the user. (D) Enterprise networks, consisting of larger routed networks, with large numbers of devices, which may be deployments spanning over multiple sites with multiple upstreams, and one more more administrative domains (depending on internal administrative delegation). The large majority of the forwarding and security devices are configured. These may be commercial or academic networks, with differing levels of administrative control over certain devices on the network, and BYOD devices commonplace in the campus scenario. (E) Mesh networks such as RPL/6LoWPAN, with one or more links per routable prefix, which may or may not have external connectivity. The topology may use technologies including 802.11 wireless, HomePlug AV and GP, and ZigBee IP. In the above scenarios, the aim is to facilitate service discovery across the defined site. It is also desirable that a user or device, when away from such a site, is still able to discover services within that site, e.g. a user discovering services in their home network while remote from it. It is also desirable that multiple discovery scopes are supported, from the point of view of either performing discovery within a specified scope or advertisement within a specified scope, and being able to discover (enumerate) the set of scopes such that an application could then choose to do either. It should be noted that scope in this sense might refer to 'building' or 'room' and thus might have no correlation to network topology. 2. To develop an improved, scalable solution for service discovery that can operate in multi-link networks, where devices may be in neighboring or non-neighboring links, applicable to the scenarios above. The solution will consider tradeoffs between reusing/extending existing protocols and developing entirely new protocols. The solution should include documentation or definition of the interfaces that can be implemented, separately to transport of the information. 3. To document challenges and problems encountered in the coexistence of zero configuration and global DNS name services in such multi-link networks, including consideration of both the name resolution mechanism and the namespace. It is important that the dnssd WG takes input from stakeholders in the scenarios it is considering. For example, the homenet WG is currently evaluating its own requirements for naming and service discovery; it is up to the homenet WG as to whether it wishes to recommend adoption of the solution developed in the dnssd WG, but coordination between the WGs is desirable. Goals and Milestones: May 2017 - Submit DNS Push draft to the IESG as Standards Track RFC Jul 2017 - Adopt hybrid-proxy implementation draft as WG document Jul 2017 - Adopt DNS-SD Advertising Proxy draft as a WG document Sep 2017 - Submit Privacy Extensions for DNS-SD draft to the IESG as Standards Track RFC Sep 2017 - Submit Device Pairing Using Short Authentication Strings draft to the IESG as Standards Track RFC Dec 2017 - Submit DNS-SD Advertising Proxy draft to the IESG as Standards Track RFC Mar 2018 - Submit DNS-SD Deployment for campus/enterprise networks draft to the IESG as a BCP document 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 wide-area service discovery solution draft as WG document Done - Adopt Informational document on the problems and challenges arising for zeroconf and unicast DNS name services 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 wide-area service discovery solution draft to the IESG as Standards Track RFC Internet-Drafts: - 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) - Discovery Proxy for Multicast DNS-Based Service Discovery [draft-ietf-dnssd-hybrid-10] (39 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-02] (29 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-SD Privacy and Security Requirements [draft-ietf-dnssd-prireq-08] (20 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] (42 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-02] (23 pages) - Device Pairing Using Short Authentication Strings [draft-kaiser-dnssd-pairing-00] (20 pages) - Multicast DNS Discovery Relay [draft-sctl-dnssd-mdns-relay-04] (20 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) DDoS Open Threat Signaling (dots) --------------------------------- Charter Last Modified: 2019-03-23 Current Status: Active Chairs: Liang Xia Valery Smyslov Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Benjamin Kaduk Mailing Lists: General Discussion: dots@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dots Archive: https://mailarchive.ietf.org/arch/browse/dots/ Description of Working Group: The aim of DDoS Open Threat Signaling (DOTS) is to develop a standards based approach for the realtime signaling of DDoS related telemetry and threat handling requests and data between elements concerned with DDoS attack detection, classification, traceback, and mitigation. The elements may be described as: * On-premise DDoS mitigation platforms * Service provider DDoS mitigation platforms * Other network elements and services with the ability to analyze and/or influence network traffic Elements may participate in DDoS detection, classification, traceback and mitigation individually or within the context of a larger collaborative system. These elements may be communicating inter-domain or intra-domain over links that may be congested by attack traffic resulting in potentially hostile conditions for any type of upstream signaling, in particular transport protocols that yield to congestion, and more generalized signaling and telemetry solutions. Robustness under these conditions is paramount while ensuring appropriate regard for authentication, authorization, privacy and data integrity. Elements may be deployed as part of a wider strategy incorporating multiple points of DDoS detection, classification, traceback and mitigation, both on premise or service provider based. Should changing conditions necessitate altering the specifics of mitigation actions and/or the topological scope of mitigation coverage, timely and effective signaling of telemetry and current threat status to all elements involved in the mitigation is essential. Feedback between participating elements is required for increased awareness supporting effective decision making. The WG will, where appropriate, reuse or extend existing standard protocols and mechanisms (for example, IPFIX and its associated templating and extension mechanisms). Any modification of or extension to existing protocols must be in close coordination with the working groups responsible for the protocol being modified, and may be done in this working group after agreement with all the relevant WGs and responsible Area Directors. The WG may coordinate on a situationally appropriate basis with other working groups and initiatives which compliment the DOTS effort e.g. M3AAWG, SACM, MILE, SUPA, I2NSF et. al. The WG will document requirements for the transport protocol to be used for the signaling of DOTS and consult with the Transport Area about the requirements and, if applicable, any new development of an encapsulation scheme for DOTS. The working group may develop an applicability statement (architecture document) explaining how all these elements should communicate together for a complete DDoS service. The charter of the working group is to produce one or more standards track specifications to provide for this open signaling in the DDoS problem space. While the resulting standards should be designed so they apply to network security applications beyond the DDoS problem space, this working group will focus on signaling and coordination mechanisms directly related to DDoS attack detection, classification, traceback and mitigation, incorporating the general principles articulated in RFC5218 . Focusing the WG efforts on DDoS is intended to meet the community's desire for a deployable solution in the near term. The specification(s) produced by the WG will include a standard mechanism for authentication and authorization, data integrity, and providing for privacy in operation, with privacy-friendly choices being the default in all cases. The WG will produce the following deliverables and milestones: * Document or Documents describing the problem space, use cases, protocol requirements and other qualifying information as the WG sees fit. * Document or Documents specifying protocols and associated data models to address the stated goals of the WG. Goals and Milestones: Done - Requirements document to WGLC Done - Use case document to WGLC Done - Signal channel document as proposed standard to WGLC Done - Data channel document as proposed standard to WGLC Done - Architecture document to WGLC Internet-Drafts: - Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS) [draft-boucadair-dots-multihoming-04] (14 pages) - Distributed-Denial-of-Service Open Threat Signaling (DOTS) Server Discovery [draft-boucadair-dots-server-discovery-05] (25 pages) - Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture [draft-ietf-dots-architecture-18] (33 pages) - Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification [draft-ietf-dots-data-channel-31] (75 pages) - Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS) [draft-ietf-dots-multihoming-03] (15 pages) - DDoS Open Threat Signaling (DOTS) Requirements [draft-ietf-dots-requirements-22] (22 pages) - Distributed-Denial-of-Service Open Threat Signaling (DOTS) Agent Discovery [draft-ietf-dots-server-discovery-10] (24 pages) - Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home [draft-ietf-dots-signal-call-home-08] (37 pages) - Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification [draft-ietf-dots-signal-channel-41] (108 pages) - Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel [draft-ietf-dots-signal-filter-control-03] (26 pages) - Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry [draft-ietf-dots-telemetry-08] (107 pages) - Use cases for DDoS Open Threat Signaling [draft-ietf-dots-use-cases-21] (15 pages) - Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry [draft-reddy-dots-telemetry-04] (41 pages) Requests for Comments: RFC8612: DDoS Open Threat Signaling (DOTS) Requirements (22 pages) DNS PRIVate Exchange (dprive) ----------------------------- Charter Last Modified: 2019-03-27 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: Mar 2020 - Submit draft on operating DNS privacy services for publication (BCP) Aug 2020 - Submit draft on DNS privacy exchanges involving authoritative servers (Exp) Mar 2021 - Submit draft on DNS privacy performance metrics and actual measurements (Info) 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) - 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-09] (43 pages) - Specification for DNS over Transport Layer Security (TLS) [draft-ietf-dprive-dns-over-tls-09] (19 pages) - DNS over Datagram Transport Layer Security (DTLS) [draft-ietf-dprive-dnsodtls-15] (13 pages) - Specification of DNS over Dedicated QUIC Connections [draft-ietf-dprive-dnsoquic-00] (20 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) - 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-00] (10 pages) - DNS Privacy Considerations [draft-ietf-dprive-problem-statement-06] (17 pages) - DNS Privacy Considerations [draft-ietf-dprive-rfc7626-bis-05] (29 pages) - TLS for DNS: Initiation and Performance Considerations [draft-ietf-dprive-start-tls-for-dns-01] (18 pages) - DNS Zone Transfer-over-TLS [draft-ietf-dprive-xfr-over-tls-00] (19 pages) - Padding Profiles for EDNS(0) [draft-mayrhofer-dprive-padding-profile-00] (6 pages) - DNS over DTLS (DNSoD) [draft-wing-dprive-dnsodtls-01] (13 pages) Requests for Comments: RFC7626: DNS Privacy Considerations (17 pages) 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) Drone Remote ID Protocol (drip) ------------------------------- Charter Last Modified: 2020-03-12 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 2020 - Requirements and architecture drafts adopted by the WG Mar 2021 - Solution space documents 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) No Requests for Comments Delay/Disruption Tolerant Networking (dtn) ------------------------------------------ Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Marc Blanchet Rick Taylor Transport Area Directors: Martin Duke Magnus Westerlund Transport Area Advisor: Magnus Westerlund Secretary: Edward Birrane 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 Network Working Group (DTNWG) specifies mechanisms for data communications in the presence of long delays and/or intermittent connectivity. Delay-Tolerant Networking (DTN) protocols have been the subject of extensive research and development in the Delay-Tolerant Networking Research Group (DTNRG) of the Internet Research Task Force since 2002.  The key documents are the DTN Architecture  (RFC 4838), the Bundle Protocol (RFC 5050), Licklider Transmission Protocol (RFC 5326) and convergence layers (RFC 7122, 7242). Multiple independent implementations exist for these technologies and multiple deployments in space and terrestrial environments.  There is an increase interest in the commercial world for these technologies, for similar and different use cases, such as unmanned air vehicles.  In this context, there is a need to update the base specifications, i.e., RFC 5050, RFC 7122, RFC 7242, RFC 6257 and RFC 6260,  based on the deployment and implementation experience as well as the new use cases.  Moreover, there is also a need to have standards track documents for the market. Therefore, the purpose of this working group is to update the base specifications in light of implementation experience. The group shall do a review of deployment problems and lessons learned, come to consensus on the issues to be addressed in the base protocol documents, and update the specifications accordingly. The group shall not endeavour to change the underlying architecture or the bundle protocol principle. Work items are: o  Agree to a list of use cases for evolving the DTN specifications and     a list of work items to be worked on. o  Create updates to RFC5050, convergence layer RFCs, and security     (RFC6257), as standard track documents. o  Document a registry for DTN Service Identifiers. Goals and Milestones: Feb 2017 - Neighbor Discovery Feb 2017 - Network Management Requirements Feb 2017 - Key Management Requirements May 2017 - Registry of Service Identifiers May 2017 - Addressing Architecture Jul 2019 - RFC5050bis Jul 2019 - Bundle Security Protocol Jul 2019 - TCP CL update Oct 2019 - Custody Done - Use Cases for evolving the DTN specifications and list of work items to be worked on. Internet-Drafts: - Asynchronous Management Architecture [draft-ietf-dtn-ama-00] (27 pages) - Bundle-in-Bundle Encapsulation [draft-ietf-dtn-bibect-03] (14 pages) - Bundle Protocol Version 7 [draft-ietf-dtn-bpbis-24] (65 pages) - Bundle Protocol Security Specification [draft-ietf-dtn-bpsec-22] (39 pages) - BPSec Interoperability Security Contexts [draft-ietf-dtn-bpsec-interop-sc-01] (10 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-20] (67 pages) No Requests for Comments Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Allison Mankin Roger Marshall Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba 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: Aug 2017 - Submit ‘A LoST extension to return complete and similar location info‘ to the IESG for consideration as an Informational RFC Aug 2017 - Submit 'Validation of Locations Around a Planned Change' to the IESG for consideration as a Standards Track RFC Done - Informational RFC containing terminology definitions and the requirements Done - An Informational document describing the threats and security considerations Done - A Standards Track RFC describing how to identify a session set-up request is to an emergency response center Done - A Standards Track RFC describing how to route an emergency call based on location information Done - An Informational document describing the Mapping Protocol Architecture Done - Submit 'Location Hiding: Problem Statement and Requirements' to the IESG for consideration as an Informational RFC. Done - Submit 'Framework for Emergency Calling using Internet Multimedia' to the IESG for consideration as an Informational RFC. Done - Submit 'Best Current Practice for Communications Services in support of Emergency Calling' to the IESG for consideration as a BCP document Done - Submit 'LoST Extension for returning Boundary Information for Services' to the IESG for consideration as an Experimental RFC 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 'Additional Data related to a Call for Emergency Call Purposes' 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 ‘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 '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] (24 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) - 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-03] (17 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-08] (17 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) Requests for Comments: BCP181: Best Current Practice for Communications Services in Support of Emergency Calling (28 pages) 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 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) 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) EAP Method Update (emu) ----------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Joseph A. Salowey Mohit Sethi Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Roman Danyliw Mailing Lists: General Discussion: emu@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/emu Archive: https://mailarchive.ietf.org/arch/search/?email_list=emu Description of Working Group: The Extensible Authentication Protocol (EAP) [RFC 3748] 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 (v1.3) 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. At the same time, some new use cases for EAP have been identified. EAP is now more broadly used in mobile network authentication. The group will update existing EAP methods such as EAP-AKA' to stay in sync with updates to the referenced 3GPP specifications. RFC 7258 notes that pervasive monitoring is an attack. Forward secrecy is an important security property for modern protocols to thwart pervasive monitoring. The group will work on an extension to EAP-AKA' for providing PFS. 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. 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 bug 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. * Develop an extension to EAP-AKA' such that forward secrecy can be provided. There may also be privacy improvements that have become feasible with the introduction of recent identity privacy improvements in 3GPP networks. * 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. 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), and the 3GPP security architecture group (for EAP-AKA' work). Goals and Milestones: Nov 2019 - WG last call on operational recommendations for large certificate and chain sizes Nov 2019 - WG last call on definition of session identifiers for fast re- authentication in EAP-SIM and EAP-AKA Nov 2019 - WG adopts initial draft addressing the errata found in EAP-TEAP Nov 2019 - WG adopts initial draft on an EAP method for mutual authentication based on an OOB channel Nov 2019 - WG adopts draft providing guidance for use of TLS 1.3 with TLS based EAP methods Jan 2020 - WG adopts initial draft on creation of long-term credentials for EAP peer based on initial limited-use credentials Mar 2020 - WG last call on extension to EAP-AKA to support forward secrecy 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) - 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) - Perfect-Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' PFS) [draft-ietf-emu-aka-pfs-02] (26 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) - 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-00] (62 pages) - EAP Session-Id Derivation for EAP-SIM, EAP-AKA, and PEAP [draft-ietf-emu-eap-session-id-03] (9 pages) - Using EAP-TLS with TLS 1.3 [draft-ietf-emu-eap-tls13-09] (29 pages) - Tunnel Extensible Authentication Protocol (TEAP) Version 1 [draft-ietf-emu-eap-tunnel-method-10] (101 pages) - Handling Large Certificates and Long Certificate Chains in TLS-based EAP Methods [draft-ietf-emu-eaptlscert-03] (12 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-07] (50 pages) - TLS-based EAP types and TLS 1.3 [draft-ietf-emu-tls-eap-types-00] (10 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) 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) Email mailstore and eXtensions To Revise or Amend (extra) --------------------------------------------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Bron Gondwana Jiankang Yao Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba 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 2019 - Adopt a document for EAI with Sieve Dec 2019 - Submit "IMAP4rev2" to IESG as a Proposed Standard Feb 2020 - Submit "Quota BIS" to IESG as a Proposed Standard Apr 2020 - Update charter to reflect current and planned work 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 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) - 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-07] (15 pages) - IMAP4 Extension: Message Snippet Generation [draft-ietf-extra-imap-fetch-snippet-00] (10 pages) - IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST [draft-ietf-extra-imap-list-myrights-07] (6 pages) - IMAP Extension for Object Identifiers [draft-ietf-extra-imap-objectid-08] (16 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 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) - Internet Message Access Protocol (IMAP) - Version 4rev2 [draft-ietf-extra-imap4rev2-14] (159 pages) - IMAP QUOTA Extension [draft-ietf-extra-quota-00] (15 pages) - Sieve Extension: File Carbon Copy (FCC) [draft-ietf-extra-sieve-fcc-09] (12 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) General Area Dispatch (gendispatch) ----------------------------------- Charter Last Modified: 2019-10-18 Current Status: Active Chairs: Francesca Palombini Pete Resnick General Area Directors: Alissa Cooper General Area Advisor: Alissa Cooper 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. The working group is chartered to identify, or help create, an appropriate venue for the work. The working group will not consider any technical standardization work. Guiding principles for the 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 amongst published or ongoing work in the GEN area, within the IESG, or within the IETF LLC. 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 the the IESG or the IETF LLC consider taking up the work. - 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. 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 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 GENDISPATCH 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 GEN area is expected to be considered in the GENDISPATCH working group, there may be times where 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. Another major objective of the GENDISPATCH WG is to streamline how the IETF community considers process improvements. Community discussions about process suggestions that begin on other mailing lists, including ietf@ietf.org, will be redirected to the GENDISPATCH mailing list where they will be facilitated by the WG chairs. Proponents of process improvements will be encouraged to craft concrete proposals for discussion on the GENDISPATCH mailing list, with the goal of producing a concrete outcome in bounded time. Direct requests to the IESG may also, after proper consideration, be redirected to the WG. For proposals to be considered by the WG they will be expected to meet guiding principle #1 above. The existence of this working group 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. A review of the efficacy of this working group will be undertaken 18-24 months after its chartering. Goals and Milestones: Internet-Drafts: No Requests for Comments GitHub Integration and Tooling (git) ------------------------------------ Charter Last Modified: 2019-03-08 Current Status: Active Chairs: Christopher A. Wood Paul E. Hoffman General Area Directors: Alissa Cooper General Area Advisor: Alissa Cooper Mailing Lists: General Discussion: ietf-and-github@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ietf-and-github Archive: https://mailarchive.ietf.org/arch/browse/ietf-and-github/ Description of Working Group: Many IETF working groups use external code repository services, primarily GitHub, in managing their work. Individual working groups, while continuing to operate within IETF guidelines for working group activity, have developed their own policies and practices for how they use these services. These policies and practices cover aspects such as: managing discussion between working group mailing lists and GitHub issues and pull requests; how text contributions are expected to be made; labeling and naming conventions; maintaining readable draft snapshots; using tooling and automation; informing participants about IETF policies; and others. The GitHub Integration and Tooling (GIT) working group will select a set of such practices and document policies that support those practices. The policies will each detail how work is conducted by working groups that opt to follow the work practice. The goal is to provide both process and tooling support for working groups that choose to adopt the practices. The documents produced by this group may apply to services similar to GitHub. However, documenting generalized policies that are designed to apply to multiple services or policies specific to services besides GitHub are out of scope for this working group. Pursuing such work requires a re-charter. The documents produced by this group will not alter the Internet Standards Process (BCP 9). They will describe how to work within it. Whether working groups choose to use GitHub or the documented policies to support their work will remain entirely at their discretion. The working group may also discuss tooling requirements in support of GitHub use. Decisions about implementing specific tooling needs will be undertaken by the IETF Tools Team in consultation with working group participants and other interested contributors. Goals and Milestones: Aug 2019 - Work practice description and policy document(s) sent to IESG for publication as BCP Internet-Drafts: - Working Group GitHub Administration [draft-ietf-git-github-wg-configuration-07] (7 pages) - Working Group GitHub Usage Guidance [draft-ietf-git-using-github-06] (23 pages) No Requests for Comments Global Routing Operations (grow) -------------------------------- Charter Last Modified: 2020-03-18 Current Status: Active Chairs: Chris Morrow Job Snijders Operations and Management Area Directors: Warren Kumari Robert Wilton 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) - Bounding Longest Match Considered [draft-grow-bounded-longest-match-00] (8 pages) - Operation of Anycast Services [draft-ietf-grow-anycast-04] (24 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) - 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) - Support for Local RIB in BGP Monitoring Protocol (BMP) [draft-ietf-grow-bmp-local-rib-07] (15 pages) - BMP Peer Up Message Namespace [draft-ietf-grow-bmp-peer-up-00] (5 pages) - Revision to Registration Procedures for Multiple BMP Registries [draft-ietf-grow-bmp-registries-change-01] (3 pages) - TLV support for BMP Route Monitoring and Peer Down Messages [draft-ietf-grow-bmp-tlv-02] (6 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) - 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) - 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-02] (9 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) - 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: BCP105: Embedding Globally-Routable Internet Addresses Considered Harmful (10 pages) BCP114: BGP Communities for Data Collection (12 pages) BCP122: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan (27 pages) BCP126: Operation of Anycast Services (24 pages) BCP169: Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services (10 pages) BCP171: Time to Remove Filters for Previously Unallocated IPv4 /8s (5 pages) BCP214: Mitigating the Negative Impact of Maintenance through BGP Session Culling (10 pages) 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 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) Host Identity Protocol (hip) ---------------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chair: Gonzalo Camarillo Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: hipsec@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/hipsec Archive: https://mailarchive.ietf.org/arch/browse/hipsec/ Description of Working Group: The Host Identity Protocol (HIP) provides a method of separating the end-point identifier and locator roles of IP addresses. It introduces a new Host Identity (HI) name space, based on public keys, from which end-point identifiers are taken. The public keys are typically, but not necessarily, self generated. HIP uses existing IP addressing and forwarding for locators and packet delivery. The architecture and protocol details for these mechanisms are currently specified in the following Experimental RFCs: o HIP Architecture (RFC 4423) o Host Identity Protocol (RFC 5201) There are several publicly known interoperating implementations, some of which are open source. The HIP WG was chartered to publish protocol specifications in documents whose quality and security properties would meet the requirements for publication as standards track documents. These specifications have been published as Experimental RFCs, because the effects of the protocol on applications and on the Internet as a whole were unknown. The Experimental RFCs produced by the HIP WG allowed the community to experiment with HIP technologies and learn from these experiments. The HIP WG will now produce standards track versions of the main HIP RFCs taking as a base the existing Experimental RFCs. The WG will also specify certificate handling in HIP in a standards track RFC. Additionally, the WG will finish the WG items it was working on before starting the standards track work. These WG items relate to how to build HIP-based overlays and will result in Experimental RFCs. The following are charter items for the working group: o Revise RFCs 4423, 4843, 5201, 5202, 5203, 5204, 5205, 5206, and 5770 as standards track RFCs. o Specify in a standards track RFC how to carry certificates in the base exchange. This was removed from the base HIP spec so that the mechanism is specified in a stand-alone spec. o Specify in an Experimental RFC how to build a HIP-based overlay using RELOAD. o Specify in an Experimental RFC how to transport HIP messages over encrypted connections that were established using HIP. Goals and Milestones: Apr 2016 - Submit RFC5770bis to the IESG Jun 2016 - Submit the mobility portion of RFC5206bis to the IESG Jun 2016 - Submit the multihoming portion of RFC5206bis to the IESG Oct 2016 - WGLC RFC4423bis Dec 2016 - Submit RFC4423bis to the IESG Jan 2017 - Recharter or close the WG Done - Submit Native API specification to the IESG Done - Submit Framework for HIP overlays specification to the IESG Done - Submit Multi-hop routing mechanism for HIP Done - Submit Upper-layer data transport in HIP to the IESG Done - WGLC Certs in HIP base exchange specification Done - WGLC the HIP over HIP specification Done - Submit Certs in HIP base exchange to the IESG as Experimental Done - Submit the HIP over HIP specification to the IESG Done - WGLC the specification on how to build HIP-based overlays using RELOAD Done - Submit the specification on how to build HIP-based overlays using RELOAD to the IESG Done - WGLC RFC4843bis Done - WGLC RFC5201bis Done - WGLC RFC5202bis Done - Submit RFC5201bis to the IESG Done - Submit RFC4843bis to the IESG Done - Submit RFC5202bis to the IESG Done - WGLC RFC5203bis Done - WGLC RFC5204bis Done - WGLC RFC5205bis Done - Submit RFC5203bis to the IESG Done - Submit RFC5204bis to the IESG Done - Submit RFC5205bis to the IESG Done - WGLC RFC5770bis Done - WGLC Certs in HIP base exchange specification (referencing RFC5201bis) Done - Submit Certs in HIP base exchange (referencing RFC5201bis) to the IESG as PS Done - WGLC the mobility portion of RFC5206bis Done - WGLC the multihoming portion of RFC5206bis Internet-Drafts: - Using the Host Identity Protocol with Legacy Applications [draft-ietf-hip-applications-04] (14 pages) - Host Identity Protocol (HIP) Architecture [draft-ietf-hip-arch-03] (24 pages) - Host Identity Protocol [draft-ietf-hip-base-10] (104 pages) - HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE) [draft-ietf-hip-bone-07] (21 pages) - Host Identity Protocol Certificates [draft-ietf-hip-cert-12] (12 pages) - HIP Diet EXchange (DEX) [draft-ietf-hip-dex-19] (58 pages) - Host Identity Protocol (HIP) Domain Name System (DNS) Extensions [draft-ietf-hip-dns-09] (17 pages) - Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) [draft-ietf-hip-esp-06] (30 pages) - Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS) [draft-ietf-hip-hiccups-05] (17 pages) - End-Host Mobility and Multihoming with the Host Identity Protocol [draft-ietf-hip-mm-05] (40 pages) - Host Multihoming with the Host Identity Protocol [draft-ietf-hip-multihoming-12] (22 pages) - Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators [draft-ietf-hip-nat-traversal-09] (34 pages) - Basic Socket Interface Extensions for the Host Identity Protocol (HIP) [draft-ietf-hip-native-api-12] (18 pages) - Native NAT Traversal Mode for the Host Identity Protocol [draft-ietf-hip-native-nat-traversal-31] (65 pages) - Encrypted Signaling Transport Modes for the Host Identity Protocol [draft-ietf-hip-over-hip-06] (13 pages) - Host Identity Protocol (HIP) Registration Extension [draft-ietf-hip-registration-02] (13 pages) - Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD) [draft-ietf-hip-reload-instance-10] (10 pages) - Host Identity Protocol Architecture [draft-ietf-hip-rfc4423-bis-20] (50 pages) - An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) [draft-ietf-hip-rfc4843-bis-08] (14 pages) - Host Identity Protocol Version 2 (HIPv2) [draft-ietf-hip-rfc5201-bis-20] (128 pages) - Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) [draft-ietf-hip-rfc5202-bis-07] (40 pages) - Host Identity Protocol (HIP) Registration Extension [draft-ietf-hip-rfc5203-bis-11] (16 pages) - Host Identity Protocol (HIP) Rendezvous Extension [draft-ietf-hip-rfc5204-bis-08] (14 pages) - Host Identity Protocol (HIP) Domain Name System (DNS) Extension [draft-ietf-hip-rfc5205-bis-10] (18 pages) - Host Mobility with the Host Identity Protocol [draft-ietf-hip-rfc5206-bis-14] (37 pages) - Host Identity Protocol Certificates [draft-ietf-hip-rfc6253-bis-09] (13 pages) - Host Identity Protocol (HIP) Rendezvous Extension [draft-ietf-hip-rvs-05] (15 pages) - Host Identity Protocol (HIP) Multi-Hop Routing Extension [draft-ietf-hip-via-03] (10 pages) Requests for Comments: RFC4423: Host Identity Protocol (HIP) Architecture (24 pages) RFC5201: Host Identity Protocol (104 pages) * Updates RFC6253 * Obsoletes RFC7401 RFC5202: Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) (30 pages) * Obsoletes RFC7402 RFC5203: Host Identity Protocol (HIP) Registration Extension (13 pages) * Obsoletes RFC8003 RFC5204: Host Identity Protocol (HIP) Rendezvous Extension (15 pages) * Obsoletes RFC8004 RFC5205: Host Identity Protocol (HIP) Domain Name System (DNS) Extensions (17 pages) * Obsoletes RFC8005 RFC5206: End-Host Mobility and Multihoming with the Host Identity Protocol (40 pages) * Obsoletes RFC8046 RFC5338: Using the Host Identity Protocol with Legacy Applications (14 pages) RFC5770: Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators (34 pages) RFC6028: Host Identity Protocol (HIP) Multi-Hop Routing Extension (10 pages) RFC6078: Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS) (17 pages) RFC6079: HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE) (21 pages) RFC6253: Host Identity Protocol Certificates (12 pages) * Obsoletes RFC8002 RFC6261: Encrypted Signaling Transport Modes for the Host Identity Protocol (13 pages) RFC6317: Basic Socket Interface Extensions for the Host Identity Protocol (HIP) (18 pages) RFC7086: Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD) (10 pages) RFC7343: An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) (14 pages) RFC7401: Host Identity Protocol Version 2 (HIPv2) (128 pages) * Updates RFC8002 RFC7402: Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) (40 pages) RFC8002: Host Identity Protocol Certificates (13 pages) RFC8003: Host Identity Protocol (HIP) Registration Extension (16 pages) RFC8004: Host Identity Protocol (HIP) Rendezvous Extension (14 pages) RFC8005: Host Identity Protocol (HIP) Domain Name System (DNS) Extension (18 pages) RFC8046: Host Mobility with the Host Identity Protocol (37 pages) RFC8047: Host Multihoming with the Host Identity Protocol (22 pages) Home Networking (homenet) ------------------------- Charter Last Modified: 2019-06-04 Current Status: Active Chairs: Barbara Stark Stephen Farrell Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Tech Advisor: Acee Lindem Mailing Lists: General Discussion: homenet@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/homenet Archive: https://mailarchive.ietf.org/arch/browse/homenet/ Description of Working Group: This working group focuses on the evolving networking technology within and among relatively small "residential home" networks. For example, an obvious trend in home networking is the proliferation of networking technology in an increasingly broad range and number of devices. This evolution in scale and diversity sets some requirements on IETF protocols. Some of the relevant trends include: o Multiple segments: While less complex L3-toplogies involving as few subnets as possible are preferred in home networks for a variety of reasons including simpler management and service discovery, the introduction of more than one subnet into a home network is enough to add complexity that needs to be addressed, and multiple dedicated segments are necessary for some cases. For instance, a common feature in modern home routers in the ability to support both guest and private network segments. Also, link layer networking technology is poised to become more heterogeneous, as networks begin to employ both traditional Ethernet technology and link layers designed for low-powered sensor networks. Finally, similar needs for segmentation may occur in other cases, such as separating building control or corporate extensions from the Internet access network for the home. Different segments may be associated with subnets that have different routing and security policies. o Service providers are deploying IPv6, and support for IPv6 is increasingly available in home gateway devices. While IPv6 resembles IPv4 in many ways, it changes address allocation principles and allows direct IP addressability and routing to devices in the home from the Internet. This is a promising area in IPv6 that has proved challenging in IPv4 with the proliferation of NAT. o End-to-end communication is both an opportunity and a concern as it enables new applications but also exposes nodes in the internal networks to receipt of unwanted traffic from the Internet. Firewalls that restrict incoming connections may be used to prevent exposure, however, this reduces the efficacy of end-to-end connectivity that IPv6 has the potential to restore. Home networks need to provide the tools to handle these situations in a manner accessible to all users of home networks. Manual configuration is rarely, if at all, possible, as the necessary skills and in some cases even suitable management interfaces are missing. The purpose of this working group is to focus on this evolution, in particular as it addresses the introduction of IPv6, by developing an architecture addressing this full scope of requirements: o prefix configuration for routers o managing routing o name resolution o service discovery o network security The task of the group is to produce an architecture document that outlines how to construct home networks involving multiple routers and subnets. This document is expected to apply the IPv6 addressing architecture, prefix delegation, global and ULA addresses, source address selection rules and other existing components of the IPv6 architecture, as appropriate. The architecture document should drive what protocols changes, if any, are necessary. Specific protocol work described below is expected to be within the scope of the working group once the architecture work is complete. However, the group is required to review its charter and milestones with the IESG and IETF community before submitting documents that make protocol changes. It is expected that the group has to discuss some of the below solutions, however, in order to complete the architecture work. The group will apply existing protocols to handle the five requirements above. For prefix configuration, existing protocols are likely sufficient, and at worst may need some small enhancements, such as new options. For automatic routing, it is expected that existing routing protocols can be used as is, however, a new mechanism may be needed in order to turn a selected protocol on by default. For name resolution and service discovery, extensions to existing multicast-based name resolution protocols are needed to enable them to work across subnets. For network security, the group shall document the concept of "advanced security" as a further development of "simple security" from RFC 6092. The main goal of this work is to enable a security policy that adapts to IPv6 threats as they emerge, taking into account not only traffic from the Internet at large, but within and leaving the home network itself. It is expected that the working group will define a set of protocol specifications to accomplish the five requirements from above. However, it is not in the scope of the working group to define entirely new routing protocols or address allocation protocols. As noted, additional options or other small extensions may be necessary to use the existing protocols in these new configuration tasks. The working group shall also not make any changes to IPv6 protocols or addressing architecture. Prefix configuration, routing, and security related work shall not cause any changes that are not backwards compatible to existing IPv6 hosts. There may be host visible changes in the work on naming and discovery protocols, however. In its design, the working group shall also consider security aspects and the impact on manageability. The main focus of the working group is home networks, but the group's results may also find applications in other small networks. The group should assume that an IPv4 network may have to co-exist alongside the IPv6 network and should take this into account insofar as alignment with IPv6 is desirable. But the group should also ensure that even IPv6-only are possible, and while IP-version agnostic work is of course desirable, IPv4-specific work is outside the scope of the group. The working group will liaise with the relevant IETF working groups. In particular, the group should work closely with the V6OPS working group, review any use or extension of DHCP with the DHC working group, and work with additional DNS requirements with the DNSEXT and DNSOP working groups. If it turns out that additional options are needed for a routing protocol, they will be developed in the appropriate Routing Area working group, with the HOMENET working group providing the architecture and requirements for such enhancements. The working group will also liason with external standards bodies where it is expected that there are normative dependencies between the specifications of the two bodies. It is expected that in the architecture definition stage liaising with the Broadband Forum, DLNA, UPnP Forum, OASIS, ZigBee Alliance and other SDOs is necessary, as is understanding existing technology from these groups. Goals and Milestones: Nov 2018 - First WG draft on perimeter security Nov 2018 - Submission of the name resolution draft to the IESG as Standards Track RFC Mar 2019 - Submission of the service discovery draft to the IESG as Standards Track RFC Nov 2019 - Submission of the perimeter security draft to the IESG as Informational RFC Done - Formation of the working group Done - First WG draft on the architecture Done - Submission of the architecture draft to the IESG as Informational RFC Done - First WG draft on prefix configuration Done - First WG draft on routing Done - First WG draft on name resolution Done - First WG draft on service discovery Done - Start of routing related work in the relevant routing area working group, if needed Done - RFC 7695 - Submission of the prefix configuration draft to the IESG as Standards Track RFC Superceded - Submission of the routing draft to the IESG as Informational RFC Internet-Drafts: - Homenet profile of the Babel routing protocol [draft-chroboczek-homenet-babel-profile-00] (7 pages) - IPv6 Home Networking Architecture Principles [draft-ietf-homenet-arch-17] (49 pages) - Homenet profile of the Babel routing protocol [draft-ietf-homenet-babel-profile-07] (9 pages) - Distributed Node Consensus Protocol [draft-ietf-homenet-dncp-12] (41 pages) - Special-Use Domain 'home.arpa.' [draft-ietf-homenet-dot-14] (12 pages) - Outsourcing Home Network Authoritative Naming Service [draft-ietf-homenet-front-end-naming-delegation-11] (39 pages) - Home Networking Control Protocol [draft-ietf-homenet-hncp-10] (40 pages) - Home Networking Control Protocol [draft-ietf-homenet-hncp-bis-00] (38 pages) - Auto-Configuration of a Network of Hybrid Unicast/Multicast DNS-Based Service Discovery Proxy Nodes [draft-ietf-homenet-hybrid-proxy-zeroconf-02] (16 pages) - DHCPv6 Options for Home Network Authoritative Naming Service [draft-ietf-homenet-naming-architecture-dhc-options-07] (14 pages) - Distributed Prefix Assignment Algorithm [draft-ietf-homenet-prefix-assignment-08] (20 pages) - Redacting .home from HNCP [draft-ietf-homenet-redact-03] (3 pages) - Homenet Routing Consensus Call [draft-ietf-homenet-routing-consensus-call-01] (4 pages) - Homenet Naming and Service Discovery Architecture [draft-ietf-homenet-simple-naming-03] (23 pages) - Homenet Naming and Service Discovery Architecture [draft-lemon-homenet-naming-architecture-01] (21 pages) - Outsourcing Home Network Authoritative Naming Service [draft-mglt-homenet-front-end-naming-delegation-04] (21 pages) - DHCP Options for Homenet Naming Architecture [draft-mglt-homenet-naming-architecture-dhc-options-02] (24 pages) - Prefix and Address Assignment in a Home Network [draft-pfister-homenet-prefix-assignment-02] (29 pages) - Home Networking Control Protocol [draft-stenberg-homenet-hncp-00] (27 pages) - Simple Homenet Naming and Service Discovery Architecture [draft-tldm-simple-homenet-naming-01] (9 pages) Requests for Comments: RFC7368: IPv6 Home Networking Architecture Principles (49 pages) RFC7695: Distributed Prefix Assignment Algorithm (20 pages) RFC7787: Distributed Node Consensus Protocol (41 pages) RFC7788: Home Networking Control Protocol (40 pages) * Updates RFC8375 RFC8375: Special-Use Domain 'home.arpa.' (12 pages) HTTP (httpbis) -------------- Charter Last Modified: 2019-11-03 Current Status: Active Chairs: Mark Nottingham Tommy Pauly Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba Mailing Lists: General Discussion: ietf-http-wg@w3.org To Subscribe: ietf-http-wg-request@w3.org Archive: http://lists.w3.org/Archives/Public/ietf-http-wg/ Description of Working Group: This Working Group is charged with maintaining and developing the "core" specifications for HTTP, 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: Jun 2020 - Submit the "core" HTTP documents for consideration as Internet Standards - Submit RFC6265bis (Cookies) - Submit Client Hints - Submit Structured Headers - Submit Secondary Certificates - Submit Building Protocols with HTTP (BCP56bis) - Submit HTTP Representation Variants - Submit Cache-Status Header - Submit Proxy-Status Header - Submit Digest Headers Internet-Drafts: - Secondary Certificate Authentication in HTTP/2 [draft-bishop-httpbis-http2-additional-certs-05] (21 pages) - Using TLS 1.3 with HTTP/2 [draft-davidben-http2-tls13-00] (4 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) - 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-09] (32 pages) - HTTP Caching [draft-ietf-httpbis-cache-07] (43 pages) - Cache Digests for HTTP/2 [draft-ietf-httpbis-cache-digest-05] (17 pages) - The Cache-Status HTTP Response Header Field [draft-ietf-httpbis-cache-header-03] (8 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) - HTTP Client Hints [draft-ietf-httpbis-client-hints-13] (12 pages) - HTTP Conditional Requests [draft-ietf-httpbis-conditional-01] (4 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 Headers [draft-ietf-httpbis-digest-headers-02] (33 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] (23 pages) - Bootstrapping WebSockets with HTTP/2 [draft-ietf-httpbis-h2-websockets-07] (8 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-18] (41 pages) - Hypertext Transfer Protocol Version 2 (HTTP/2) [draft-ietf-httpbis-http2-17] (96 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) - Signing HTTP Messages [draft-ietf-httpbis-message-signatures-00] (38 pages) - HTTP/1.1 Messaging [draft-ietf-httpbis-messaging-07] (59 pages) - Initial Hypertext Transfer Protocol (HTTP) Method Registrations [draft-ietf-httpbis-method-registrations-15] (5 pages) - The ORIGIN HTTP/2 Frame [draft-ietf-httpbis-origin-frame-06] (11 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-00] (19 pages) - The Proxy-Status HTTP Response Header Field [draft-ietf-httpbis-proxy-status-01] (18 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) - 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-06] (53 pages) - The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) [draft-ietf-httpbis-rfc7238bis-03] (6 pages) - Security Requirements for HTTP [draft-ietf-httpbis-security-properties-05] (14 pages) - HTTP Semantics [draft-ietf-httpbis-semantics-07] (206 pages) - The ALPN HTTP Header Field [draft-ietf-httpbis-tunnel-protocol-05] (7 pages) - HTTP Representation Variants [draft-ietf-httpbis-variants-06] (23 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) - The ORIGIN HTTP/2 Frame [draft-nottingham-httpbis-origin-frame-01] (4 pages) - The Proxy-Status HTTP Header Field [draft-nottingham-proxy-status-00] (17 pages) - Signing HTTP Messages [draft-richanna-http-message-signatures-00] (38 pages) - Reactive Certificate-Based Client Authentication in HTTP/2 [draft-thomson-http2-client-certs-02] (19 pages) - Same-site Cookies [draft-west-first-party-cookies-07] (14 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 RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content (101 pages) RFC7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests (28 pages) RFC7233: Hypertext Transfer Protocol (HTTP/1.1): Range Requests (25 pages) RFC7234: Hypertext Transfer Protocol (HTTP/1.1): Caching (43 pages) RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication (19 pages) 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) RFC7540: Hypertext Transfer Protocol Version 2 (HTTP/2) (96 pages) * Updates RFC8740 RFC7541: HPACK: Header Compression for HTTP/2 (55 pages) RFC7615: HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields (6 pages) RFC7639: The ALPN HTTP Header Field (7 pages) RFC7694: Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding (7 pages) 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) Interface to Network Security Functions (i2nsf) ----------------------------------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Linda Dunbar Yoav Nir Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Roman Danyliw Mailing Lists: General Discussion: i2nsf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/i2nsf Archive: https://mailarchive.ietf.org/arch/browse/i2nsf/ Description of Working Group: A Network Security Function (NSF) is a function used to ensure integrity, confidentiality, or availability of network communications, to detect unwanted network activity, or to block or at least mitigate the effects of unwanted activity. NSFs are provided and consumed in increasingly diverse environments. Users could consume network security services enforced by NSFs hosted by one or more providers, which may be their own enterprise, service providers, or a combination of both. Similarly, service providers may offer their customers network security services that are enforced by multiple security products, functions from different vendors, or open source technologies. NSFs may be provided by physical and/or virtualized infrastructure. Without standard interfaces to control and monitor the behavior of NSFs, it has become virtually impossible for providers of security services to automate service offerings that utilize different security functions from multiple vendors. The goal of I2NSF is to define a set of software interfaces and data models for controlling and monitoring aspects of physical and virtual NSFs, enabling clients to specify rulesets. If the working group finds it necessary to work on an information model before the data models, to help provide guidance and derive the data models, it may do so. The working group will decide later whether the information model needs to be published as an RFC. Other aspects of NSFs, such as device or network provisioning and configuration, are out of scope. As there are many different security vendors or open source technologies supporting different features and functions on their devices, I2NSF will focus on flow-based NSFs that provide treatment to packets/flows, such as Intrusion Protection/Detection System (IPS/IDS), web filtering, flow filtering, deep packet inspection, or pattern matching and remediation. Controlling and monitoring aspects of NSFs include the ability to specify rules (by a single controller at the first phase), query, and monitor NSFs by one or more management entities. The initial phase of I2NSF will only consider one single controller that can specify or change rules to NSFs because multi-headed control requires the coordination to avoid potential conflict of rules. The NSFs can be monitored by multiple entities, but the database update and synchronization among multiple management entities are out of scope for I2NSF. I2NSF will specify interfaces at two functional levels for the control and monitoring of network security functions: The I2NSF Capability Layer specifies how to control and monitor NSFs at a functional implementation level. The term "Functional Implementation" is used to emphasize that the rules (for control and monitor) of NSFs have to be implementable by most NSFs. I2NSF will standardize a set of interfaces by which a security controller can invoke, operate, and monitor NSFs. The I2NSF Service Layer defines how clients' security policies may be expressed to a security controller. The controller implements its policies according to the various capabilities provided by the I2NSF Capability Layer. The I2NSF Service Layer also allows the client to monitor the client specific policies. A client may leverage the I2NSF Service Layer interface to express security policies to a security controller, which in turn interacts with one or more NSFs through the I2NSF Capability Layer interface. Alternatively, a client may interact with one or more NSFs directly through the I2NSF Capability Layer interface. Since there could be many depths or types of Service Layer policies, the following bullets further clarify the scope of I2NSF: o Only the simple Service Layer policies that are modeled as closely as possible on the Capability Layer are within the scope. Simple Service Layer policies can be directly translated to capability layer rules with a direct mapping that might include a customer ID to be translated to tags carried by packets, but might not specify the NSF. This flexibility in the simple Service Layer enables a security controller to handle issues like multi-tenancy and the choice between available NSFs for a given policy. o I2NSF will not specify abstract or sophisticated policies from clients. Expressing policies in ways other than the model used by the Capability Layer is out of scope. o The translation mechanism/methods from Service Layer policies to Capability layer commands are out of scope for I2NSF. However, I2NSF will provide a discussion forum for Informational drafts on data models, APIs, etc. that demonstrate how more complex Service Layer policies and formats may be translated to Capability Layer functions. Such documents would be pursued outside the WG. Standard interfaces for monitoring and controlling the behavior of NSFs are essential building blocks for providers of security service to automate the use of different NSFs from multiple vendors. This work will leverage the existing protocols and data models defined by the I2RS, NETCONF, and NETMOD working groups. If extensions to these protocols or data models are needed, requirements will be developed by this WG, and the extensions will be developed in cooperation with the working groups responsible for the protocols. The I2NSF working group's deliverables include: o A single document covering use cases, problem statement, and gap analysis document. This document will initially be produced for reference as a living list to track and record discussions: the working group may decide to not publish this document as an RFC. o A framework document, presenting an overview of the use of NSFs and the purpose of the models developed by the working group. This document will also be a reference text to guide the main work and the working group may decide to not publish this document as an RFC. o If the working group considers it necessary, a single, unified, Information Model to describe the control and monitoring of flow-based NSFs. o YANG data models for the control and monitoring of NSFs. o A vendor-neutral vocabulary to enable the characteristics and behavior of NSFs to be specified without requiring the NSFs themselves to be standardized, so that "security controller" or "manager" have a common base to choose the appropriate NSFs (by different vendors) that can fulfill the requests requested by clients. o An examination of existing secure communication mechanisms to identify the appropriate ones for carrying the controlling and monitoring information between the NSFs and their management entities. This document may also be produced as a working document that is not published as an RFC. The working group may additionally choose to develop documents to describe requirements for extensions (if any) to existing protocols used by the working group, to explain how the data models are used to monitor and control flow-based NSFs, and to describe how to use I2RS and NETCONF to carry the content of the data models. These documents may be published as Informational RFCs or may be working documents that are discarded once they have triggered the necessary work. The working group will work closely with the I2RS, NETCONF, and NETMOD WGs. The working group will communicate with external SDOs like ETSI NFV and will encourage open source code development related to the working group scope in organizations like ONF, OpenStack, ODL, and OPNFV. The working group must have the above deliverables completed within 24 months. The responsible AD will close the working group at that time if they are not completed or close to completion. The working group may be closed earlier if substantial progress is not being made. Goals and Milestones: Dec 2016 - Adopt examination of existing secure communication mechanisms as WG document Dec 2018 - Data Models and Applicability Statements to IESG for publication Feb 2019 - Adopt IANA registry consideration as WG document Feb 2019 - Working group re-charter or close Done - Adopt use Cases, problem statement, and gap analysis as WG document Done - Adopt framework as WG document Done - Adopt requirements for extensions to protocols as WG document Done - WG decides whether to progress adopted drafts for publication as RFCs (use cases, framework, information model, and examination of existing secure communication mechanisms) Done - Adopt info model as WG document (if desired) Done - Adopt data models as WG document Done - Adopt applicability statements as WG Document Done - All early drafts to IESG for publication (if WG decided to proceed): use cases, problem statement, and gap analysis document; framework document; information model requirements for extensions to protocols document; examination of existing secure communication mechanisms document Internet-Drafts: - Software-Defined Networking (SDN)-based IPsec Flow Protection [draft-abad-i2nsf-sdn-ipsec-flow-protection-03] (45 pages) - Analysis of Existing work for I2NSF [draft-hares-i2nsf-gap-analysis-01] (44 pages) - I2NSF Problem Statement and Use cases [draft-hares-i2nsf-merged-problem-use-cases-00] (23 pages) - A YANG Data Model for Monitoring I2NSF Network Security Functions [draft-hong-i2nsf-nsf-monitoring-data-model-06] (75 pages) - Applicability of Interfaces to Network Security Functions to Network-Based Security Services [draft-ietf-i2nsf-applicability-18] (29 pages) - Information Model of NSFs Capabilities [draft-ietf-i2nsf-capability-05] (26 pages) - I2NSF Capability YANG Data Model [draft-ietf-i2nsf-capability-data-model-05] (49 pages) - Requirements for Client-Facing Interface to Security Controller [draft-ietf-i2nsf-client-facing-interface-req-05] (24 pages) - I2NSF Consumer-Facing Interface YANG Data Model [draft-ietf-i2nsf-consumer-facing-interface-dm-08] (48 pages) - Framework for Interface to Network Security Functions [draft-ietf-i2nsf-framework-10] (25 pages) - Analysis of Existing work for I2NSF [draft-ietf-i2nsf-gap-analysis-03] (48 pages) - I2NSF Network Security Function-Facing Interface YANG Data Model [draft-ietf-i2nsf-nsf-facing-interface-dm-09] (101 pages) - I2NSF NSF Monitoring YANG Data Model [draft-ietf-i2nsf-nsf-monitoring-data-model-03] (78 pages) - Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases [draft-ietf-i2nsf-problem-and-use-cases-16] (29 pages) - I2NSF Registration Interface YANG Data Model [draft-ietf-i2nsf-registration-interface-dm-08] (34 pages) - Software-Defined Networking (SDN)-based IPsec Flow Protection [draft-ietf-i2nsf-sdn-ipsec-flow-protection-07] (86 pages) - Interface to Network Security Functions (I2NSF) Terminology [draft-ietf-i2nsf-terminology-08] (13 pages) - Applicability of Interfaces to Network Security Functions to Networked Security Services [draft-jeong-i2nsf-applicability-01] (15 pages) - Requirements for Client-Facing Interface to Security Controller [draft-kumar-i2nsf-client-facing-interface-req-02] (22 pages) - Information Model of NSFs Capabilities [draft-xibassnez-i2nsf-capability-02] (57 pages) Requests for Comments: RFC8192: Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases (29 pages) RFC8329: Framework for Interface to Network Security Functions (25 pages) Interface to the Routing System (i2rs) -------------------------------------- Charter Last Modified: 2018-03-21 Current Status: Active Chairs: Russ White Susan Hares Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Martin Vigoureux Mailing Lists: General Discussion: i2rs@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/i2rs Archive: https://mailarchive.ietf.org/arch/browse/i2rs/ Description of Working Group: In an IP routed network, the routing system: - Distributes topology and other state (network metadata) - Uses this network metadata to determine the best paths to each given reachable destination attached to the network - Communicates these decisions to the forwarding plane of each forwarding device in the network. That is, the routing system is the collection of entities, protocols and processes that collectively build the forwarding tables that are exported into the entities that constitute the network's forwarding plane. While processes participating in the routing system are often colocated with the local forwarding elements, this isn't a necessary condition. Thus, the routing system includes control plane protocols and processes that compute routes and paths for data packets, wherever the processes implementing those protocols and processes may be running. I2RS facilitates real-time or event driven interaction with the routing system through a collection of protocol-based control or management interfaces. These allow information, policies, and operational parameters to be injected into and retrieved (as read or by notification) from the routing system while retaining data consistency and coherency across the routers and routing infrastructure, and among multiple interactions with the routing system. The I2RS interfaces will co-exist with existing configuration and management systems and interfaces. It is envisioned that users of the I2RS interfaces will be management applications, network controllers, and user applications that make specific demands on the network. The I2RS working group works to develop a high-level architecture that describes the basic building-blocks necessary to enable the specific use cases, and that will lead to an understanding of the abstract informational models and requirements for encodings and protocols for the I2RS interfaces. Small and well-scoped use cases are critical to constrain the scope of the work and achieve sufficient focus for the working group to deliver successful outcomes. Initial work within the working group will be limited to a single administrative domain. The working group is chartered to work on the following items: - High-level architecture for I2RS including considerations of policy and security. - Tightly scoped key use cases for operational use of I2RS as follows: o Interactions with the Routing Information Base (RIB). Allowing read and write access to the RIB, but no direct access to the Forwarding Information Base (FIB). o Filter-based RIBs include a match of fields in IP header plus other IP packet format fields. The matches in the filter-based RIBs may be ordered to allow appropriate sequencing of the filter. Each match contains an action which may be forwarding to a next hop address or other actions. I2RS will coordinate this work with appropriate working groups in routing, security and operations & management areas. o Control and analysis of the operation of the Border Gateway Protocol (BGP) including the setting and activation of policies related to the protocol. o Control, optimization, and choice of traffic exit points from networks based on more information than provided by the dynamic control plane. o Distributed reaction to network-based attacks through rapid modification of the control plane behavior to reroute traffic for one destination while leaving standard mechanisms (filters, metrics, and policy) in place for other routes. o Service layer routing to improve on existing hub-and-spoke traffic. o The ability to extract information about topology from the network. Injection and creation of topology will not be considered as a work item. Such topology-related models will be based on a generic topology model to support multiple uses; the generic topology model should support topology extension for non-I2RS uses. o Other use cases may be adopted by the working group only through rechartering. - Yang Data Models consistent with the use cases. Such documents should include an information overview. The existing WG draft - draft-ietf-i2rs-rib-info-model - that is just an informational model can be completed or extended with the associated YANG data model. - Requirements for I2RS protocols and encoding languages. - An analysis of existing IETF and other protocols and encoding languages against the requirements. Goals and Milestones: Mar 2016 - Request Publication of Filter-Based RIB Data Model Aug 2016 - Request publication of an Informational document defining the protocol requirements Aug 2016 - Request publication of Standards Track documents specifying information models Sep 2016 - Request publication of Informational documents describing use cases Sep 2016 - Request Publication of Protocol Independent RIB Data Model Oct 2016 - Consider re-chartering Nov 2016 - Request publication of an Informational document providing an analysis of existing IETF and other protocols and encoding languages against the requirements Dec 2016 - Request publication of an Informational document defining encoding language requirements Dec 2016 - Request Publication of Protocol Independent Topology Data Models Done - Working Group adoption of Filter-Based RIB Yang Data Model RFC7921 - Request publication of an Informational document defining the problem statement RFC7921 - Request publication of an Informational document defining the high-level architecture Internet-Drafts: - An Architecture for the Interface to the Routing System [draft-atlas-i2rs-architecture-02] (21 pages) - Interface to the Routing System Problem Statement [draft-atlas-i2rs-problem-statement-02] (10 pages) - Identifier Management for I2RS Protocol [draft-chen-i2rs-identifier-management-00] (9 pages) - A YANG Data Model for Layer 3 Topologies [draft-clemm-i2rs-yang-l3-topo-00] (39 pages) - A Data Model for Network Topologies [draft-clemm-i2rs-yang-network-topo-04] (25 pages) - A YANG Data Model for Layer-2 Network Topologies [draft-dong-i2rs-l2-network-topology-01] (14 pages) - I2RS Ephemeral State Requirements [draft-haas-i2rs-ephemeral-state-reqs-00] (9 pages) - I2RS requirements for netmod/netconf [draft-haas-i2rs-netmod-netconf-requirements-01] (9 pages) - I2RS Security Related Requirements [draft-hares-i2rs-auth-trans-05] (10 pages) - An Information Model for Basic Network Policy and Filter Rules [draft-hares-i2rs-bnp-eca-data-model-03] (30 pages) - Filter-Based RIB Data Model [draft-hares-i2rs-fb-rib-data-model-03] (20 pages) - Filter-Based Packet Forwarding ECA Policy [draft-hares-i2rs-pkt-eca-data-model-02] (37 pages) - An Information Model for Basic Network Policy [draft-hareskini-i2rs-pbr-info-model-00] (17 pages) - An Architecture for the Interface to the Routing System [draft-ietf-i2rs-architecture-15] (40 pages) - Interface to the Routing System (I2RS) Ephemeral State Requirements [draft-ietf-i2rs-ephemeral-state-23] (12 pages) - Filter-Based RIB Data Model [draft-ietf-i2rs-fb-rib-data-model-01] (21 pages) - Filter-Based RIB Information Model [draft-ietf-i2rs-fb-rib-info-model-00] (21 pages) - Filter-Based Packet Forwarding ECA Policy [draft-ietf-i2rs-pkt-eca-data-model-03] (39 pages) - Problem Statement for the Interface to the Routing System [draft-ietf-i2rs-problem-statement-11] (12 pages) - Interface to the Routing System (I2RS) Security-Related Requirements [draft-ietf-i2rs-protocol-security-requirements-17] (20 pages) - Requirements for Subscription to YANG Datastores [draft-ietf-i2rs-pub-sub-requirements-09] (18 pages) - A YANG Data Model for the Routing Information Base (RIB) [draft-ietf-i2rs-rib-data-model-15] (71 pages) - RIB Information Model [draft-ietf-i2rs-rib-info-model-17] (28 pages) - I2RS Environment Security Requirements [draft-ietf-i2rs-security-environment-reqs-06] (28 pages) - Interface to the Routing System (I2RS) Traceability: Framework and Information Model [draft-ietf-i2rs-traceability-11] (17 pages) - Summary of I2RS Use Case Requirements [draft-ietf-i2rs-usecase-reqs-summary-03] (34 pages) - A YANG Data Model for Fabric Topology in Data-Center Networks [draft-ietf-i2rs-yang-dc-fabric-network-topology-12] (32 pages) - A YANG Data Model for Layer-2 Network Topologies [draft-ietf-i2rs-yang-l2-network-topology-13] (35 pages) - A YANG Data Model for Layer 3 Topologies [draft-ietf-i2rs-yang-l3-topology-16] (35 pages) - A YANG Data Model for Network Topologies [draft-ietf-i2rs-yang-network-topo-20] (57 pages) - Use Cases for an Interface to BGP Protocol [draft-keyupate-i2rs-bgp-usecases-04] (21 pages) - Filter-Based RIB Information Model [draft-kini-i2rs-fb-rib-info-model-03] (21 pages) - I2RS Environment Security Requirements [draft-mglt-i2rs-security-environment-reqs-01] (19 pages) - Routing Information Base Info Model [draft-nitinb-i2rs-rib-info-model-02] (26 pages) - BGP Model for Service Provider Networks [draft-shaikh-idr-bgp-model-02] (77 pages) - Requirements for Subscription to YANG Datastores [draft-voit-i2rs-pub-sub-requirements-00] (13 pages) - Data Model for RIB I2RS protocol [draft-wang-i2rs-rib-data-model-02] (38 pages) - A YANG Data Model for Layer 1 Network Topology [draft-zhang-i2rs-l1-topo-yang-model-01] (23 pages) - TRILL Support of Point to Multipoint BFD [draft-zhang-trill-p2mp-bfd-02] (7 pages) - Yang Data Model for BGP Protocol [draft-zhdankin-idr-bgp-cfg-00] (44 pages) Requests for Comments: RFC7920: Problem Statement for the Interface to the Routing System (12 pages) RFC7921: An Architecture for the Interface to the Routing System (40 pages) RFC7922: Interface to the Routing System (I2RS) Traceability: Framework and Information Model (17 pages) RFC7923: Requirements for Subscription to YANG Datastores (18 pages) RFC8241: Interface to the Routing System (I2RS) Security-Related Requirements (20 pages) RFC8242: Interface to the Routing System (I2RS) Ephemeral State Requirements (12 pages) RFC8345: A YANG Data Model for Network Topologies (57 pages) RFC8346: A YANG Data Model for Layer 3 Topologies (35 pages) RFC8430: RIB Information Model (28 pages) RFC8431: A YANG Data Model for the Routing Information Base (RIB) (71 pages) RFC8542: A YANG Data Model for Fabric Topology in Data-Center Networks (32 pages) Interactive Connectivity Establishment (ice) -------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chair: Ari Keränen Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Murray Kucherawy Tech Advisor: Martin Stiemerling Mailing Lists: General Discussion: ice@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ice Archive: https://mailarchive.ietf.org/arch/browse/ice/ Description of Working Group: Interactive Connectivity Establishment (ICE) is at the same time a NAT traversal technique, a multihomed address selection technique, and a dual stack address selection technique that works by including multiple IP addresses and ports in both the request and response messages of a connectivity establishment transaction. It makes no assumptions regarding network topology on the local or remote side. Interactive Connectivity Establishment was published as RFC 5245 in April 2010. Until recently the protocol had seen rather limited deployment. This situation has changed drastically as ICE is mandatory to implement in WebRTC, a set of technologies developed at the IETF and W3C to standardize Real Time Communication on the Web. ICE was originally defined for the Offer-Answer (RFC 3264) protocol used by SIP (RFC 3261). Later XMPP (XEP-0176), RTSP (draft-ietf-mmusic-rtsp-nat), RTCWeb (draft-ietf-rtcweb-jsep) and other realtime media establishment protocols have used the protocol. ICE is also used by non-realtime media protocols, like HIP (RFC 5770) and RELOAD (RFC 6940). The goal of the ICE Working Group is to consolidate the various initiatives to update and improve ICE, and to help ensure suitability and consistency in the environments ICE operates in. Current work in this area includes an updated version of the ICE RFC (ICEbis), Trickle ICE and dualstack/multihomed fairness. This work will make ICE more flexible, robust and more suitable for changing mobile environments without major changes to the original ICE RFC. The ICE workgroup will consider new work items that follow this pattern. The core ICE work will offer guidance to help minimize the unintentional exposure of IP addresses. ICE is an application controlled protocol that leverages a set of network defined protocols. The STUN (RFC 5389), TURN (RFC 5766) and related protocol work done in the TRAM working group must be closely synchronized with the work in this working group. To avoid interoperability issues and unwanted behavior it is desired to increase the interaction with other working groups dealing with network protocols closer to the wire. Example of such work may be, but not limited to: issues regarding multi-homing, multi subnet and prefixes, QoS, transport selection and congestion control. From the application side, the users of ICE, there is a need to make sure what is specified is actually usable. Getting input from the application working groups will be helpful (RTCWEB, HIP, MMUSIC, P2PSIP). Goals and Milestones: May 2019 - Submit ICE Patience as Proposed Standard Done - Submit Dual-stack Fairness with ICE as Proposed Standard Done - Submit a revision of ICE (RFC 5245) as Proposed Standard (draft-ietf-mmusic-ice-sip-sdp remains in MMUSIC) Done - Submit Trickle ICE as Proposed Standard (draft-ietf-mmusic-trickle-ice-sip remains in MMUSIC) Internet-Drafts: - Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactive Connectivity Establishment (ICE) [draft-ietf-ice-dualstack-fairness-07] (9 pages) - Interactive Connectivity Establishment Patiently Awaiting Connectivity (ICE PAC) [draft-ietf-ice-pac-06] (7 pages) - Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal [draft-ietf-ice-rfc5245bis-20] (100 pages) - Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol [draft-ietf-ice-trickle-21] (33 pages) Requests for Comments: BCP217: Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactive Connectivity Establishment (ICE) (9 pages) RFC8421: Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactive Connectivity Establishment (ICE) (9 pages) RFC8445: Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal (100 pages) Inter-Domain Routing (idr) -------------------------- Charter Last Modified: 2020-03-20 Current Status: Active Chairs: John Scudder Susan Hares Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Alvaro Retana 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 Advertisement of Multiple Paths in BGP to IESG as a Proposed Standard Jun 2015 - Submit BGP Link Bandwidth Extended Community to IESG as a Proposed Standard Nov 2015 - Submit MIB v2 for BGP-4 to IESG as a Proposed Standard Nov 2015 - Submit Multisession BGP 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 ASpath ORF draft to IESG as a Proposed Standard Feb 2016 - Submit Yang BGP Modules to IESG as Proposed Standard Apr 2016 - Solicit work items for scalability improvements Apr 2016 - Progress base BGP specification (RFC 4271) as Full Standard Done - Submit to BGP Capability Advertisement to the IESG Done - Submit BGP Security Vulnerabilities Analysis to IESG as an Informational Done - Submit BGP4 MIB to IESG as a Proposed Standard Done - Submit BGP4 document to IESG as a Draft Standard Done - Submit BGP Graceful Restart to IESG as a Proposed Standard Done - Submit Extended Communities draft to IESG as a Proposed Standard Done - Submit revised text on Multi-Protocol BGP (rfc2858bis) to IESG as a Draft Standard Done - Submit Subcodes for BGP Cease Notification Message to IESG as a Proposed Standard Done - Submit 4-byte AS ID to IESG as a Proposed Standard Done - Submit Outbound Route Filter, Prefix and ASpath ORF draft to IESG as a Proposed Standard Done - Prefix and ASpath ORF draft to IESG as a Proposed Standard 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 Link State Extensions for SRv6 [draft-dawra-idr-bgpls-srv6-ext-06] (24 pages) - Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios [draft-dong-idr-rtc-hierarchical-rr-02] (6 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) - 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) - A BGP/IDRP Route Server alternative to a full mesh routing [draft-haskin-bgp-idrp-mesh-routing-00] (16 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) - 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) - 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) - 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) - 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) - AS Path Based Outbound Route Filter for BGP-4 [draft-ietf-idr-aspath-orf-13] (7 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) - BGP-4 Protocol Analysis [draft-ietf-idr-bgp-analysis-07] (16 pages) - Constrain Attribute announcement within BGP [draft-ietf-idr-bgp-attribute-announcement-02] (9 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-03] (6 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) - 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) - 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-01] (10 pages) - Revised Validation Procedure for BGP Flow Specifications [draft-ietf-idr-bgp-flowspec-oid-11] (11 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) - 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 Attributes Advertisement with BGP Link-State [draft-ietf-idr-bgp-ls-app-specific-attr-01] (13 pages) - Flexible Algorithm Definition Advertisement with BGP Link-State [draft-ietf-idr-bgp-ls-flex-algo-02] (13 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-00] (5 pages) - BGP Link-State Extensions for Seamless BFD [draft-ietf-idr-bgp-ls-sbfd-extensions-02] (9 pages) - BGP Link-State extensions for Segment Routing [draft-ietf-idr-bgp-ls-segment-routing-ext-16] (31 pages) - Signaling MSD (Maximum SID Depth) using Border Gateway Protocol - Link State [draft-ietf-idr-bgp-ls-segment-routing-msd-18] (10 pages) - Signalling ERLD using BGP-LS [draft-ietf-idr-bgp-ls-segment-routing-rld-05] (6 pages) - SR Policies Extensions for Path Segment and Bidirectional Path in BGP-LS [draft-ietf-idr-bgp-ls-sr-policy-path-segment-00] (11 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) - BGP YANG Model for Service Provider Networks [draft-ietf-idr-bgp-model-08] (134 pages) - Multisession BGP [draft-ietf-idr-bgp-multisession-07] (19 pages) - Carrying next-hop cost information in BGP [draft-ietf-idr-bgp-nh-cost-02] (10 pages) - Route Leak Prevention using Roles in Update and Open messages [draft-ietf-idr-bgp-open-policy-10] (11 pages) - BGP Optimal Route Reflection (BGP-ORR) [draft-ietf-idr-bgp-optimal-route-reflection-20] (14 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) - 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) - 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) - BGP-4 Requirement Satisfaction Report [draft-ietf-idr-bgp4-stdreport1-02] (3 pages) - BGP4/IDRP for IP---OSPF Interaction [draft-ietf-idr-bgp4ospf-interact-07] (19 pages) - BGP-LS Extension for Inter-AS Topology Retrieval [draft-ietf-idr-bgpls-inter-as-topology-ext-08] (12 pages) - BGP-LS extensions for Segment Routing BGP Egress Peer Engineering [draft-ietf-idr-bgpls-segment-routing-epe-19] (18 pages) - BGP Link State Extensions for SRv6 [draft-ietf-idr-bgpls-srv6-ext-02] (24 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 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 AS_SET and AS_CONFED_SET in BGP [draft-ietf-idr-deprecate-as-set-confed-set-03] (7 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-14] (7 pages) - Distribution of Traffic Engineering Extended Admin Groups using BGP-LS [draft-ietf-idr-eag-distribution-12] (6 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) - Revised Error Handling for BGP UPDATE Messages [draft-ietf-idr-error-handling-19] (19 pages) - Extended Optional Parameters Length for BGP OPEN Message [draft-ietf-idr-ext-opt-param-08] (6 pages) - IANA Registries for BGP Extended Communities [draft-ietf-idr-extcomm-iana-02] (16 pages) - Dissemination of Flow Specification Rules [draft-ietf-idr-flow-spec-09] (22 pages) - Dissemination of Flow Specification Rules for IPv6 [draft-ietf-idr-flow-spec-v6-11] (15 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-14] (23 pages) - BGP Flow Specification Filter for MPLS Label [draft-ietf-idr-flowspec-mpls-match-01] (8 pages) - BGP Dissemination of Flow Specification Rules for Tunneled Traffic [draft-ietf-idr-flowspec-nvo3-09] (19 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-10] (12 pages) - BGP Flow-Spec Redirect to IP Action [draft-ietf-idr-flowspec-redirect-ip-02] (9 pages) - Clarification of the Flowspec Redirect Extended Community [draft-ietf-idr-flowspec-redirect-rt-bis-05] (7 pages) - Subcodes for BGP Finite State Machine Error [draft-ietf-idr-fsm-subcode-03] (5 pages) - IDRP for IP v4 and v6 [draft-ietf-idr-idrp-v4v6-02] (20 pages) - Inter-Domain Routing Protocol, Version 2 [draft-ietf-idr-idrp2-00] (110 pages) - Internet Exchange BGP Route Server [draft-ietf-idr-ix-bgp-route-server-12] (12 pages) - Internet Exchange Route Server - Implementation Report [draft-ietf-idr-ix-bgp-route-server-implementation-00] (5 pages) - BGP Large Communities Attribute [draft-ietf-idr-large-community-12] (8 pages) - Reservation of Last Autonomous System (AS) Numbers [draft-ietf-idr-last-as-reservation-07] (5 pages) - Automatic Route Target Filtering for legacy PEs [draft-ietf-idr-legacy-rtc-08] (10 pages) - BGP Link Bandwidth Extended Community [draft-ietf-idr-link-bandwidth-07] (5 pages) - Support for Long-lived BGP Graceful Restart [draft-ietf-idr-long-lived-gr-00] (25 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) - Revisions to the BGP 'Minimum Route Advertisement Interval' [draft-ietf-idr-mrai-dep-04] (4 pages) - BGP Next-Hop dependent capabilities [draft-ietf-idr-next-hop-capability-05] (13 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-02] (10 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-24] (39 pages) - Distribution of Link-State and Traffic Engineering Information Using BGP [draft-ietf-idr-rfc7752bis-03] (59 pages) - Extended BGP Administrative Shutdown Communication [draft-ietf-idr-rfc8203bis-06] (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-03] (18 pages) - Making Route Servers Aware of Data Link Failures at IXPs [draft-ietf-idr-rs-bfd-08] (14 pages) - Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios [draft-ietf-idr-rtc-hierarchical-rr-03] (6 pages) - Route Target Constrained Distribution of Routes with no Route Targets [draft-ietf-idr-rtc-no-rt-12] (7 pages) - Advertising Segment Routing Policies in BGP [draft-ietf-idr-segment-routing-te-policy-08] (38 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 Path MTU in BGP [draft-ietf-idr-sr-policy-path-mtu-01] (9 pages) - SR Policy Extensions for Path Segment and Bidirectional Path [draft-ietf-idr-sr-policy-path-segment-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-13] (49 pages) - BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions [draft-ietf-idr-te-pm-bgp-18] (10 pages) - The BGP Tunnel Encapsulation Attribute [draft-ietf-idr-tunnel-encaps-15] (42 pages) - Advertising an IPv4 NLRI with an IPv6 Next Hop [draft-ietf-idr-v4nlri-v6nh-01] (10 pages) - BGP Community Container Attribute [draft-ietf-idr-wide-bgp-communities-05] (25 pages) - IDRP for SIP [draft-ietf-ipidrp-sip-01] (9 pages) - Border Gateway Protocol (BGP) [draft-ietf-iwg-bgp-00] (29 pages) - Definitions of Managed Objects for the Border Gateway Protocol: Version 3 [draft-ietf-iwg-bgp-mib-02] (13 pages) - Application of the Border Gateway Protocol in the Internet [draft-ietf-iwg-bgpapplication-00] (23 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) - Application Specific Attributes Advertisement with BGP Link-State [draft-ketant-idr-bgp-ls-app-specific-attr-01] (13 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) - 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-02] (9 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) - 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) - 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) - Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE) [draft-ooms-v6ops-bgp-tunnel-07] (14 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) - 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) - Revision to Capability Codes Registration Procedures [draft-scudder-idr-capabilities-registry-change-02] (4 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) - Methods for Detection and Mitigation of BGP Route Leaks [draft-sriram-idr-route-leak-detection-mitigation-01] (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-LS Extension for Inter-AS Topology Retrieval [draft-wang-idr-bgpls-inter-as-topology-ext-02] (10 pages) - Distribution of MPLS-TE Extended admin Group Using BGP [draft-wang-idr-eag-distribution-02] (5 pages) - BGP Extensions for IDs Allocation [draft-wu-idr-bgp-segment-allocation-ext-05] (16 pages) - A YANG Data Model for Flow Specification [draft-wu-idr-flowspec-yang-cfg-02] (32 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) - 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) Requests for Comments: BCP172: Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP (5 pages) BCP6: Guidelines for creation, selection, and registration of an Autonomous System (AS) (10 pages) 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 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 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) RFC5575: Dissemination of Flow Specification Rules (22 pages) * Updates RFC7674 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) 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) 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) 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) 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) Internet Area Working Group (intarea) ------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Juan-Carlos Zúñiga Wassim Haddad Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: int-area@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/int-area Archive: https://mailarchive.ietf.org/arch/browse/int-area/ Description of Working Group: The Internet Area Working Group (INTAREA WG) acts primarily as a forum for discussing far-ranging topics that affect the entire area. Such topics include, for instance, address space issues, basic IP layer functionality, and architectural questions. The group also serves as a forum to distribute information about ongoing activities in the area, create a shared understanding of the challenges and goals for the area, and to enable coordination. The Internet Area receives occasional proposals for the development and publication of RFCs that are not in scope of an existing working group and do not justify the formation of a new working group. The INTAREA WG has a secondary role to serve as the forum for developing such work items in the IETF. The working group milestones are updated as needed to reflect the current work items and their associated milestones. New work must satisfy the following conditions: (1) WG consensus on the relevance for the Internet at large. (2) WG consensus on the suitability and projected quality of the proposed work item. (3) A core group of WG participants with sufficient energy and expertise to advance the work item according to the proposed schedule. (4) Commitment from the WG as a whole to provide sufficient and timely review of the proposed work item. (5) Agreement by the ADs, who, depending on the scope of the proposed work item, may decide that an IESG review is needed first. Goals and Milestones: May 2010 - Submission of IPID document to the IESG as PS Aug 2010 - Submission of tunneling issues document to the IESG as Info Aug 2010 - Submission of tunneling security issues document to the IESG as Info Internet-Drafts: - Multi-hop Ad Hoc Wireless Communication [draft-baccelli-intarea-adhoc-wireless-com-01] (11 pages) - Extended Ping (Xping) [draft-bonica-intarea-eping-04] (17 pages) - Discovering Provisioning Domain Names and Data [draft-bruneau-intarea-provisioning-domains-02] (20 pages) - Current Hostname Practice Considered Harmful [draft-huitema-privsec-harmfulname-01] (9 pages) - Multi-hop Ad Hoc Wireless Communication [draft-ietf-intarea-adhoc-wireless-com-02] (12 pages) - Privacy Considerations for Protocols Relying on IP Broadcast or Multicast [draft-ietf-intarea-broadcast-consider-09] (13 pages) - Using the IPv6 Flow Label for Load Balancing in Server Farms [draft-ietf-intarea-flow-label-balancing-03] (13 pages) - IP Fragmentation Considered Fragile [draft-ietf-intarea-frag-fragile-17] (28 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] (33 pages) - IP Router Alert Considerations and Usage [draft-ietf-intarea-router-alert-considerations-10] (19 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-10] (52 pages) - IP over Intentionally Partially Partitioned Links [draft-nordmark-intarea-ippl-05] (12 pages) Requests for Comments: BCP162: Logging Recommendations for Internet-Facing Servers (5 pages) BCP168: IP Router Alert Considerations and Usage (19 pages) BCP177: IPv6 Support Required for All IP-Capable Nodes (6 pages) 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) IP Performance Measurement (ippm) --------------------------------- Charter Last Modified: 2020-04-02 Current Status: Active Chairs: Ian Swett Tommy Pauly Transport Area Directors: Martin Duke Magnus Westerlund Transport Area Advisor: Martin Duke 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: Mar 2020 - submit a Standards Track draft on inband OAM based measurement methodologies to the IESG Mar 2020 - Submit a Standards Track draft defining a metric for unidirectional route assessment to the IESG Mar 2020 - Submit a Standards Track document on Direct Export for IOAM Jul 2020 - Submit a Standards Track document on Metrics and Methods for IP Capacity Measurement 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 Internet-Drafts: - Two-Way Active Measurement Protocol (TWAMP) Data Model [draft-cmzrjp-ippm-twamp-yang-02] (56 pages) - Multipoint Alternate Marking method for passive and hybrid performance monitoring [draft-fioccola-ippm-multipoint-alt-mark-04] (20 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) - A Bulk Transfer Capacity Methodology for Cooperating Hosts [draft-ietf-ippm-btc-cap-00] (5 pages) - A Framework for Defining Empirical Bulk Transfer Capacity Metrics [draft-ietf-ippm-btc-framework-05] (16 pages) - Defining Network Capacity [draft-ietf-ippm-bw-capacity-05] (14 pages) - Metrics and Methods for IP Capacity [draft-ietf-ippm-capacity-metric-method-01] (22 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 One-way Delay Metric for IPPM [draft-ietf-ippm-delay-07] (20 pages) - Packet Delay Variation Applicability Statement [draft-ietf-ippm-delay-var-as-02] (39 pages) - A One-Way Packet Duplication Metric [draft-ietf-ippm-duplicate-08] (14 pages) - Framework for IP Performance Metrics [draft-ietf-ippm-framework-02] (40 pages) - Framework for Metric Composition [draft-ietf-ippm-framework-compagg-09] (18 pages) - Overview of Implementation reports relating to IETF work on IP Performance Measurements (IPPM, RFC 2678 - 2681) [draft-ietf-ippm-implement-02] (24 pages) - Initial Performance Metrics Registry Entries [draft-ietf-ippm-initial-registry-16] (78 pages) - Data Fields for In-situ OAM [draft-ietf-ippm-ioam-data-09] (43 pages) - In-situ OAM Direct Exporting [draft-ietf-ippm-ioam-direct-export-00] (10 pages) - In-situ OAM Flags [draft-ietf-ippm-ioam-flags-01] (10 pages) - In-situ OAM IPv6 Options [draft-ietf-ippm-ioam-ipv6-options-01] (9 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] (38 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] (24 pages) - Network performance measurement with periodic streams [draft-ietf-ippm-npmps-07] (23 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) - One-Way Metric Applicability Statement [draft-ietf-ippm-owmetric-as-01] (8 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) - 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) - Advanced Unidirectional Route Assessment (AURA) [draft-ietf-ippm-route-07] (27 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 Optional Extensions [draft-ietf-ippm-stamp-option-tlv-04] (25 pages) - Simple Two-way Active Measurement Protocol (STAMP) Data Model [draft-ietf-ippm-stamp-yang-05] (35 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) - TReno Bulk Transfer Capacity [draft-ietf-ippm-treno-btc-03] (5 pages) - A Two-Way Active Measurement Protocol (TWAMP) [draft-ietf-ippm-twamp-09] (26 pages) - Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features [draft-ietf-ippm-twamp-reflect-octets-09] (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) Data Model [draft-ietf-ippm-twamp-yang-13] (68 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) - 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) - 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) Requests for Comments: BCP108: IP Performance Metrics (IPPM) Metrics Registry (14 pages) BCP176: IP Performance Metrics (IPPM) Standard Advancement Testing (37 pages) RFC2330: Framework for IP Performance Metrics (40 pages) * Updates RFC7312 * Updates RFC8468 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) 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) STD81: A One-Way Delay Metric for IP Performance Metrics (IPPM) (27 pages) STD82: A One-Way Loss Metric for IP Performance Metrics (IPPM) (22 pages) IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ Charter Last Modified: 2019-11-20 Current Status: Active Chairs: Tero Kivinen Yoav Nir Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Benjamin Kaduk 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: Dec 2019 - The internal address failure indication in IKEv2 to IESG May 2020 - G-DOI for IKEv2 to IESG May 2020 - Postquantum cryptography document for IKEv2 to IESG Aug 2020 - The security labels support for IKEv2 to IESG Aug 2020 - TCP-encapsulation guidelines document to IESG Nov 2020 - Traffic Flow Confidentiality document to IESG Jun 2021 - The ESP on contrained network to IESG Jun 2021 - Signature algorithm negotiation for IKEv2 to IESG Internet-Drafts: - IKEv2 Notification Codes for IPv4/IPv6 Coexistence [draft-boucadair-ipsecme-ipv6-ipv4-codes-03] (6 pages) - Postquantum Preshared Keys for IKEv2 [draft-fluhrer-qr-ikev2-04] (11 pages) - IP Traffic Flow Security [draft-hopps-ipsecme-iptfs-01] (25 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) - 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-00] (52 pages) - A TCP transport for the Internet Key Exchange [draft-ietf-ipsecme-ike-tcp-01] (9 pages) - Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation [draft-ietf-ipsecme-ikev2-fragmentation-10] (20 pages) - Intermediate Exchange in the IKEv2 Protocol [draft-ietf-ipsecme-ikev2-intermediate-03] (11 pages) - IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-ikev2-ipv6-config-03] (32 pages) - Multiple Key Exchanges in IKEv2 [draft-ietf-ipsecme-ikev2-multiple-ke-00] (23 pages) - The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-ikev2-null-auth-07] (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) - Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-ikev2bis-11] (138 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) - IP Traffic Flow Security [draft-ietf-ipsecme-iptfs-01] (25 pages) - IKEv2 Notification Status Types for IPv4/IPv6 Coexistence [draft-ietf-ipsecme-ipv6-ipv4-codes-04] (7 pages) - Labeled IPsec Traffic Selector support for IKEv2 [draft-ietf-ipsecme-labeled-ipsec-02] (8 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 IKEv2 for Post-quantum Security [draft-ietf-ipsecme-qr-ikev2-11] (20 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) - 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) - 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) - 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) - Intermediate Exchange in the IKEv2 Protocol [draft-smyslov-ipsecme-ikev2-aux-02] (10 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 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) RFC8229: TCP Encapsulation of IKE and IPsec Packets (25 pages) RFC8247: Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2) (19 pages) 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) STD79: Internet Key Exchange Protocol Version 2 (IKEv2) (142 pages) IP Wireless Access in Vehicular Environments (ipwave) ----------------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Carlos J. Bernardos Russ Housley Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Erik Kline Mailing Lists: General Discussion: its@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/its Archive: https://mailarchive.ietf.org/arch/browse/its/ Description of Working Group: Automobiles and vehicles of all types are increasingly connected to the Internet. Comfort-enhancing entertainment applications, road safety applications using bidirectional data flows, and connected automated driving are some of the new features expected in automobiles to hit the roads from now to year 2020. Today, there are several deployed Vehicle-to-Internet technologies (V2Internet) that make use of embedded Internet modules, or an occupant's cellular smartphone: mirrorlink, carplay, android auto. Vehicle-to-Infrastructure (V2I, not to be mistaken with V2Internet) Communications are used for wireless exchange of critical safety and operational data between vehicles and roadway infrastructure, intended primarily to avoid motor vehicle crashes. Similarly, Vehicle-to-Vehicle Communications (V2V) are used for short-range communications between vehicles to exchange vehicle information such as vehicle speed, heading and braking status. This group will work on V2V and V2I use-cases where IP is well-suited as a networking technology and will develop an IPv6 based solution to establish direct and secure connectivity between a vehicle and other vehicles or stationary systems. These vehicular networks are characterized by dynamically changing network topologies and connectivity. V2V and V2I communications may involve various kinds of link layers: 802.11-OCB (Outside the Context of a Basic Service Set), 802.15.4 with 6lowpan, 802.11ad, VLC (Visible Light Communications), IrDA, LTE-D, LP-WAN. One of the most used link layers for vehicular networks is IEEE 802.11-OCB, as a basis for Dedicated short-range communications (DSRC). Several of these link-layers already provide support for IPv6. However, IPv6 on 802.11-OCB is yet to be fully defined. Some aspects of the IPv6 over 802.11-OCB work have been already defined at IEEE 1609 and the specification produced by this working group is expected be compatible with these aspects. This group's primary deliverable (and the only Standards track item) will be a document that will specify the mechanisms for transmission of IPv6 datagrams over IEEE 802.11-OCB mode. Once this document is completed, it will also be reviewed by the 6man working group. This group will work on an informational document that will explain the state of the art in the field and describe the use cases that will use IPv6 in order to focus the work of the group. The group will also work on informational document that describes the problem statement and the associated security and privacy considerations. The working group will decide at a future point whether these informational documents need to be published separately as RFCs or if they maybe combined. The group will try to reuse relevant technologies for Internet of Things (IoT) and infrastructure mobility that have been developed in other IETF and IRTF groups. The WG will pay particular attention to the privacy characteristics of solution it develops in order to minimize unwanted tracking opportunities. The group will closely coordinate with IEEE 802.11. The IETF has also established a formal liason relationship with ISO/TC204 in connection with the work to be performed by this working group. The work produced by this group may also be of interest to other SDOs such as ETSI TC ITS, 3GPP, and government organizations such as the NHTSA. No formal co-ordination is anticipated with these groups at this point but work done in these SDOs may end up becoming relevant to the WG deliverables in the future. Goals and Milestones: Oct 2017 - Submit "ITS General Problem Area" to IESG May 2018 - Submit "Problem Statement" to IESG Done - Draft for "IPv6 over 802.11-OCB" adopted by WG Done - Draft for "ITS General Problem Area" adopted by WG Done - Draft for "Problem Statement" adopted by WG Done - Publish "IPv6 over 802.11-OCB" Internet-Drafts: - Basic Support for IPv6 Networks Operating Outside the Context of a Basic Service Set over IEEE Std 802.11 [draft-ietf-ipwave-ipv6-over-80211ocb-52] (29 pages) - Problem Statement for IP Wireless Access in Vehicular Environments [draft-ietf-ipwave-problem-statement-00] (19 pages) - IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases [draft-ietf-ipwave-vehicular-networking-14] (32 pages) - Survey on IP-based Vehicular Networking for Intelligent Transportation Systems [draft-ietf-ipwave-vehicular-networking-survey-00] (37 pages) - Problem Statement for IP Wireless Access in Vehicular Environments [draft-jeong-ipwave-problem-statement-00] (18 pages) - Survey on IP-based Vehicular Networking for Intelligent Transportation Systems [draft-jeong-ipwave-vehicular-networking-survey-03] (34 pages) - Transmission of IPv6 Packets over IEEE 802.11 Outside the Context of a Basic Service Set (OCB) [draft-petrescu-ipv6-over-80211p-06] (40 pages) Requests for Comments: RFC8691: Basic Support for IPv6 Networks Operating Outside the Context of a Basic Service Set over IEEE Std 802.11 (29 pages) JSON Mail Access Protocol (jmap) -------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Bron Gondwana Jim Fenton Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba Mailing Lists: General Discussion: jmap@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/jmap Archive: https://mailarchive.ietf.org/arch/search/?email_list=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: Dec 2019 - Submit Message Disposition Notification document to the IESG Jan 2020 - Adopt a document for a JSON Contact format (after recharter) Feb 2020 - Submit JMAP Quotas document to the IESG Feb 2020 - Submit JMAP S/MIME signature validation document to the IESG Feb 2020 - Adopt a document for S/MIME key management and server side signing/encryption Jul 2020 - Adopt a document defining JMAP access to addressbooks Nov 2020 - Submit JMAP Calendars document to the IESG Dec 2020 - Submit document with guidance for implementation of IMAP servers and proxies (Informational) Dec 2020 - Submit JSON Contact document to IESG Internet-Drafts: - JMAP for Calendars [draft-ietf-jmap-calendars-02] (38 pages) - The JSON Meta Application Protocol (JMAP) [draft-ietf-jmap-core-17] (90 pages) - JSContact: A JSON representation of contact data [draft-ietf-jmap-jscontact-01] (17 pages) - The JSON Meta Application Protocol (JMAP) for Mail [draft-ietf-jmap-mail-16] (108 pages) - Handling Message Disposition Notification with JMAP [draft-ietf-jmap-mdn-09] (12 pages) - JMAP for Quotas [draft-ietf-jmap-quotas-01] (10 pages) - S/MIME signature verification extension to JMAP [draft-ietf-jmap-smime-01] (6 pages) - A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket [draft-ietf-jmap-websocket-07] (17 pages) Requests for Comments: RFC8620: The JSON Meta Application Protocol (JMAP) (90 pages) RFC8621: The JSON Meta Application Protocol (JMAP) for Mail (108 pages) Common Authentication Technology Next Generation (kitten) --------------------------------------------------------- Charter Last Modified: 2019-08-28 Current Status: Active Chair: Robbie Harwood Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Benjamin Kaduk 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: Mar 2013 - draft-ietf-krb-wg-pkinit-alg-agility to IESG Mar 2013 - draft-ietf-kitten-sasl-oauth to IESG Apr 2013 - draft-ietf-krb-wg-iakerb to IESG Apr 2013 - draft-ietf-kitten-sasl-saml-ec to IESG May 2013 - draft-ietf-kitten-gssapi-extensions-iana to IESG May 2013 - draft-ietf-krb-wg-cammac 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 one or more items for GSS-API cred management Jul 2013 - Adopt work on better error reporting in the GSS-API 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 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) - 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-00] (11 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) - 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) - 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) - SPAKE Pre-Authentication [draft-ietf-kitten-krb-spake-preauth-07] (37 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) - 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-19] (34 pages) - Stackable Generic Security Service Pseudo-Mechanisms [draft-ietf-kitten-stackable-pseudo-mechs-02] (17 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) 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) Lightweight Authenticated Key Exchange (lake) --------------------------------------------- Charter Last Modified: 2019-10-30 Current Status: Active Chairs: Mališa Vučinić Stephen Farrell Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Benjamin Kaduk 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: Problem Constrained environments using OSCORE in network environments such as NB-IoT, 6TiSCH, and LoRaWAN need a ‘lightweight’ authenticated key exchange (LAKE) that enables forward security. 'Lightweight' refers to: * resource consumption, measured by number of round-trips to complete, bytes on the wire, wall-clock time to complete, or power consumption * the amount of new code required on end systems which already have an OSCORE stack but the LAKE must still provide the security properties expected of IETF protocols, e.g., providing confidentiality protection, integrity protection, and authentication with strong work factor. Goals This working group is intended to be a narrowly focused activity intended to produce at most one LAKE for OSCORE usage and close. The working group will collaborate and coordinate with other IETF WGs such as ACE, CORE, 6TISCH, LPWAN, and LWIG to understand and validate the requirements and solution. draft-selander-ace-cose-ecdhe is a candidate starting point for the LAKE produced by the WG. Any work available from TLS or other WGs that satisfies the determined requirements will also be evaluated for suitability, but does not preclude the WG from freely selecting its preferred LAKE for OSCORE. Program of Work The deliverables of this WG are: 1. Design requirements of the lightweight authenticated key exchange protocol for OSCORE (this draft will not be published as an RFC but will be used to drive WG consensus on the deliverable (2)) 2. Specify a lightweight authenticated key exchange protocol suitable for use in constrained environments using OSCORE Goals and Milestones: Mar 2020 - WGLC on requirements document May 2020 - Adopt solution document or defer to existing external solution document Sep 2020 - solution document to IESG (if needed) Internet-Drafts: - Requirements for a Lightweight AKE for OSCORE [draft-ietf-lake-reqs-03] (25 pages) - Requirements for a Lightweight AKE for OSCORE [draft-selander-lake-reqs-04] (19 pages) No Requests for Comments Limited Additional Mechanisms for PKIX and SMIME (lamps) -------------------------------------------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Russ Housley Tim Hollebeek Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Roman Danyliw 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. 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: Nov 2019 - Adopt a draft for short-lived certificate conventions Dec 2019 - Adopt a draft for header protection conventions Dec 2019 - Adopt a draft for CMP updates Dec 2019 - Adopt a draft for Lightweight CMP profile Nov 2020 - Short-lived certificate conventions sent to IESG for BCP publication Nov 2020 - CMP updates sent to IESG for standards track publication Nov 2020 - Lightweight CMP profile sent to IESG for informational publication Mar 2021 - Header protection conventions sent to IESG for standards track publication Internet-Drafts: - DNS Certification Authority Authorization (CAA) Resource Record [draft-hoffman-andrews-caa-simplification-03] (19 pages) - Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection [draft-housley-lamps-cms-update-alg-id-protect-00] (8 pages) - Clarifications for Elliptic Curve Cryptogtaphy Subject Public Key Information [draft-ietf-lamps-5480-ku-clarifications-03] (3 pages) - CMP Updates [draft-ietf-lamps-cmp-updates-01] (16 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 Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-cms-mix-with-psk-07] (31 pages) - Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-cms-shakes-18] (16 pages) - Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection [draft-ietf-lamps-cms-update-alg-id-protect-01] (8 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) - Problem Statement and Requirements for Header Protection [draft-ietf-lamps-header-protection-requirements-01] (24 pages) - Lightweight CMP Profile [draft-ietf-lamps-lightweight-cmp-profile-01] (72 pages) - OCSP Nonce Extension [draft-ietf-lamps-ocsp-nonce-02] (6 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) - 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) - DNS Certification Authority Authorization (CAA) Resource Record [draft-ietf-lamps-rfc6844bis-07] (17 pages) - Clarification of Enrollment over Secure Transport (EST): transfer encodings and ASN.1 [draft-ietf-lamps-rfc7030est-clarify-05] (12 pages) - Clarification of Enrollment over Secure Transport (EST): transfer encodings and ASN.1 [draft-richardson-lamps-rfc7030est-clarify-05] (10 pages) - Clarifications for Elliptic Curve Cryptogtaphy Subject Public Key Information [draft-turner-5480-ku-clarifications-01] (3 pages) Requests for Comments: RFC8398: Internationalized Email Addresses in X.509 Certificates (12 pages) RFC8399: Internationalization Updates to RFC 5280 (9 pages) 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) Locator/ID Separation Protocol (lisp) ------------------------------------- Charter Last Modified: 2019-03-29 Current Status: Active Chairs: Joel M. Halpern Luigi Iannone Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Deborah Brungard Secretary: Padma Pillay-Esnault 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: The LISP WG has completed the first set of Experimental RFCs describing the Locator/ID Separation Protocol (LISP). LISP supports a routing architecture which decouples the routing locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. LISP requires no changes to end-systems or to routers that do not directly participate in the LISP deployment. LISP aims for an incrementally deployable protocol. The scope of the LISP technology is potentially applicable to have a large span, including unicast and multicast overlays at Layer 2 as well as at Layer 3, encompassing NAT traversal, VPNs, and supporting mobility as a general feature, independently of whether it is a mobile user or a migrating Virtual Machine (VM). Hence, the LISP technology is applicable in both Data Centers and public Internet environments. The LISP WG is chartered to continue work on the LISP base protocol and produce standard-track documents. In order to produce a coherent set of documents, the first (and high priority) work item of the LISP Working Group is to develop a standard-track solution based on the completed Experimental RFCs and the experience gained from early deployments. This work will include reviewing the existing set of Experimental RFCs and doing the necessary enhancements to support a base set of standards track RFCs. The group will review the current set of Working Group documents to identify potential standards-track documents and do the necessary enhancements to support standards-track. In parallel with the previous main work item, the LISP WG will work on the items listed below: - Multi-protocol support: Specifying the required extensions to support multi-protocol encapsulation (e.g., L2 or NSH (Network Service Headers). Rather than developing new encapsulations the work will aim at using existing well-established encapsulations or emerging from other Working Groups such as NVO3 and SFC. - Alternative Mapping System Design: By extending LISP with new multi-protocols support, it becomes necessary to develop the required mapping function and control plane extensions to operate LISP map-assisted networks (which might include Hierarchical Pull, Publish/Subscribe, or Push models, independent mapping systems interconnection, security extensions, or alternative transports of the LISP control protocol). - Mobility: Some LISP deployment scenarios include mobile nodes (in mobile environments) or Virtual Machines (VMs in data centers), hence, support needs to be provided in order to achieve seamless connectivity. This work item may benefit from experience of other Working Groups like DMM (Distributed Mobility Management) or NVO3 (for VM migration). - Multicast: Support for overlay multicast by means of replication as well as interfacing with existing underlay multicast support. This may need discussion with other Working Groups related to multicast solutions (e.g. PIM). - Data-Plane Encryption: In some scenarios, it may be desirable to encrypt LISP encapsulated traffic. In this case, the data-plane encryption mechanism itself and support for control-plane security material exchange needs to be specified. Any solution proposed in this work item has to be reviewed by security experts. - NAT-Traversal: Support for NAT-traversal solution in deployments where LISP tunnel routers are separated from correspondent tunnel routers by a NAT (e.g., LISP mobile node). - Models for managing the LISP protocol and deployments that include data models, as well as allowing for programmable management interfaces. These management methods should be considered for both the data-plane, control plane, and mapping system components of standards-track documents. Similar to the main work item, documents for these work items will as well target standard-track unless the document is of a different maturity level (e.g., Informational or Experimental). In the latter case, the Working Group will evaluate the maturity level and propose a recommended track for the document. Collaboration with other working groups, as stated in the different work items (e.g., PIM, NVO3, DMM, SFC), is important to ensure to have technologies that work smoothly together. The LISP Working Group is chartered to work on the LISP technology. It may use technologies developed in other working groups, but if it identifies needs for extensions or modifications, those extensions and modifications will be addressed in the working groups that developed those technologies. The LISP Working Group may provide feedback to other working groups based on experience gained while using their solutions. Goals and Milestones: Aug 2016 - Submit a LISP control-plane security mechanism document to the IESG for consideration as Experimental Apr 2017 - Submit a LISP unicast data-plane specification (6830bis) document to the IESG for consideration as Proposed Standard Apr 2017 - Submit a LISP multicast data-plane specification (6831bis) document to the IESG for consideration as Proposed Standard Jul 2017 - Submit a LISP control-plane specification (6833bis) document to the IESG for consideration as Proposed Standard Jul 2017 - Submit a LISP interworking specification (6832bis) document to the IESG for consideration as Proposed Standard Jul 2017 - Submit a LISP Mobility document to the IESG for consideration as Proposed Standard 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-09] (11 pages) - LISP Canonical Address Format (LCAF) [draft-farinacci-lisp-lcaf-10] (29 pages) - LISP Distinguished Name Encoding [draft-farinacci-lisp-name-encoding-09] (6 pages) - LISP Predictive RLOCs [draft-farinacci-lisp-predictive-rlocs-02] (13 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-06] (18 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-03] (17 pages) - LISP EID Anonymity [draft-ietf-lisp-eid-anonymity-08] (10 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-05] (26 pages) - LISP Generic Protocol Extension [draft-ietf-lisp-gpe-14] (14 pages) - Locator/ID Separation Protocol (LISP) Impact [draft-ietf-lisp-impact-05] (18 pages) - Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites [draft-ietf-lisp-interworking-06] (19 pages) - An Architectural Introduction to the Locator/ID Separation Protocol (LISP) [draft-ietf-lisp-introduction-13] (27 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) - 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-07] (24 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) - Network-Hexagons: H3-LISP GeoState & Mobility Network [draft-ietf-lisp-nexagon-01] (18 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-06] (15 pages) - Publish/Subscribe Functionality for LISP [draft-ietf-lisp-pubsub-05] (12 pages) - The Locator/ID Separation Protocol (LISP) [draft-ietf-lisp-rfc6830bis-32] (46 pages) - Locator/ID Separation Protocol (LISP) Control-Plane [draft-ietf-lisp-rfc6833bis-27] (61 pages) - Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations [draft-ietf-lisp-rfc8113bis-03] (6 pages) - LISP-Security (LISP-SEC) [draft-ietf-lisp-sec-20] (27 pages) - Signal-Free Locator/ID Separation Protocol (LISP) Multicast [draft-ietf-lisp-signal-free-multicast-09] (21 pages) - LISP Traffic Engineering Use-Cases [draft-ietf-lisp-te-06] (18 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-06] (5 pages) - LISP Virtual Private Networks (VPNs) [draft-ietf-lisp-vpn-05] (17 pages) - LISP YANG Model [draft-ietf-lisp-yang-13] (79 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) Requests for Comments: RFC6830: The Locator/ID Separation Protocol (LISP) (75 pages) * Updates RFC8113 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) RFC6834: Locator/ID Separation Protocol (LISP) Map-Versioning (21 pages) 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) 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) RFC8378: Signal-Free Locator/ID Separation Protocol (LISP) Multicast (21 pages) IPv6 over Low Power Wide-Area Networks (lpwan) ---------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Alexander Pelov Pascal Thubert Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: lp-wan@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lp-wan Archive: https://mailarchive.ietf.org/arch/browse/lp-wan/ Description of Working Group: A new generation of wireless technologies has emerged under the generic name of Low-Power Wide-Area (LPWA), with a number of common characteristics, which make these technologies unique and disruptive for Internet of Things applications. Those common traits include an optimized radio modulation, a star topology, frame sizes in the order of tens of bytes transmitted a few times per day at ultra-low speeds and sometimes variable MTUs, and, though downstream may be supported, a mostly upstream transmission pattern that allows the devices to spend most of their time in low- energy deep-sleep mode. This enables a range of several kilometers and a long battery lifetime, possibly ten years operating on a single coin-cell. This also enables simple and scalable deployments with low-cost devices and thin infrastructures. Those benefits come at a price: the layer 2 frame formats are optimized and specific to each individual technology. There is no network layer and the application is often hard wired to the layer 2 frame format, leading to siloed deployments that must be managed, secured and operated individually. Migrating from one LPWA technology to another implies rebuilding the whole chain. There is a need to allow an integration of different LPWAN technologies in order to couple them with their related ecosystems. This will guarantee the inter-working by introducing a network layer, and enable common components for management and security, as well as shared application profiles. The IETF can contribute by providing IPv6 connectivity, and propose technologies to secure the operations and manage the devices and their gateways. The Working Group will focus on enabling IPv6 connectivity over the following selection of Low-Power Wide-Area technologies: SIGFOX, LoRa, WI-SUN and NB-IOT. These technologies will be used as the baseline technologies for future work. These technologies present similar characteristics of rare and widely unbalanced over-the-air transmissions, with little capability to alter the frame formats to accommodate this work, which makes it so that existing IETF work (6lo) cannot be trivially applied. The Working Group will leverage cross-participation with the associated set of stakeholders, including users and SDOs working on the baseline technologies, to ensure that the work taking place corresponds to real demands and that the proposed solutions are indeed applicable. The group has produced documents providing an overview of the baseline LPWA technologies (RFC8376) as well as a document specifying a Generic Framework for Static Context Header Compression and Fragmentation (SCHC), which provides both a header compression mechanism and an optional fragmentation mechanism (RFC8724). The group will continue to produce new standards track work to optimize IPv6-based communications to the end devices. The group will: 1. Perform SCHC Maintenance, including enabling SCHC mechanisms for Upper layer Protocols. 2. Produce Standard Track documents to apply SCHC IPv6/UDP over the baseline technologies. 3. Produce a Standards Track document to define the generic data models to formalize the compression and fragmentation contexts for LPWANs. 4. Produce a Standards Track document to enable  operations, administration and maintenance (OAM) to the LPWAN device, including support for delayed or proxied liveness verification (Ping). Goals and Milestones: May 2020 - Perform SCHC Maintenance, including enabling SCHC mechanisms for Upper layer Protocols Dec 2020 - Produce Standard Track documents to apply SCHC IPv6/UDP over the baseline technologies Feb 2021 - Produce a Standards Track document to define the generic data models to formalize the compression and fragmentation contexts for LPWANs Jul 2021 - Produce a Standards Track document to enable operations, administration and maintenance (OAM) to the LPWAN device, including support for delayed or proxied liveness verification (Ping) Internet-Drafts: - LPWAN Static Context Header Compression (SCHC) for CoAP [draft-ietf-lpwan-coap-static-context-hc-13] (29 pages) - SCHC: Generic Framework for Static Context Header Compression and Fragmentation [draft-ietf-lpwan-ipv6-static-context-hc-24] (71 pages) - Low-Power Wide Area Network (LPWAN) Overview [draft-ietf-lpwan-overview-10] (43 pages) - Static Context Header Compression (SCHC) over LoRaWAN [draft-ietf-lpwan-schc-over-lorawan-07] (25 pages) - SCHC over NB-IoT [draft-ietf-lpwan-schc-over-nbiot-02] (23 pages) - SCHC over Sigfox LPWAN [draft-ietf-lpwan-schc-over-sigfox-02] (13 pages) - Data Model for Static Context Header Compression (SCHC) [draft-ietf-lpwan-schc-yang-data-model-02] (34 pages) Requests for Comments: RFC8376: Low-Power Wide Area Network (LPWAN) Overview (43 pages) RFC8724: SCHC: Generic Framework for Static Context Header Compression and Fragmentation (71 pages) Link State Routing (lsr) ------------------------ Charter Last Modified: 2018-11-01 Current Status: Active Chairs: Acee Lindem Christian Hopps Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Alvaro Retana Secretary: Yingzhen Qu 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: Jul 2018 - OSPF YANG Model to IESG Jul 2018 - ISIS YANG model to IESG Jul 2018 - IS-IS Reverse Metric to IESG Jul 2018 - IS-IS Segment Routing MSD to IESG Nov 2018 - OSPFv3 SR to IESG Nov 2018 - OSPFv2 Attribute Agility Mar 2019 - OSPF Segment Routing YANG Model Mar 2019 - IS-IS Segment Routing SR YANG Model Jul 2019 - OSPFv3 Dual Stack (single instance) Internet-Drafts: - OSPF YANG Model Augmentations for Additional Features - Version 1 [draft-acee-lsr-ospf-yang-augmentation-v1-01] (23 pages) - YANG Model for OSPFv3 Extended LSAs [draft-acee-lsr-ospfv3-extended-lsa-yang-06] (30 pages) - IPv6 Source/Destination Routing using IS-IS [draft-baker-ipv6-isis-dst-src-routing-07] (12 pages) - Invalid TLV Handling in IS-IS [draft-ginsberg-lsr-isis-invalid-tlv-03] (8 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-12] (8 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) - YANG Data Model for IS-IS Segment Routing [draft-ietf-isis-sr-yang-07] (25 pages) - IS-IS TE Attributes per application [draft-ietf-isis-te-app-12] (21 pages) - YANG Data Model for IS-IS Protocol [draft-ietf-isis-yang-isis-cfg-42] (118 pages) - Dynamic Flooding on Dense Graphs [draft-ietf-lsr-dynamic-flooding-05] (47 pages) - IGP Flexible Algorithm [draft-ietf-lsr-flex-algo-07] (34 pages) - IS-IS Extended Hierarchy [draft-ietf-lsr-isis-extended-hierarchy-01] (19 pages) - Invalid TLV Handling in IS-IS [draft-ietf-lsr-isis-invalid-tlv-01] (8 pages) - Restart Signaling for IS-IS [draft-ietf-lsr-isis-rfc5306bis-09] (22 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 Extension to Support Segment Routing over IPv6 Dataplane [draft-ietf-lsr-isis-srv6-extensions-08] (26 pages) - OSPF Strict-Mode for BFD [draft-ietf-lsr-ospf-bfd-strict-mode-00] (10 pages) - OSPF Prefix Originator Extension [draft-ietf-lsr-ospf-prefix-originator-05] (12 pages) - OSPF Reverse Metric [draft-ietf-lsr-ospf-reverse-metric-00] (12 pages) - OSPF YANG Model Augmentations for Additional Features - Version 1 [draft-ietf-lsr-ospf-yang-augmentation-v1-01] (23 pages) - YANG Model for OSPFv3 Extended LSAs [draft-ietf-lsr-ospfv3-extended-lsa-yang-01] (30 pages) - OSPFv3 Extensions for SRv6 [draft-ietf-lsr-ospfv3-srv6-extensions-00] (23 pages) - IGP extension for PCEP security capability support in the PCE discovery [draft-ietf-lsr-pce-discovery-security-support-03] (9 pages) - YANG Module for IS-IS Reverse Metric [draft-ietf-lsr-yang-isis-reverse-metric-00] (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-13] (9 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) - YANG Data Model for OSPF SR (Segment Routing) Protocol [draft-ietf-ospf-sr-yang-11] (27 pages) - OSPF Link Traffic Engineering Attribute Reuse [draft-ietf-ospf-te-link-attr-reuse-11] (21 pages) - OSPF Routing with Cross-Address Family Traffic Engineering Tunnels [draft-ietf-ospf-xaf-te-07] (8 pages) - YANG Data Model for OSPF Protocol [draft-ietf-ospf-yang-29] (132 pages) - OSPF Strict-Mode for BFD [draft-ketant-lsr-ospf-bfd-strict-mode-03] (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) - OSPFv3 Extensions for SRv6 [draft-li-lsr-ospfv3-srv6-extensions-00] (23 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) Link State Vector Routing (lsvr) -------------------------------- Charter Last Modified: 2018-02-23 Current Status: Active Chairs: Gunter Van de Velde Victor Kuarsingh Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Alvaro Retana Mailing Lists: General Discussion: lsvr@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lsvr Archive: https://mailarchive.ietf.org/arch/browse/lsvr/ Description of Working Group: Data Centers have been steadily growing to commonly host tens of thousands of end points, or more, in a single network. Because of their topologies (traditional and emerging), traffic patterns, need for fast restoration, and for low human intervention, data center networks have a unique set of requirements that is resulting in the design of routing solutions specific to them. The Link-State Vector Routing (LSVR) Working Group is chartered to develop and document a hybrid routing protocol utilizing a combination of link-state and path-vector routing mechanisms. The LSVR WG will utilize existing IPv4/IPv6 transport, packet formats and error handling of BGP-4 consistent with BGP-LS NLRI encoding mechanisms (RFC7752) to facilitate Link-State Vector (LSV) routing information distribution. An LSV is intended to be specified as a data structure comprised of link attributes, neighbor information, and other and other potential attributes that can be utilized to make routing decisions. The LSVR specification is initially focused on operation within a single datacenter (DC) as a single distribution domain, which is defined as a set of participating nodes in a single administrative domain. Routing protocol functionality defined by LSVR would be typically routing within a datacenter’s underlay routing plane. The work will include coexistence considerations with BGP IPv4/IPv6 unicast address families installing and advertising routes into the same RIB. The WG will consider the effects (if any) of deploying the LSVR protocol while concurrently using the same transport session as other existing BGP address families. These considerations will be documented as part of the main protocol specification. A mechanism to be able to independently deploy LSVR from other address families may be defined (as needed). The LSVR protocol is intended as a self-standing routing protocol even if using existing BGP transport mechanisms and encodings, or if sharing the same transport session with other existing BGP address families. Similar as existing routing protocols, the LSVR protocol will not internally combine the route selection mechanisms or share routing information, except through common external interaction methods in the RIB. In order to achieve the noted objective, the working group will focus on standardization of protocol functionality, defining Link-State Vectors (LSVs) and defining standard path-vector route selection utilizing the Dijkstra SPF based algorithm, BGP-4 protocol mechanics and BGP-LS NRLI encoding. The working group will provide specifications to manage routing information from other unicast routing protocols or BGP address families to common prefixes. The LSVR WG is chartered to deliver the following documents: - Specification document describing LSV with standard Dijkstra SPF route/path selection (calculation) utilizing existing BGP protocol baseline functionality and BGP-LS packet encoding formats - Specification documenting protocol extensions required to efficiently reuse BGP to distribute LSVs within an IPv4/IPv6 DC with scope to include privacy and security considerations - The impact of these extensions to the security properties of BGP will be studied and documented - New attack vectors will be explored and documented - Mitigations to any new attack vectors identified will be discussed and documented - Applicability Statement for the use of LSVR in the Datacenter - YANG model specification for LSVR management The WG will closely collaborate with the idr WG. Any modifications or extension to BGP that will not be specifically constrained to be used by LSVR must be carried out in the idr WG, but may be done in this WG after agreement with all the relevant chairs and the responsible Area Directors. Goals and Milestones: Mar 2019 - LSVR with standard Dijkstra path selection Mar 2019 - LSV distribution using BGP transport Mar 2019 - Applicability statement for LSVR in DCs Jul 2019 - YANG specification for LSVR Internet-Drafts: - Usage and Applicability of Link State Vector Routing in Data Centers [draft-ietf-lsvr-applicability-05] (14 pages) - Shortest Path Routing Extensions for BGP Protocol [draft-ietf-lsvr-bgp-spf-09] (22 pages) - Layer 3 Discovery and Liveness [draft-ietf-lsvr-l3dl-04] (35 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 Light-Weight Implementation Guidance (lwig) ------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Mohit Sethi Zhen Cao Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Erik Kline Mailing Lists: General Discussion: lwip@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lwip Archive: https://mailarchive.ietf.org/arch/browse/lwip/ Description of Working Group: Communications technology is being embedded into our environment. Different types of devices in our buildings, vehicles, equipment and other objects have a need to communicate. It is expected that most of these devices will employ the Internet Protocol suite. However, there is a lot of variation in the capabilities between different types of devices, and it is not always easy to embed all the necessary features. The Light-Weight Implementation Guidance (LWIG) Working Group focuses on helping the implementors of the smallest devices. The goal is to be able to build minimal yet interoperable IP-capable devices for the most constrained environments. Building a small implementation does not have to be hard. Many small devices use stripped down versions of general purpose operating systems and their TCP/IP stacks. However, there are implementations that go even further in minimization and can exist in as few as a couple of kilobytes of code, as on some devices this level of optimization is necessary. Technical and cost considerations may limit the computing power, battery capacity, available memory, or communications bandwidth that can be provided. To overcome these limitations the implementors have to employ the right hardware and software mechanisms. For instance, certain types of memory management or even fixed memory allocation may be required. It is also useful to understand what is necessary from the point of view of the communications protocols and the application employing them. For instance, a device that only acts as a client or only requires one connection can simplify its TCP implementation. The purpose of the LWIG working group is to collect experiences from implementors of IP stacks in constrained devices. The group shall focus only on techniques that have been used in actual implementations and do not impact interoperability with other devices. The techniques shall also not affect conformance to the relevant specifications. The output of this work is a document that describes implementation techniques for reducing complexity, memory footprint, or power usage. The topics for this working group will be chosen from these protocols: IPv4, IPv6, UDP, TCP, ICMPv4/v6, MLD/IGMP, ND, DNS, DHCPv4/v6, IPsec, 6LOWPAN, COAP, RPL, SNMP and NETCONF protocols. This document will be helpful for the implementors of new devices or for the implementors of new general-purpose small IP stacks. It is also expected that the document increases our knowledge of what existing small implementations do, and helps in the further optimization of the existing implementations. On areas where the considerations for small implementations have already been documented the group shall make an effort to refer to those documents instead of developing its own. Generic hardware design advice and software implementation techniques are outside the scope of this work, as such expertise is not within the IETF domain. Protocol implementation experience, however, is within the IETF domain. The group shall also not develop any new protocols or protocol behavior modifications beyond what is already allowed by existing RFCs, because it is important to ensure that different types of devices can work together. The group shall not develop assumptions or profiles about the operating environment of the devices, because, in general, it is not possible to guarantee any special configuration. Finally, while implementation techniques relating to security mechanisms are within scope, mere removal of security functionality from a protocol is not an acceptable recommendation. Given that the group works on both IP and transport layer protocols it is necessary to ensure that expertise in both aspects is present in the group. Participation from the implementors of existing small IP stacks is also required. Goals and Milestones: Nov 2018 - Submit the CoAP implementation document to the IESG for publication as an Informational RFC Nov 2018 - Submit the TCP over constrained networks guidance document to the IESG for publication as an Informational RFC Nov 2018 - Submit the minimal ESP guidance document to the IESG for publication as an Informational RFC Done - Submit the terminology document to the IESG for publication as an Informational RFC Done - Submit the implementation guidance document to the IESG for publication as an Informational RFC Done - Submit the minimal IKEv2 implementation document to the IESG for publication as an Informational RFC Done - Submit the energy efficient implementation guidance document to the IESG for publication as an Informational RFC Done - Submit the lightweight crypto implementation document to the IESG for publication as an Informational RFC Internet-Drafts: - Virtual reassembly buffers in 6LoWPAN [draft-bormann-lwig-6lowpan-virtual-reassembly-00] (5 pages) - TCP over Constrained-Node Networks [draft-gomez-lwig-tcp-constrained-node-networks-03] (17 pages) - Virtual reassembly buffers in 6LoWPAN [draft-ietf-lwig-6lowpan-virtual-reassembly-02] (6 pages) - Building Power-Efficient CoAP Devices for Cellular Networks [draft-ietf-lwig-cellular-06] (16 pages) - CoAP Implementation Guidance [draft-ietf-lwig-coap-06] (31 pages) - Practical Considerations and Implementation Experiences in Securing Smart Object Networks [draft-ietf-lwig-crypto-sensors-06] (33 pages) - Alternative Elliptic Curve Representations [draft-ietf-lwig-curve-representations-10] (115 pages) - Energy-Efficient Features of Internet of Things Protocols [draft-ietf-lwig-energy-efficient-08] (24 pages) - Guidance for Light-Weight Implementations of the Internet Protocol Suite [draft-ietf-lwig-guidance-03] (34 pages) - Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation [draft-ietf-lwig-ikev2-minimal-05] (41 pages) - Minimal ESP [draft-ietf-lwig-minimal-esp-00] (13 pages) - Neighbor Management Policy for 6LoWPAN [draft-ietf-lwig-nbr-mgmt-policy-03] (20 pages) - Comparison of CoAP Security Protocols [draft-ietf-lwig-security-protocol-comparison-04] (40 pages) - TCP Usage Guidance in the Internet of Things (IoT) [draft-ietf-lwig-tcp-constrained-node-networks-09] (29 pages) - Terminology for Constrained-Node Networks [draft-ietf-lwig-terminology-07] (17 pages) - A Hitchhiker's Guide to the (Datagram) Transport Layer Security Protocol for Smart Objects and Constrained Node Networks [draft-ietf-lwig-tls-minimal-01] (15 pages) - Neighbor Management Policy for 6LoWPAN [draft-jadhav-lwig-nbr-mgmt-policy-01] (18 pages) - Minimal ESP [draft-mglt-lwig-minimal-esp-07] (13 pages) Requests for Comments: RFC7228: Terminology for Constrained-Node Networks (17 pages) RFC7815: Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation (41 pages) RFC8352: Energy-Efficient Features of Internet of Things Protocols (24 pages) RFC8387: Practical Considerations and Implementation Experiences in Securing Smart Object Networks (33 pages) Mobile Ad-hoc Networks (manet) ------------------------------ Charter Last Modified: 2019-11-20 Current Status: Active Chair: Ronald in 't Velt Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Alvaro Retana 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 Credit-Based Flow Control Messages and Data Items [draft-ietf-manet-dlep-credit-flow-control-05] (18 pages) - DLEP DiffServ Aware Credit Window Extension [draft-ietf-manet-dlep-da-credit-extension-08] (6 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 Traffic Classification Data Item [draft-ietf-manet-dlep-traffic-classification-02] (13 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) 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 RFC7188 * Updates RFC7183 * 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 RFC7188 * Updates RFC7187 * Updates RFC7183 * 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) MBONE Deployment (mboned) ------------------------- Charter Last Modified: 2017-03-29 Current Status: Active Chairs: Greg Shepherd Leonard Giuliano Operations and Management Area Directors: Warren Kumari Robert Wilton 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-00] (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-00] (15 pages) - Multicast in the Data Center Overview [draft-ietf-mboned-dc-deploy-09] (18 pages) - Deprecating ASM for Interdomain Multicast [draft-ietf-mboned-deprecate-interdomain-asm-07] (16 pages) - Discovery Of Restconf Metadata for Source-specific multicast [draft-ietf-mboned-dorms-00] (17 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-11] (26 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 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 YANG Data Model [draft-ietf-mboned-multicast-yang-model-03] (35 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) - IANA Guidelines for IPv4 Multicast Address Assignments [draft-ietf-mboned-rfc3171-update-00] (9 pages) - IANA Guidelines for IPv4 Multicast Address Assignments [draft-ietf-mboned-rfc3171bis-08] (11 pages) - Overview of the Internet Multicast Routing Architecture [draft-ietf-mboned-routingarch-12] (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: BCP120: Source-Specific Protocol Independent Multicast in 232/8 (7 pages) BCP121: Multicast Source Discovery Protocol (MSDP) Deployment Scenarios (14 pages) BCP213: Use of Multicast across Inter-domain Peering Points (44 pages) BCP23: Administratively Scoped IP Multicast (8 pages) BCP51: IANA Guidelines for IPv4 Multicast Address Assignments (11 pages) BCP53: GLOP Addressing in 233/8 (5 pages) 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 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) Managed Incident Lightweight Exchange (mile) -------------------------------------------- Charter Last Modified: 2020-05-05 Current Status: Active Chairs: Nancy Cam-Winget Takeshi Takahashi Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Murray Kucherawy Secretary: David Waltermire Mailing Lists: General Discussion: mile@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mile Archive: https://mailarchive.ietf.org/arch/browse/mile/ Description of Working Group: The Managed Incident Lightweight Exchange (MILE) working group develops standards to support computer and network security incident management; an incident is an unplanned event that occurs in an information technology (IT) infrastructure. An incident could be a benign configuration issue, IT incident, a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, or suspected, there may be a need for organizations to collaborate. This collaboration effort may take several forms including joint analysis, information dissemination, and/or a coordinated operational response. Examples of the response may include filing a report, notifying the source of the incident, requesting that a third-party resolve/mitigate the incident, sharing select indicators of compromise, or requesting that the source be located. By sharing indicators of compromise associated with an incident or possible threat, the information becomes a proactive defense for others that may include mitigation options. The MILE WG is focused on two areas: standardizing a data format for representing incident and indicator data, and standardizing how application-level protocols such as HTTPS and XMPP become substrates for sharing the structured data. With respect to the data format, the working group has adopted the Incident Object Description Exchange Format (IODEF, RFC 7970) as one exchange format and will continue to: - Revise the IODEF document to incorporate enhancements and extensions based on operational experience. Use by the Computer Security Incident Response Teams (CSIRTs) and others has exposed the need to extend IODEF to support industry specific extensions, use case specific content, and representations to associate information related to represented threats (system, threat actors, campaigns, etc.). The value of information sharing has been demonstrated and highlighted at an increasing rate through the success of the Information Sharing and Analysis Centers (ISACs). In addition, the Multinational Alliance for Collaborative Cyber Situational Awareness (CCSA) have been running experiments to determine what data is useful to exchange between industries and nations to effectively mitigate threats. The work of these and other groups have identified and continue to develop data representations relevant to their use cases that may compliment/extend IODEF. - Provide guidance on the implementation and use of IODEF to facilitate interoperability. Though the working group also adopted Real-time Inter-network Defense (RID, RFC 6545) as further enabling information exchange of security policy, its transport mechanism, based on the Simple Object Access Protocol (SOAP), led to the second focus for MILE: adopting more modern transport through the adoption of a RESTful interface through ROLIE (Resource-oriented lightweight information exchange, RFC 8322) and the adoption of a publish-subscribe model through XMPP-Grid (draft-ietf-mile-xmpp-grid). The MILE WG will continue to: - Update and enhance these application-level substrate protocols to optimize their performance and representations. More explicitly, documenting how ROLIE can transport JSON representations. - Define and document how these application-level substrate protocols can also be used to support other security information exchange formats. For example, documenting how ROLIE can transport STIX (Structured Threat Information Expression) data. As STIX is a expression format defined by the OASIS consortium, the working group will maintain a relationship with OASIS to ensure proper use, compatibility and interoperability when using STIX. Goals and Milestones: Apr 2019 - Submit a draft on RESTful indicator exchange for CSIRT usage as an Informational RFC Apr 2019 - Submit a draft on JSON bindings of IODEF to the IESG for publication as a Standards Track RFC Apr 2019 - Submit a draft on ROLIE vulnerability extension as an Informational RFC Done - Submit a draft on XMPP Protocol Extensions for Use with IODEF Internet-Drafts: - XMPP Protocol Extensions for Use with IODEF [draft-appala-mile-xmpp-grid-00] (45 pages) - Enumeration Reference Format for the Incident Object Description Exchange Format (IODEF) [draft-ietf-mile-enum-reference-format-14] (10 pages) - GRC Report Exchange [draft-ietf-mile-grc-exchange-01] (68 pages) - Management Incident Lightweight Exchange (MILE) Implementation Report [draft-ietf-mile-implementreport-10] (16 pages) - Incident Object Description Exchange Format Usage Guidance [draft-ietf-mile-iodef-guidance-11] (33 pages) - Expert Review for Incident Object Description Exchange Format (IODEF) Extensions in IANA XML Registry [draft-ietf-mile-iodef-xmlreg-01] (3 pages) - JSON binding of IODEF [draft-ietf-mile-jsoniodef-14] (81 pages) - The Incident Object Description Exchange Format Version 2 [draft-ietf-mile-rfc5070-bis-26] (172 pages) - Real-time Inter-network Defense (RID) [draft-ietf-mile-rfc6045-bis-11] (84 pages) - Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS [draft-ietf-mile-rfc6046-bis-09] (8 pages) - Resource-Oriented Lightweight Information Exchange (ROLIE) [draft-ietf-mile-rolie-16] (43 pages) - Definition of ROLIE CSIRT Extension [draft-ietf-mile-rolie-csirt-06] (16 pages) - Definition of the ROLIE Vulnerability Extension [draft-ietf-mile-rolie-vuln-03] (8 pages) - An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information [draft-ietf-mile-sci-13] (28 pages) - Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF) [draft-ietf-mile-template-05] (12 pages) - Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange [draft-ietf-mile-xmpp-grid-11] (28 pages) Requests for Comments: RFC6545: Real-time Inter-network Defense (RID) (84 pages) RFC6546: Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS (8 pages) RFC6684: Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF) (12 pages) RFC6685: Expert Review for Incident Object Description Exchange Format (IODEF) Extensions in IANA XML Registry (3 pages) * Obsoletes RFC7970 RFC7203: An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information (28 pages) RFC7495: Enumeration Reference Format for the Incident Object Description Exchange Format (IODEF) (10 pages) RFC7970: The Incident Object Description Exchange Format Version 2 (172 pages) RFC8134: Management Incident Lightweight Exchange (MILE) Implementation Report (16 pages) RFC8274: Incident Object Description Exchange Format Usage Guidance (33 pages) RFC8322: Resource-Oriented Lightweight Information Exchange (ROLIE) (43 pages) RFC8600: Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange (28 pages) Messaging Layer Security (mls) ------------------------------ Charter Last Modified: 2019-01-14 Current Status: Active Chairs: Nick Sullivan Sean Turner Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Benjamin Kaduk 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: Several Internet applications have a need for group key establishment and message protection protocols with the following properties: o Message Confidentiality - Messages can only be read by members of the group o Message Integrity and Authentication - Each message has been sent by an authenticated sender, and has not been tampered with o Membership Authentication - Each participant can verify the set of members in the group o Asynchronicity - Keys can be established without any two participants being online at the same time o Forward secrecy - Full compromise of a node at a point in time does not reveal past messages sent within the group o Post-compromise security - Full compromise of a node at a point in time does not reveal future messages sent within the group o Scalability - Resource requirements have good scaling in the size of the group (preferably sub-linear) Several widely-deployed applications have developed their own protocols to meet these needs. While these protocols are similar, no two are close enough to interoperate. As a result, each application vendor has had to maintain their own protocol stack and independently build trust in the quality of the protocol. The primary goal of this working group is to develop a standard messaging security protocol for human-to-human(s) communication with the above security and deployment properties so that applications can share code, and so that there can be shared validation of the protocol (as there has been with TLS 1.3). Humans are assumed to have access to one or more general-purpose computers. It is not a goal of this group to enable interoperability/federation between messaging applications beyond the key establishment, authentication, and confidentiality services. Full interoperability would require alignment at many different layers beyond security, e.g., standard message transport and application semantics. The focus of this work is to develop a messaging security layer that different applications can adapt to their own needs. While authentication is a key goal of this working group, it is not the objective of this working group to develop new authentication technologies. Rather, the security protocol developed by this group will provide a way to leverage existing authentication technologies to associate identities with keys used in the protocol, just as TLS does with X.509. In developing this protocol, we will draw on lessons learned from several prior message-oriented security protocols, in addition to the proprietary messaging security protocols deployed within existing applications: o S/MIME - https://tools.ietf.org/html/rfc5751 o OpenPGP - https://tools.ietf.org/html/rfc4880 o Off the Record - https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html o Double Ratchet - https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm The intent of this working group is to follow the pattern of TLS 1.3, with specification, implementation, and verification proceeding in parallel. By the time we arrive at RFC, we hope to have several interoperable implementations as well as a thorough security analysis. The specifications developed by this working group will be based on pre-standardization implementation and deployment experience, and generalizing the design described in: o draft-omara-mls-architecture o draft-barnes-mls-protocol Note that consensus is required both for changes to the protocol mechanisms from these documents and retention of the mechanisms from them. In particular, because something is in the initial document set does not imply that there is consensus around the feature or around how it is specified. Goals and Milestones: May 2018 - Initial working group documents for architecture and key management Sep 2018 - Initial working group document adopted for message protection Jan 2019 - Submit architecture document to IESG as Informational Jun 2019 - Submit key management protocol to IESG as Proposed Standard Sep 2019 - Submit message protection protocol to IESG as Proposed Standard Internet-Drafts: - The Messaging Layer Security (MLS) Protocol [draft-barnes-mls-protocol-01] (37 pages) - The Messaging Layer Security (MLS) Architecture [draft-ietf-mls-architecture-04] (18 pages) - The Messaging Layer Security (MLS) Federation [draft-ietf-mls-federation-00] (8 pages) - The Messaging Layer Security (MLS) Protocol [draft-ietf-mls-protocol-09] (73 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) No Requests for Comments Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Bo Burman Flemming Andreasen Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: mmusic@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mmusic Archive: https://mailarchive.ietf.org/arch/browse/mmusic/ Description of Working Group: The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group was originally chartered to develop protocols to support Internet teleconferencing and multimedia communications. These protocols are now reasonably mature, and many have received widespread deployment. Currently, the group is focused on using and negotiating media streams with the Session Description Protocol (SDP), which is used as a common protocol to express media and session descriptions. The group also maintains the Real-time Streaming Protocol (RTSP) specifications. The group has revised these protocols in the light of implementation experience and additional demands that have arisen from other WGs (such as AVTCORE, CLUE, ICE, and RTCWEB). In particular, the many uses of SDP have led to requests for numerous extensions as well as a recognition of several limitations in the original protocol design. Today, the SDP protocol is widely deployed and continues to see extensions being defined. The current aims of the working group include the following: - Provide SDP signaling support for the Interactive Connectivity Establishment (ICE) protocol and its extensions. These were originally defined in MMUSIC, but are now handled by the ICE WG. - To support the establishment of multi-party multimedia sessions for RTCWEB based implementations, MMUSIC provides SDP signaling support for a number of extensions required by RTCWEB. The MMUSIC WG will seek a balanced trade-off between general applicability of such extensions versus RTCWEB specific usage. - Various other extensions to SDP may be pursued to remedy the most urgent of SDP's shortcomings. These include updates to the SDP specification itself and missing IANA registrations. - With the exception of the items listed above, only extensions within the existing SDP framework will be done. - Maintain the specification of the (revised) Real Time Streaming Protocol (RTSP) as needed. The MMUSIC work items will be pursued in close coordination with other IETF WGs including AVTCORE, CLUE, ICE, RTCWEB and SIPCORE, as well as others where appropriate. Goals and Milestones: Mar 2020 - Submit T.140 Real-time Text Conversation over WebRTC Data Channels as Proposed Standard Jul 2020 - Submit SDP Negotiation of MSRP over Data Channels as Proposed Standard Done - Submit a framework for SDP attributes when multiplexing as Proposed Standard Done - Submit IANA registrations of SDP 'proto' attribute for transporting RTP Media over TCP under various RTP profiles as Proposed Standard Done - Submit SDP extension for cross session stream identification as Proposed Standard Done - Submit Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP as Proposed Standard Done - Submit SCTP-Based Media Transport in SDP as Proposed Standard. Done - Using the SDP Offer/Answer Mechanism for DTLS Done - Submit RTP Payload Format Constraints as Proposed Standard Done - Submit SDP extensions to negotiate multiplexed media streams as Proposed Standard Done - Submit SIP usage for Trickle ICE as Proposed Standard Done - Submit Using Simulcast in SDP and RTP Sessions as Proposed Standard Done - Submit revised SDP specification to IETF as Proposed Standard Done - Submit SDP Negotiation of DataChannel sub-protocols as Proposed Standard Done - Submit Interactive Connectivity Establishment (ICE) with SDP offer/answer and SIP as Proposed Standard Done - Submit Unknown Key Share Attacks on uses of Transport Layer Security with the Session Description Protocol as Proposed Standard Internet-Drafts: - T.140 Real-time Text Conversation over WebRTC Data Channels [draft-holmberg-mmusic-t140-usage-data-channel-02] (16 pages) - Negotiating SRTP and RTCP Feedback using the RTP/AVP Profile [draft-hutton-mmusic-opportunistic-negotiation-00] (6 pages) - Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) [draft-ietf-mmusic-4572-update-13] (18 pages) - Managing Shared Ephemeral Teleconferencing State: Policy and Mechanism [draft-ietf-mmusic-agree-00] (29 pages) - The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework [draft-ietf-mmusic-anat-02] (7 pages) - Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) [draft-ietf-mmusic-comedia-tls-06] (17 pages) - The Internet Multimedia Conferencing Architecture [draft-ietf-mmusic-confarch-03] (28 pages) - Connection-Establishment Preconditions in the Session Initiation Protocol (SIP) [draft-ietf-mmusic-connection-precon-01] (8 pages) - Connectivity Preconditions for Session Description Protocol (SDP) Media Streams [draft-ietf-mmusic-connectivity-precon-07] (17 pages) - SDP-based Data Channel Negotiation [draft-ietf-mmusic-data-channel-sdpneg-28] (40 pages) - Signaling Media Decoding Dependency in the Session Description Protocol (SDP) [draft-ietf-mmusic-decoding-dependency-08] (18 pages) - Duplication Delay Attribute in the Session Description Protocol [draft-ietf-mmusic-delayed-duplication-03] (11 pages) - Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS) [draft-ietf-mmusic-dtls-sdp-32] (27 pages) - Duplication Grouping Semantics in the Session Description Protocol [draft-ietf-mmusic-duplication-grouping-04] (10 pages) - Forward Error Correction Grouping Semantics in Session Description Protocol [draft-ietf-mmusic-fec-grouping-05] (6 pages) - Grouping of Media Lines in the Session Description Protocol (SDP) [draft-ietf-mmusic-fid-06] (11 pages) - A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer [draft-ietf-mmusic-file-transfer-mech-11] (50 pages) - Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols [draft-ietf-mmusic-ice-19] (117 pages) - ICE Multihomed and IPv4/IPv6 Dual Stack Fairness [draft-ietf-mmusic-ice-dualstack-fairness-02] (10 pages) - IANA Registry for Interactive Connectivity Establishment (ICE) Options [draft-ietf-mmusic-ice-options-registry-02] (5 pages) - Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE) [draft-ietf-mmusic-ice-sip-sdp-39] (43 pages) - TCP Candidates with Interactive Connectivity Establishment (ICE) [draft-ietf-mmusic-ice-tcp-16] (29 pages) - Negotiation of Generic Image Attributes in the Session Description Protocol (SDP) [draft-ietf-mmusic-image-attributes-11] (23 pages) - A Framework for the Usage of Internet Media Guides (IMGs) [draft-ietf-mmusic-img-framework-09] (22 pages) - Requirements for Internet Media Guides (IMGs) [draft-ietf-mmusic-img-req-08] (23 pages) - Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) [draft-ietf-mmusic-kmgmt-ext-15] (30 pages) - Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication [draft-ietf-mmusic-latching-08] (16 pages) - An Mbus Profile for Call Control [draft-ietf-mmusic-mbus-call-control-00] (37 pages) - The Message Bus: Guidelines for Application Profile Writers [draft-ietf-mmusic-mbus-guidelines-00] (49 pages) - Requirements for Local Conference Control [draft-ietf-mmusic-mbus-req-00] (10 pages) - A Message Bus for Local Coordination [draft-ietf-mmusic-mbus-transport-06] (39 pages) - An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback [draft-ietf-mmusic-media-loopback-27] (33 pages) - Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path [draft-ietf-mmusic-media-path-middleboxes-07] (20 pages) - WebRTC MediaStream Identification in the Session Description Protocol [draft-ietf-mmusic-msid-17] (19 pages) - MSRP over Data Channels [draft-ietf-mmusic-msrp-usage-data-channel-16] (18 pages) - Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP [draft-ietf-mmusic-mux-exclusive-12] (14 pages) - Short term NAT requirements for UDP based peer-to-peer applications [draft-ietf-mmusic-natreq4udp-00] (6 pages) - Session Description Protocol (SDP) Offer/Answer Examples [draft-ietf-mmusic-offer-answer-examples-06] (24 pages) - Negotiating SRTP and RTCP Feedback using the RTP/AVP Profile [draft-ietf-mmusic-opportunistic-negotiation-01] (7 pages) - SDP attribute to signal parallax [draft-ietf-mmusic-parallax-attribute-00] (15 pages) - Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles [draft-ietf-mmusic-proto-iana-registration-06] (7 pages) - Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP) [draft-ietf-mmusic-qos-identification-03] (9 pages) - Mapping of Media Streams to Resource Reservation Flows [draft-ietf-mmusic-reservation-flows-01] (6 pages) - Real-Time Streaming Protocol Version 2.0 [draft-ietf-mmusic-rfc2326bis-40] (318 pages) - The Session Description Protocol (SDP) Grouping Framework [draft-ietf-mmusic-rfc3388bis-04] (21 pages) - SDP: Session Description Protocol [draft-ietf-mmusic-rfc4566bis-37] (63 pages) - Forward Error Correction Grouping Semantics in the Session Description Protocol [draft-ietf-mmusic-rfc4756bis-10] (14 pages) - Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal [draft-ietf-mmusic-rfc5245bis-05] (91 pages) - RTP Payload Format Restrictions [draft-ietf-mmusic-rid-15] (28 pages) - Real Time Streaming Protocol (RTSP) [draft-ietf-mmusic-rtsp-08] (92 pages) - RTSP Announce Method [draft-ietf-mmusic-rtsp-announce-01] (0 pages) - A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP) [draft-ietf-mmusic-rtsp-nat-22] (33 pages) - Comparison of Different NAT Traversal Techniques for Media Controlled by the Real-Time Streaming Protocol (RTSP) [draft-ietf-mmusic-rtsp-nat-evaluation-16] (46 pages) - SAP: Session Announcement Protocol [draft-ietf-mmusic-sap-00] (14 pages) - SAP Security Using Public Key Algorithms [draft-ietf-mmusic-sap-sec-04] (18 pages) - Session Announcement Protocol [draft-ietf-mmusic-sap-v2-06] (18 pages) - Simple Conference Control Protocol [draft-ietf-mmusic-sccp-01] (24 pages) - Simple Conference Invitation Protocol [draft-ietf-mmusic-scip-00] (18 pages) - Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport. [draft-ietf-mmusic-sctp-sdp-26] (26 pages) - Session Description Protocol (SDP) Security Descriptions for Media Streams [draft-ietf-mmusic-sdescriptions-12] (44 pages) - SDP: Session Description Protocol [draft-ietf-mmusic-sdp-06] (42 pages) - Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections [draft-ietf-mmusic-sdp-atm-05] (110 pages) - Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams [draft-ietf-mmusic-sdp-bfcp-03] (12 pages) - Negotiating Media Multiplexing Using the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-bundle-negotiation-54] (69 pages) - A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-bwparam-06] (22 pages) - Session Description Protocol (SDP) Capability Negotiation [draft-ietf-mmusic-sdp-capability-negotiation-13] (77 pages) - SDP Capability Negotiation: Requirements and Review of Existing Work [draft-ietf-mmusic-sdp-capability-negotiation-reqts-01] (23 pages) - TCP-Based Media Transport in the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-comedia-10] (15 pages) - Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN) [draft-ietf-mmusic-sdp-cs-23] (39 pages) - Describing session directories in SDP [draft-ietf-mmusic-sdp-directory-type-02] (0 pages) - Session Description Protocol (SDP) Indicators for Datagram Transport Layer Security (DTLS) [draft-ietf-mmusic-sdp-dtls-00] (8 pages) - Offer/Answer Considerations for G.723 Annex A and G.729 Annex B [draft-ietf-mmusic-sdp-g273-g729-00] (8 pages) - Offer/Answer Considerations for G723 Annex A and G729 Annex B [draft-ietf-mmusic-sdp-g723-g729-06] (8 pages) - Implementation Status Of SDP [draft-ietf-mmusic-sdp-implem-00] (18 pages) - Support for IPv6 in Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-ipv6-03] (5 pages) - Session Description Protocol (SDP) Media Capabilities Negotiation [draft-ietf-mmusic-sdp-media-capabilities-17] (55 pages) - The Session Description Protocol (SDP) Content Attribute [draft-ietf-mmusic-sdp-media-content-06] (11 pages) - The Session Description Protocol (SDP) Label Attribute [draft-ietf-mmusic-sdp-media-label-01] (8 pages) - Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-misc-cap-00] (17 pages) - Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-miscellaneous-caps-07] (22 pages) - A Framework for SDP Attributes when Multiplexing [draft-ietf-mmusic-sdp-mux-attributes-17] (97 pages) - SDP: Session Description Protocol [draft-ietf-mmusic-sdp-new-26] (49 pages) - An Offer/Answer Model with Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-offer-answer-02] (25 pages) - Establishing QoS and Security Preconditions for SDP Sessions [draft-ietf-mmusic-sdp-qos-00] (13 pages) - Using Simulcast in SDP and RTP Sessions [draft-ietf-mmusic-sdp-simulcast-14] (41 pages) - Source-Specific Media Attributes in the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-source-attributes-02] (18 pages) - Session Description Protocol (SDP) Source Filters [draft-ietf-mmusic-sdp-srcfilter-10] (14 pages) - SDP Extensions for Fax over IP Using T.38 [draft-ietf-mmusic-sdp-t38-00] (4 pages) - TCP-Based Media Transport in SDP [draft-ietf-mmusic-sdp-tcpmedia-00] (9 pages) - Unknown Key Share Attacks on uses of TLS with the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-uks-07] (19 pages) - Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP) [draft-ietf-mmusic-sdp4nat-05] (8 pages) - Session Description and Capability Negotiation [draft-ietf-mmusic-sdpng-08] (61 pages) - Requirements for Session Description and Capability Negotiation [draft-ietf-mmusic-sdpng-req-01] (24 pages) - SDPng Transition [draft-ietf-mmusic-sdpng-trans-04] (15 pages) - Security Preconditions for Session Description Protocol (SDP) Media Streams [draft-ietf-mmusic-securityprecondition-04] (16 pages) - Signal 3D format [draft-ietf-mmusic-signal-3d-format-00] (27 pages) - SIP: Session Initiation Protocol [draft-ietf-mmusic-sip-12] (151 pages) - Reliability of Provisional Responses in SIP [draft-ietf-mmusic-sip-100rel-01] (12 pages) - SIP Caller Preferences and Callee Capabilities [draft-ietf-mmusic-sip-caller-00] (16 pages) - SIP Call Control Services [draft-ietf-mmusic-sip-cc-01] (34 pages) - The SIP INFO Method [draft-ietf-mmusic-sip-info-method-01] (6 pages) - The SIP ISUP/MIME type [draft-ietf-mmusic-sip-isup-mime-00] (4 pages) - The multipart/sip-id media type [draft-ietf-mmusic-sip-multipart-00] (4 pages) - SIP Security Using Public Key Algorithms [draft-ietf-mmusic-sip-sec-00] (24 pages) - SIP Session Timer [draft-ietf-mmusic-sip-session-timer-02] (12 pages) - SIP URL Scheme [draft-ietf-mmusic-sip-url-00] (3 pages) - A real-time stream control protocol (RTSP') [draft-ietf-mmusic-stream-00] (25 pages) - T.140 Real-time Text Conversation over WebRTC Data Channels [draft-ietf-mmusic-t140-usage-data-channel-14] (19 pages) - The Session Description Protocol (SDP) 'trafficclass' Attribute [draft-ietf-mmusic-traffic-class-for-sdp-05] (29 pages) - Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol [draft-ietf-mmusic-trickle-ice-02] (25 pages) - A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE) [draft-ietf-mmusic-trickle-ice-sip-18] (47 pages) - UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS) [draft-ietf-mmusic-udptl-dtls-10] (23 pages) Requests for Comments: RFC2326: Real Time Streaming Protocol (RTSP) (92 pages) * Obsoletes RFC7826 RFC2327: SDP: Session Description Protocol (42 pages) * Obsoletes RFC4566 * Updates RFC3266 RFC2543: SIP: Session Initiation Protocol (151 pages) * Obsoletes RFC3261 * Obsoletes RFC3262 * Obsoletes RFC3263 * Obsoletes RFC3264 * Obsoletes RFC3265 RFC2974: Session Announcement Protocol (18 pages) RFC3108: Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections (110 pages) RFC3259: A Message Bus for Local Coordination (39 pages) RFC3264: An Offer/Answer Model with Session Description Protocol (SDP) (25 pages) * Updates RFC6157 RFC3266: Support for IPv6 in Session Description Protocol (SDP) (5 pages) * Obsoletes RFC4566 RFC3388: Grouping of Media Lines in the Session Description Protocol (SDP) (11 pages) * Obsoletes RFC5888 RFC3524: Mapping of Media Streams to Resource Reservation Flows (6 pages) RFC3605: Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP) (8 pages) RFC3890: A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP) (22 pages) RFC4091: The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework (7 pages) * Obsoletes RFC5245 RFC4145: TCP-Based Media Transport in the Session Description Protocol (SDP) (15 pages) * Updates RFC4572 RFC4317: Session Description Protocol (SDP) Offer/Answer Examples (24 pages) RFC4435: A Framework for the Usage of Internet Media Guides (IMGs) (22 pages) RFC4473: Requirements for Internet Media Guides (IMGs) (23 pages) RFC4566: SDP: Session Description Protocol (49 pages) RFC4567: Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) (30 pages) RFC4568: Session Description Protocol (SDP) Security Descriptions for Media Streams (44 pages) RFC4570: Session Description Protocol (SDP) Source Filters (14 pages) RFC4572: Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) (17 pages) * Obsoletes RFC8122 RFC4574: The Session Description Protocol (SDP) Label Attribute (8 pages) RFC4583: Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams (12 pages) RFC4756: Forward Error Correction Grouping Semantics in Session Description Protocol (6 pages) * Obsoletes RFC5956 RFC4796: The Session Description Protocol (SDP) Content Attribute (11 pages) RFC5027: Security Preconditions for Session Description Protocol (SDP) Media Streams (16 pages) RFC5245: Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols (117 pages) * Updates RFC6336 * Obsoletes RFC8445 RFC5432: Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP) (9 pages) RFC5547: A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer (50 pages) RFC5576: Source-Specific Media Attributes in the Session Description Protocol (SDP) (18 pages) RFC5583: Signaling Media Decoding Dependency in the Session Description Protocol (SDP) (18 pages) RFC5888: The Session Description Protocol (SDP) Grouping Framework (21 pages) RFC5898: Connectivity Preconditions for Session Description Protocol (SDP) Media Streams (17 pages) RFC5939: Session Description Protocol (SDP) Capability Negotiation (77 pages) * Updates RFC6871 RFC5956: Forward Error Correction Grouping Semantics in the Session Description Protocol (14 pages) RFC6236: Negotiation of Generic Image Attributes in the Session Description Protocol (SDP) (23 pages) RFC6336: IANA Registry for Interactive Connectivity Establishment (ICE) Options (5 pages) RFC6544: TCP Candidates with Interactive Connectivity Establishment (ICE) (29 pages) RFC6849: An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback (33 pages) RFC6871: Session Description Protocol (SDP) Media Capabilities Negotiation (55 pages) RFC7006: Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP) (22 pages) RFC7104: Duplication Grouping Semantics in the Session Description Protocol (10 pages) RFC7195: Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN) (39 pages) RFC7197: Duplication Delay Attribute in the Session Description Protocol (11 pages) RFC7261: Offer/Answer Considerations for G723 Annex A and G729 Annex B (8 pages) RFC7345: UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS) (23 pages) RFC7362: Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication (16 pages) RFC7604: Comparison of Different NAT Traversal Techniques for Media Controlled by the Real-Time Streaming Protocol (RTSP) (46 pages) RFC7825: A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP) (33 pages) RFC7826: Real-Time Streaming Protocol Version 2.0 (318 pages) RFC7850: Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles (7 pages) RFC8122: Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) (18 pages) Media OPerationS (mops) ----------------------- Charter Last Modified: 2020-04-21 Current Status: Active Chairs: Kyle Rose Leslie Daigle Operations and Management Area Directors: Warren Kumari Robert Wilton 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: Feb 2020 - Draft of edge network operational considerations for streaming media Feb 2020 - Initial draft operational considerations for low latency streaming video applications Mar 2020 - Draft documenting Streaming Video Alliance (SVA) reliance on IETF protocols Mar 2020 - Draft documenting Society of Motion Picture and Television Engineers (SMPTE) protocol reliance on IETF protocols Jul 2020 - Last-call document on Streaming Video Alliance (SVA) reliance on IETF protocols (including explicit outreach to SVA) Jul 2020 - Last-call document on Society of Motion Picture and Television Engineers (SMPTE) protocol reliance on IETF protocols (including explicit outreach to SMPTE) Jul 2020 - Revised draft of edge network operational considerations for streaming media Jul 2020 - Revised draft operational considerations for low latency streaming video applications Nov 2020 - Last-call document on edge network considerations for streaming media Nov 2020 - Last-call document on operational considerations for low latency streaming video applications Nov 2020 - Develop work items specific to media acquisition and delivery Nov 2021 - IESG to decide whether continue, re-charter or close MOPS WG Internet-Drafts: - Operational Considerations for Streaming Media [draft-ietf-mops-streaming-opcons-01] (11 pages) No Requests for Comments Multiprotocol Label Switching (mpls) ------------------------------------ Charter Last Modified: 2019-05-24 Current Status: Active Chairs: Loa Andersson Nicolai Leymann Tarek Saad Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Deborah Brungard Tech Advisor: George Swallow 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: Mar 2015 - Submit draft-ietf-mpls-tp-oam-id-mib for publication May 2015 - Submit draft-ietf-mpls-lsp-ping-relay-reply for publication May 2015 - Submit draft-ietf-mpls-mldp-node-protection for publication May 2015 - Submit draft-ietf-mpls-rfc6374-udp-return-path for publicatiion May 2015 - ++ Progress draft-ietf-mpls-seamless-mcast to publication May 2015 - ++ Progress draft-ietf-mpls-ldp-ipv6 for publication to publication May 2015 - ++ Progress draft-ietf-mpls-ldp-ip-pw-capability to publication Jun 2015 - Submit draft-ietf-mpls-seamless-mpls for publication Jun 2015 - Submit draft-ietf-mpls-lsp-ping-reply-mode-simple for publication Jun 2015 - Submit draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf for publication Jun 2015 - Submit draft-ietf-mpls-entropy-lsp-ping for publication Jun 2015 - ++ Progress draft-ietf-mpls-proxy-lsp-ping to publication Jun 2015 - ++ Progress draft-ietf-mpls-oam-ipv6-rao to publication Jun 2015 - ++ Progress draft-ietf-mpls-in-udp to publication Jul 2015 - Submit draft-ietf-mpls-te-express-path Aug 2015 - Submit draft-ietf-mpls-tp-temporal-hitless-psm for publication Aug 2015 - Submit draft-ietf-mpls-tp-linear-protection-mib Aug 2015 - Submit draft-ietf-mpls-ldp-mrt for publication Aug 2015 - Submit draft-ietf-mpls-lsp-ping-lag-multipath 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 - Submit Definitions of Managed Objects for MultoiProtocol Label Switching, Label Distribution Protocol (LDP) to the IESG for publication as Proposed Standards Done - Specification for MPLS-specific recovery ready for advancement. Done - Submit Multiprotocol Label Switching (MPLS) Forward Equivalency Class-To-Next Hop Label Forwarding Entry Management Information Base to the IESG for publication as Proposed Standards Done - Submit Multiprotocol Label Switching (MPLS) Label Switching Router (LSR), Management Information Base to the IESG for publication as Proposed Standards Done - Submit Multiprotocol Label Switching (MPLS) Management Overview to the IESG for publication as Proposed Standards Done - Submit Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management to the IESG for publication as Proposed Standards Done - Submit Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base to the IESG for publication as Proposed Standards Done - Submit the Traffic Engineering Link MIB to the IESG for as a Proposed Standard Done - Submit a specification on Encapsulations to carry MPLS over IP and GRE to the IESG for as a Proposed Standard Done - Submit specification on LSP Ping to the IESG for publication as a Proposed Standard Done - Submit a document defining the scope, requirements, and issues to resolve for setup of P2MP TE LSPs (MPLS and GMPLS) Done - Submit an OAM Framework Document to the IESG for publication as an Informational RFC Done - Submit a BCP on MPLS load sharing to the IESG Done - Submit specification on LSR Self Test to the IESG for publication as a Proposed Standard Done - Submit document(s) specifying protocol extensions, enhancements and mechanisms for setup of P2MP TE LSPs Done - Submit point to multipoint TE MIB to IESG as proposed standard Done - Submit EXP field clarification document to IESG as proposed standard Done - Submit a specification on Soft Pre-emption of LSP Tunnels to the IESG for publication as a Proposed Standard Done - Submit LDP extensions for P2MP LSPs Done - Submit MPLS security framework for publication as an informational RFC Done - Submit requirements for point-to-multipoint extensions to LDP Done - Submit draft-ietf-mpls-ldp-gtsm for publication Done - Submit draft-ietf-mpls-tp-itu-t-identifiers for publication Done - Submit draft-ietf-mpls-entropy-label 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-mldp-in-band-signaling for publication Done - Submit draft-ietf-mpls-tp-ethernet-addressing for publication Done - Submit draft-ietf-mpls-tp-ring-protection for publication Done - Submit draft-ietf-mpls-tp-use-cases-and-design for publication Done - Submit draft-ietf-mpls-gach-adv for publication Done - Submit draft-ietf-mpls-retire-ach-tlv 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-ldp-dod 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-ldp-hello-crypto-auth for publication Done - Submit draft-ietf-mpls-extended-admin-group for publication Done - Submit draft-ietf-mpls-forwardig 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-smp-requirements for publication Done - Submit draft-ietf-mpls-deprecate-bgp-entropy-label 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-ldp-ipv6 for publication Done - Submit draft-ietf-mpls-seamless-mcast for publication Done - Submit draft-ietf-mpls-ldp-ip-pw-capability for publication Done - Submit draft-ietf-mpls-in-udp for publication Done - Submit draft-ietf-mpls-proxy-lsp-ping fpr 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-registry for publication Done - Submit draft-ietf-mpls-oam-ipv6-rao for publication 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) - 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) - 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-06] (13 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) - 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) - MPLS-TP Shared-Ring protection (MSRP) mechanism for ring topology [draft-cheng-mpls-tp-shared-ring-protection-06] (46 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) - Performance Measurement for Segment Routing Networks with MPLS Data Plane [draft-gandhi-mpls-rfc6374-sr-02] (18 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-06] (15 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-14] (19 pages) - Bidirectional Forwarding Detection (BFD) Directed Return Path [draft-ietf-mpls-bfd-directed-13] (9 pages) - Graceful Restart Mechanism for BGP with MPLS [draft-ietf-mpls-bgp-mpls-restart-05] (10 pages) - Carrying Label Information in BGP-4 [draft-ietf-mpls-bgp4-mpls-05] (8 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) - Extensions to RSVP-TE and CR-LDP for support of Diff-Serv-aware MPLS Traffic Engineering [draft-ietf-mpls-diff-te-ext-01] (12 pages) - Requirements for support of Diff-Serv-aware MPLS Traffic Engineering [draft-ietf-mpls-diff-te-reqts-00] (13 pages) - Avoiding Equal Cost Multipath Treatment in MPLS Networks [draft-ietf-mpls-ecmp-bcp-03] (8 pages) - A Proposal to Incorporate ECN in MPLS [draft-ietf-mpls-ecn-00] (9 pages) - MPLS Egress Protection Framework [draft-ietf-mpls-egress-protection-framework-07] (25 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) - A Framework for MPLS [draft-ietf-mpls-framework-05] (69 pages) - Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB) [draft-ietf-mpls-ftn-mib-09] (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) - MPLS/IP Header Compression [draft-ietf-mpls-hdr-comp-00] (14 pages) - MPLS/IP Header Compression over PPP [draft-ietf-mpls-hdr-comp-over-ppp-00] (10 pages) - Codepoint Registry for the Flags Field in the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Session Attribute Object [draft-ietf-mpls-iana-rsvp-session-flags-01] (5 pages) - ICMP Extensions for Multiprotocol Label Switching [draft-ietf-mpls-icmp-08] (8 pages) - LDP IGP Synchronization [draft-ietf-mpls-igp-sync-01] (8 pages) - Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) [draft-ietf-mpls-in-ip-or-gre-08] (14 pages) - Encapsulating MPLS in UDP [draft-ietf-mpls-in-udp-11] (19 pages) - Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment [draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp-01] (17 pages) - Detecting MPLS Data Plane Failures in Inter-AS and inter-provider Scenarios [draft-ietf-mpls-interas-lspping-00] (18 pages) - Label Edge Router Forwarding of IPv4 Option Packets [draft-ietf-mpls-ip-options-07] (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) - LDP DoD Graceful Restart [draft-ietf-mpls-ldp-dod-restart-00] (18 pages) - Signaling LDP Label Advertisement Completion [draft-ietf-mpls-ldp-end-of-lib-04] (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) - LDP Extensions for Optical User Network Interface (O-UNI) Signaling [draft-ietf-mpls-ldp-optical-uni-01] (26 pages) - Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths [draft-ietf-mpls-ldp-p2mp-15] (39 pages) - Graceful Restart Mechanism for Label Distribution Protocol [draft-ietf-mpls-ldp-restart-06] (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] (93 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) - OSPFv3 CodePoint for MPLS LSP Ping [draft-ietf-mpls-lsp-ping-ospfv3-codepoint-02] (6 pages) - Updating the IANA MPLS LSP Ping Parameters [draft-ietf-mpls-lsp-ping-registries-update-02] (13 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) - Connectivity Verification for Multicast Label Switched Paths [draft-ietf-mpls-mcast-cv-00] (13 pages) - Multiprotocol Label Switching (MPLS) Management Overview [draft-ietf-mpls-mgmt-overview-09] (32 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) - Definitions of Managed Objects for the LDP Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths [draft-ietf-mpls-mldp-mib-05] (40 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-06] (69 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) - 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) - 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) - P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels [draft-ietf-mpls-p2mp-te-bypass-02] (14 pages) - Point-to-Multipoint Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) module [draft-ietf-mpls-p2mp-te-mib-09] (62 pages) - 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-05] (20 pages) - UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks [draft-ietf-mpls-rfc6374-udp-return-path-05] (10 pages) - Clarification of Segment ID Sub-TLV Length for RFC 8287 [draft-ietf-mpls-rfc8287-len-clarification-04] (7 pages) - Refresh-interval Independent FRR Facility Protection [draft-ietf-mpls-ri-rsvp-frr-07] (25 pages) - Resilient MPLS Rings [draft-ietf-mpls-rmr-12] (15 pages) - Resilient MPLS Rings and Multicast [draft-ietf-mpls-rmr-multicast-00] (7 pages) - Use of Label Switching With RSVP [draft-ietf-mpls-rsvp-00] (13 pages) - Fast Reroute Extensions to RSVP-TE for LSP Tunnels [draft-ietf-mpls-rsvp-lsp-fastreroute-07] (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) - 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) - MPLS Upstream Label Assignment for RSVP-TE [draft-ietf-mpls-rsvp-upstream-05] (10 pages) - Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) [draft-ietf-mpls-rsvpte-attributes-05] (21 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-06] (10 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-02] (6 pages) - Entropy Label for Source Packet Routing in Networking (SPRING) Tunnels [draft-ietf-mpls-spring-entropy-label-12] (22 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) - 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-11] (18 pages) - RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels [draft-ietf-mpls-summary-frr-rsvpte-09] (21 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) - 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) - Traffic Engineering Link Management Information Base [draft-ietf-mpls-telink-mib-07] (54 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) - Indication of Client Failure in MPLS-TP [draft-ietf-mpls-tp-csf-02] (12 pages) - MPLS Transport Profile Data Plane Architecture [draft-ietf-mpls-tp-data-plane-04] (15 pages) - MPLS 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) - IETF Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) Document Process [draft-ietf-mpls-tp-process-05] (23 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) - 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-07] (11 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) - Management Information Base for MPLS LDP Multi Topology [draft-li-mpls-ldp-mt-mib-06] (29 pages) - Proxy MPLS Echo Request [draft-lim-mpls-proxy-lsp-ping-03] (24 pages) - MPLS Capability set [draft-loa-mpls-cap-set-01] (7 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) - 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-10] (9 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) - 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-00] (17 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) - Targeted LDP Hello Reduction [draft-pdutta-mpls-tldp-hello-reduce-04] (8 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) - Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode [draft-ryoo-mpls-tp-aps-updates-03] (7 pages) - MPLS Transport Profile (MPLS-TP) Linear Protection in Support of ITU-T's Requirements [draft-ryoogray-mpls-tp-psc-itu-01] (31 pages) - A YANG Data Model for MPLS Base [draft-saad-mpls-base-yang-00] (10 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) - 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 Node Protection [draft-wijnands-mpls-mldp-node-protection-04] (16 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: BCP128: Avoiding Equal Cost Multipath Treatment in MPLS Networks (8 pages) 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 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 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 RFC7274 * Updates RFC7214 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 RFC7324 * Updates RFC7271 * Updates RFC7214 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) RFC7307: LDP Extensions for Multi-Topology (20 pages) RFC7308: Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE) (7 pages) RFC7324: Updates to MPLS Transport Profile Linear Protection (11 pages) RFC7325: MPLS Forwarding Compliance and Performance Requirements (59 pages) RFC7349: LDP Hello Cryptographic Authentication (14 pages) RFC7358: Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs) (8 pages) RFC7394: Definition of Time to Live TLV for LSP-Ping Mechanisms (8 pages) RFC7412: Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection (16 pages) RFC7438: Multipoint LDP (mLDP) In-Band Signaling with Wildcards (16 pages) RFC7439: Gap Analysis for Operating IPv6-Only MPLS Networks (28 pages) RFC7442: Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP) (11 pages) RFC7447: Deprecation of BGP Entropy Label Capability Attribute (4 pages) RFC7453: MPLS Transport Profile (MPLS-TP) Traffic Engineering (TE) Management Information Base (MIB) (62 pages) RFC7473: Controlling State Advertisements of Non-negotiated LDP Applications (15 pages) * Updates RFC8223 RFC7506: IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM) (6 pages) RFC7510: Encapsulating MPLS in UDP (19 pages) RFC7524: Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs) (42 pages) * Updates RFC8534 RFC7537: IANA Registries for LSP Ping Code Points (7 pages) * Obsoletes RFC8029 RFC7552: Updates to LDP for IPv6 (24 pages) RFC7555: Proxy MPLS Echo Request (28 pages) RFC7697: MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB) (36 pages) RFC7715: Multipoint LDP (mLDP) Node Protection (19 pages) RFC7737: Label Switched Path (LSP) Ping and Traceroute Reply Mode Simplification (17 pages) RFC7743: Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping (18 pages) RFC7746: Label Switched Path (LSP) Self-Ping (12 pages) RFC7759: Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using Label Switched Path (LSP) Ping (29 pages) RFC7876: UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks (10 pages) RFC8012: Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy Labels (ELs) (23 pages) RFC8029: Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures (78 pages) * Updates RFC8611 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 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) 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) Network Configuration (netconf) ------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Kent Watsen Mahesh Jethanandani Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Robert Wilton 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: Sep 2018 - WGLC for advanced Notification/Subscription Specifications Sep 2018 - WGLC for YANG Push Sep 2018 - WGLC for RESTCONF and HTTP Transport for Event Notifications Sep 2018 - WGLC for NETCONF Support for Event Notifications Sep 2018 - WGLC for YANG Notification Headers and Bundles Dec 2018 - WGLC for System-level Keystore Mechanism Dec 2018 - WGLC for Server and Client Configuration Models for NETCONF and RESTCONF Dec 2018 - WGLC for Client and Server Configuration Models for SSH and TLS Dec 2018 - Submit draft-ietf-netconf-udp-pub-channel to IESG for publication (as Standards Track) Done - WGLC for NMDA NETCONF Done - WGLC for NMDA RESTCONF Done - WGLC for YANG Library bis (as Standards Track) Done - WGLC for Zero-touch Configuration Mechanism Internet-Drafts: - 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) - 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) - Common YANG Data Types for Cryptography [draft-ietf-netconf-crypto-types-14] (65 pages) - YANG Groupings for HTTP Clients and HTTP Servers [draft-ietf-netconf-http-client-server-02] (16 pages) - An HTTPS-based Transport for Configured Subscriptions [draft-ietf-netconf-https-notif-02] (19 pages) - A YANG Data Model for a Keystore [draft-ietf-netconf-keystore-16] (40 pages) - YANG Module for NETCONF Monitoring [draft-ietf-netconf-monitoring-15] (28 pages) - NETCONF Client and Server Models [draft-ietf-netconf-netconf-client-server-18] (98 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 for describing System Capabilities and Yang-Push Notification Capabilities [draft-ietf-netconf-notification-capabilities-13] (26 pages) - Notification Message Headers and Bundles [draft-ietf-netconf-notification-messages-08] (23 pages) - Partial Lock Remote Procedure Call (RPC) for NETCONF [draft-ietf-netconf-partial-lock-11] (23 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-18] (85 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) - 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-18] (54 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) - YANG Groupings for TCP Clients and TCP Servers [draft-ietf-netconf-tcp-client-server-04] (19 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-18] (55 pages) - A YANG Data Model for a Truststore [draft-ietf-netconf-trust-anchors-09] (30 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) - 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) - YANG Library [draft-nmdsdt-netconf-rfc7895bis-01] (23 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) RFC4744: Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) (10 pages) RFC5277: NETCONF Event Notifications (35 pages) RFC5539: NETCONF over Transport Layer Security (TLS) (7 pages) * Obsoletes RFC7589 RFC5717: Partial Lock Remote Procedure Call (RPC) for NETCONF (23 pages) RFC6022: YANG Module for NETCONF Monitoring (28 pages) RFC6241: Network Configuration Protocol (NETCONF) (113 pages) * Updates RFC7803 * Updates RFC8526 RFC6242: Using the NETCONF Protocol over Secure Shell (SSH) (11 pages) RFC6243: With-defaults Capability for NETCONF (26 pages) RFC6470: Network Configuration Protocol (NETCONF) Base Notifications (15 pages) RFC6536: Network Configuration Protocol (NETCONF) Access Control Model (49 pages) * Obsoletes RFC8341 RFC7589: Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication (11 pages) RFC7895: YANG Module Library (13 pages) * Obsoletes RFC8525 RFC8040: RESTCONF Protocol (137 pages) * Updates RFC8527 RFC8071: NETCONF Call Home and RESTCONF Call Home (13 pages) RFC8072: YANG Patch Media Type (39 pages) RFC8341: Network Configuration Access Control Model (58 pages) RFC8525: YANG Library (32 pages) RFC8526: NETCONF Extensions to Support the Network Management Datastore Architecture (23 pages) RFC8527: RESTCONF Extensions to Support the Network Management Datastore Architecture (9 pages) RFC8572: Secure Zero Touch Provisioning (SZTP) (87 pages) RFC8639: Subscription to YANG Notifications (77 pages) RFC8640: Dynamic Subscription to YANG Events and Datastores over NETCONF (19 pages) RFC8641: Subscription to YANG Notifications for Datastore Updates (58 pages) RFC8650: Dynamic Subscription to YANG Events and Datastores over RESTCONF (23 pages) STD91: Network Configuration Access Control Model (58 pages) Network Modeling (netmod) ------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Joel Jaeggli Kent Watsen Lou Berger Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Robert Wilton 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: May 2017 - Submit draft-ietf-netmod-yang-model-classification to IESG for publication (as Informational) May 2017 - Submit draft-ietf-netmod-syslog-model to IESG for publication (as Standards Track) Jul 2017 - Submit draft-ietf-netmod-rfc6087bis to IESG for publication (as Informational) Nov 2017 - Submit draft-ietf-netmod-revised-datastores to IESG for publication (as Standards Track) Dec 2017 - Submit draft-ietf-netmod-schema-mount to IESG for publication (as Standards Track) Dec 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for publication (as Standards Track) Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to IESG for publication (as Informational) Jan 2018 - Submit draft-ietf-netmod-entity to IESG for publication (as Standards Track) Jan 2018 - Submit draft-ietf-netmod-acl-model to IESG for publication (as Standards Track) 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) - 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 Inclusions in Internet-Drafts and RFCs [draft-ietf-netmod-artwork-folding-12] (30 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 Hardware Management [draft-ietf-netmod-entity-08] (60 pages) - A YANG Data Model for Factory Default Settings [draft-ietf-netmod-factory-default-15] (13 pages) - A YANG Grouping for Geographic Locations [draft-ietf-netmod-geo-location-04] (23 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) - 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-08] (32 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] (18 pages) - Comparison of NMDA datastores [draft-ietf-netmod-nmda-diff-03] (17 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-02] (48 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) - A YANG Data Model for Routing Management [draft-ietf-netmod-routing-cfg-25] (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-06] (32 pages) - A YANG Data Model for Syslog Configuration [draft-ietf-netmod-syslog-model-26] (31 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) - YANG Instance Data File Format [draft-ietf-netmod-yang-instance-file-format-12] (28 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) - Updated YANG Module Revision Handling [draft-ietf-netmod-yang-module-versioning-00] (34 pages) - YANG Packages [draft-ietf-netmod-yang-packages-00] (56 pages) - YANG Schema Comparison [draft-ietf-netmod-yang-schema-comparison-00] (13 pages) - YANG Semantic Versioning [draft-ietf-netmod-yang-semver-00] (15 pages) - YANG Versioning Solution Overview [draft-ietf-netmod-yang-solutions-00] (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-02] (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) - 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) - Sub-interface VLAN YANG Data Models [draft-wilton-netmod-intf-vlan-yang-04] (27 pages) Requests for Comments: BCP215: YANG Tree Diagrams (13 pages) BCP216: Guidelines for Authors and Reviewers of Documents Containing YANG Data Models (63 pages) 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) 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) RFC8519: YANG Data Model for Network Access Control Lists (ACLs) (60 pages) RFC8528: YANG Schema Mount (28 pages) Network File System Version 4 (nfsv4) ------------------------------------- Charter Last Modified: 2019-11-21 Current Status: Active Chairs: Brian Pawlowski David Noveck Transport Area Directors: Martin Duke Magnus Westerlund Transport Area Advisor: Magnus Westerlund 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 the 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. 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. Goals and Milestones: Aug 2020 - Submit final document describing use of NVMe in accessing a pNFS SCSI Layout (as Proposed Standard) Dec 2020 - Submit final document defining RPC-over-RDMA Version 2 (as Proposed Standard) Done - WGLC for draft-ietf-nfsv4-migration-issues (Informational) Done - Submit final document describing NFSv4.0 trunking discovery (as Proposed Standard) Done - Submit final document describing NFSv4.1 trunking discovery (as Proposed Standard) Done - Submit final document describing Transparent State Migration in NFSv4.1 (as Proposed Standard) Done - Submit final document describing CM private data convention for RPC-over-RDMA version 1 (as Proposed Standard) Done - Submit final document defining TLS use for RPC / NFS Internet-Drafts: - 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-00] (15 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) - 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) - 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) - Requirements for NFSv4.2 [draft-ietf-nfsv4-minorversion-2-requirements-00] (10 pages) - Network File System (NFS) Version 4 Minor Version 1 Protocol [draft-ietf-nfsv4-minorversion1-29] (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 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) Remote Direct Memory Access (RDMA) Problem Statement [draft-ietf-nfsv4-nfs-rdma-problem-statement-08] (15 pages) - Network File System (NFS) Upper-Layer Binding To RPC-Over-RDMA Version 2 [draft-ietf-nfsv4-nfs-ulb-v2-01] (16 pages) - Network File System (NFS) Direct Data Placement [draft-ietf-nfsv4-nfsdirect-08] (10 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) - 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) - NFSv4.0 Migration: Specification Update [draft-ietf-nfsv4-rfc3530-migration-update-08] (55 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) - 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] (662 pages) - Object-Based Parallel NFS (pNFS) Operations [draft-ietf-nfsv4-rfc5664bis-03] (38 pages) - RPC-over-RDMA Version One Implementation Experience [draft-ietf-nfsv4-rfc5666-implementation-experience-03] (50 pages) - Remote Direct Memory Access Transport for Remote Procedure Call Version 1 [draft-ietf-nfsv4-rfc5666bis-11] (55 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) - Towards Remote Procedure Call Encryption By Default [draft-ietf-nfsv4-rpc-tls-07] (23 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) - RDMA Connection Manager Private Data For RPC-Over-RDMA Version 1 [draft-ietf-nfsv4-rpcrdma-cm-pvt-data-08] (13 pages) - RPC-over-RDMA Version 2 Protocol [draft-ietf-nfsv4-rpcrdma-version-two-01] (83 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) - Parallel NFS (pNFS) Small Computer System Interface (SCSI) Layout [draft-ietf-nfsv4-scsi-layout-10] (30 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) 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 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) 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) STD67: XDR: External Data Representation Standard (27 pages) Network Time Protocol (ntp) --------------------------- Charter Last Modified: 2020-03-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: The Network Time Protocol (NTP) is widely deployed and used in the Internet. However, the standardization status of this protocol has lagged in the IETF. RFC 1305 (NTP version 3) was published in March 1992 and remains unchanged and at Draft Standard status. RFC 1305 represents the majority of full NTP implementations deployed today. RFC 2030 (SNTP version 4) was published as an Informational RFC in October 1996 as a lightweight version of NTP for deployments not requiring the full functionality of NTP. SNTP now represents the majority of both NTP traffic and NTP implementation issues on the Internet. A good deal of work has been produced in the NTP community updating both NTPv3 and SNTPv4. This work is ongoing and available through the collaborative development effort in the NTP community, but it has not been reflected back into the NTP specifications. The goal of this working group is to document NTPv4 based on the extensive work of the NTP community and to advance the standardization status of NTP. It is an explicit goal of this effort to have NTPv4 interoperate with the deployed base avoiding any backwards-incompatible changes. A number of topics have been raised as potential work items for an update to NTP including support for IPv6, security considerations including authentication, automatic configuration including possible requirements for DHCP, and algorithm improvements. This working group will focus first on delivering NTPv4 and will defer additional development efforts until after the delivery of NTPv4. Support for IPv6 and defining mechanisms for securing NTP transactions is considered part of the core NTPv4 functionality. Potential further modifications and additions to the NTP protocol will be documented for possible further work beyond the initial NTPv4 effort. The working group will initially focus on the following deliverables: 1. NTPv4 Scope and Requirements Document (documenting the scope of the NTPv4 update and identifying issues deferred for future work). 2. NTPv4 Protocol Specification (documenting the protocol on the wire) 3. NTPv4 Architecture and Algorithms Specification (documenting the architecture, mathematical algorithms, and behavior of NTP servers and clients) 4. NTPv4 MIB (provision for management and monitoring of NTP via SNMP) Goals and Milestones: Feb 2016 - WGLC for Network Time Security Feb 2016 - WGLC for Using the Network Time Security Specification to Secure the Network Time Protocol Feb 2016 - WGLC Protecting Network Time Security Messages with the Cryptographic Message Syntax (CMS) Apr 2016 - Publish UDP Checksum Complement in the Network Time Protocol (NTP) Apr 2016 - Publish The Network Time Protocol Version 4 (NTPv4) Extension Fields Apr 2016 - WGLC Network Time Protocol Best Current Practices Done - NTP BOF at IETF 61 Done - NTP WG Charter Approved Done - Draft of Scope and Requirements Document Done - Draft of NTP Protocol Specification Done - Draft of MIB Specification Done - Draft of NTP Algorithms Specification Done - Draft of NTP Autokey Specification - Informational RFC Done - WG Last Call NTP Protocol Specification Done - WG Last Call NTP MIB Specification Done - Draft of NTP Control Protocol - Informational RFC Done - WG Last Call NTP Autokey Specification - Informational RFC Done - WG Last Call NTP Control Protocol - Informational RFC Internet-Drafts: - On Implementing Time [draft-aanchal-time-implementation-guidance-02] (9 pages) - Message Authentication Codes for the Network Time Protocol [draft-aanchal4-ntp-mac-03] (12 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) - Port Randomization in the Network Time Protocol Version 4 [draft-gont-ntp-port-randomization-04] (10 pages) - Control Messages Protocol for Use with Network Time Protocol Version 4 [draft-haberman-ntpwg-mode-6-cmds-02] (15 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 Version 4 [draft-ietf-ntp-chronos-00] (11 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-03] (12 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-07] (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) - Guidelines for Defining Packet Timestamps [draft-ietf-ntp-packet-timestamps-09] (20 pages) - Port Randomization in the Network Time Protocol Version 4 [draft-ietf-ntp-port-randomization-02] (10 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-01] (20 pages) - Network Time Security for the Network Time Protocol [draft-ietf-ntp-using-nts-for-ntp-28] (44 pages) - A YANG Data Model for NTP [draft-ietf-ntp-yang-data-model-08] (54 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) - 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 Best Current Practices [draft-reilly-ntp-bcp-02] (18 pages) - Roughtime [draft-roughtime-aanchal-04] (17 pages) - A Secure Selection and Filtering Mechanism for the Network Time Protocol Version 4 [draft-schiff-ntp-chronos-03] (8 pages) - Network Time Protocol Extended Information Extension Field [draft-stenn-ntp-extended-information-04] (5 pages) - Network Time Protocol Version 4 (NTPv4) Extension Fields [draft-stenn-ntp-extension-fields-09] (13 pages) - Network Time Protocol I-Do Extension Field [draft-stenn-ntp-i-do-06] (7 pages) - Network Time Protocol IPv6 REFID Hash [draft-stenn-ntp-ipv6-refid-hash-00] (4 pages) - Network Time Protocol Last Extension Field [draft-stenn-ntp-last-extension-00] (4 pages) - Network Time Protocol Leap Smear REFID [draft-stenn-ntp-leap-smear-refid-02] (5 pages) - Network Time Protocol MAC/Last Extension Fields [draft-stenn-ntp-mac-last-ef-04] (8 pages) - Network Time Protocol Suggested REFID Extension Field [draft-stenn-ntp-suggest-refid-05] (7 pages) Requests for Comments: BCP223: Network Time Protocol Best Current Practices (26 pages) RFC5905: Network Time Protocol Version 4: Protocol and Algorithms Specification (110 pages) * Updates RFC7822 * Updates RFC8573 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) Network Virtualization Overlays (nvo3) -------------------------------------- Charter Last Modified: 2018-05-21 Current Status: Active Chairs: Matthew Bocci Sam Aldrin Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Martin Vigoureux Tech Advisor: Ron Bonica Secretary: Li Yizhou 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 Solutions Submitted to IESG Mar 2020 - Security Requirements 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 - Architecture submitted for IESG review Done - Use Cases 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) - NVO3 Data Plane Requirements [draft-ietf-nvo3-dataplane-requirements-03] (18 pages) - NVO3 Encapsulation Considerations [draft-ietf-nvo3-encap-05] (19 pages) - Applicability of EVPN to NVO3 Networks [draft-ietf-nvo3-evpn-applicability-02] (26 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] (37 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) - Network-related VM Mobility Issues [draft-ietf-nvo3-vm-mobility-issues-03] (11 pages) - Virtual Machine Mobility Solutions for L2 and L3 Overlay Networks [draft-ietf-nvo3-vmm-14] (17 pages) - Generic Protocol Extension for VXLAN [draft-ietf-nvo3-vxlan-gpe-09] (22 pages) - Base YANG Data Model for NVO3 Protocols [draft-ietf-nvo3-yang-cfg-02] (27 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) Web Authorization Protocol (oauth) ---------------------------------- Charter Last Modified: 2019-03-30 Current Status: Active Chairs: Hannes Tschofenig Rifaat Shekh-Yusef Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Roman Danyliw 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: Apr 2017 - Submit 'OAuth 2.0 Device Flow' to the IESG May 2017 - Submit 'OAuth 2.0 Token Exchange' to the IESG for consideration as a Proposed Standard Jul 2017 - Submit 'OAuth 2.0 Mix-Up Mitigation'to the IESG Jul 2017 - Submit 'OAuth 2.0 Security: Closing Open Redirectors in OAuth' to the IESG Jul 2017 - Submit 'OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution' to the IESG Jul 2017 - Submit 'A Method for Signing HTTP Requests for OAuth' to IESG Done - Submit 'OAuth 2.0 Proof-of-Possession (PoP) Security Architecture' to the IESG Done - Submit 'Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)' 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 Internet-Drafts: - JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens [draft-ietf-oauth-access-token-jwt-07] (19 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) - The OAuth Protocol: Authentication [draft-ietf-oauth-authentication-01] (21 pages) - OAuth 2.0 for Browser-Based Apps [draft-ietf-oauth-browser-based-apps-06] (21 pages) - OAuth 2.0 Security: Closing Open Redirectors in OAuth [draft-ietf-oauth-closing-redirectors-00] (7 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 Demonstration of Proof-of-Possession at the Application Layer (DPoP) [draft-ietf-oauth-dpop-01] (22 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 Incremental Authorization [draft-ietf-oauth-incremental-authz-04] (11 pages) - OAuth 2.0 Token Introspection [draft-ietf-oauth-introspection-11] (17 pages) - JSON Web Token (JWT) [draft-ietf-oauth-json-web-token-32] (30 pages) - The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR) [draft-ietf-oauth-jwsreq-23] (32 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-09] (18 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-01] (14 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-01] (30 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 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) - OAuth 2.0 Security Best Current Practice [draft-ietf-oauth-security-topics-15] (46 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) - 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) - 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.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: BCP212: OAuth 2.0 for Native Apps (21 pages) BCP225: JSON Web Token Best Current Practices (13 pages) RFC6749: The OAuth 2.0 Authorization Framework (76 pages) * Updates RFC8252 RFC6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage (18 pages) 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) Operations and Management Area Working Group (opsawg) ----------------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Joe Clarke Tianran Zhou Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Robert Wilton 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 - Initial submission for the 'Guidelines for Considering Operations and Management of New Protocols' Internet-Draft Done - Initial submission for the 'Template for Generic Management Data Models' Internet-Draft Done - Initial submission for the 'Structured Data Elements (SDEs) for syslog' Internet-Draft Done - WGLC for the 'SNMP Engine ID Discovery' Internet-Draft Done - Submit the 'SNMP Engine ID Discovery' Internet-Draft to the IESG for consideration as Proposed Standard Done - WGLC for the 'Guidelines for Considering Operations and Management of New Protocols' Internet-Draft Done - Submit the 'Guidelines for Considering Operations and Management of New Protocols' Internet-Draft to the IESG for consideration as BCP 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) - 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) - 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) - 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) - Export of BGP Community Information in IP Flow Information Export (IPFIX) [draft-ietf-opsawg-ipfix-bgp-community-12] (18 pages) - A Layer 3 VPN Network YANG Model [draft-ietf-opsawg-l3sm-l3nm-03] (123 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-02] (35 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) - 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-03] (34 pages) - An Overview of Operations, Administration, and Maintenance (OAM) Tools [draft-ietf-opsawg-oam-overview-16] (53 pages) - Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions [draft-ietf-opsawg-operations-and-management-09] (35 pages) - Ethernet in the First Mile Copper (EFMCu) Interfaces MIB [draft-ietf-opsawg-rfc5066bis-07] (6 pages) - Secure Device Install [draft-ietf-opsawg-sdi-10] (18 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 TACACS+ Protocol [draft-ietf-opsawg-tacacs-18] (46 pages) - Yang data model for TACACS+ [draft-ietf-opsawg-tacacs-yang-04] (15 pages) - Management Information Base for Virtual Machines Controlled by a Hypervisor [draft-ietf-opsawg-vmm-mib-04] (52 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) Requests for Comments: BCP161: Guidelines for the Use of the "OAM" Acronym in the IETF (9 pages) 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) STD78: Simple Network Management Protocol (SNMP) Context EngineID Discovery (9 pages) Operational Security Capabilities for IP Network Infrastructure (opsec) ----------------------------------------------------------------------- Charter Last Modified: 2019-04-05 Current Status: Active Chairs: Jen Linkova Ron Bonica Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Warren Kumari Mailing Lists: General Discussion: opsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/opsec Archive: https://mailarchive.ietf.org/arch/browse/opsec/ Description of Working Group: Goals: The OPSEC WG will document operational issues and best current practices with regard to network security. In particular, the working group will clarify the rationale of supporting current operational practice, addressing gaps in currently understood best practices and clarifying liabilities inherent in security practices where they exist. Scope: The scope of the OPSEC WG includes the protection and secure operation of the forwarding, control and management planes. Documentation of operational issues, revision of existing operational security practices documents and proposals for new approaches to operational challenges related to network security are in scope. Method: The work will result in the publication of informational or BCP RFCs. Taxonomy or problem statement documents may provide a basis for such documents. Informational or Best Current Practices Documents For each topic addressed, the working group will produce a document that captures common practices related to secure network operation. This will be primarily based on operational experience. A document might convey: * a threat or threats to be addressed * current practices for addressing the threat * protocols, tools and technologies extant at the time of writing that are used to address the threat * the possibility that a solution does not exist within existing tools or technologies Taxonomy and Problem Statement Documents These are documents that describe the scope of particular operational security challenges or problem spaces without necessarily coming to conclusions or proposing solutions. Such a document might be the precursor to an informational or best current practices document. While the principal input of the working group is operational experience and needs, the output should be directed towards providing guidance to the operators community, other working groups that develop protocols or the protocol development community. Non-Goals: The OPSEC WG is will not write or modify protocols. New protocol work must be addressed through a working group chartered for that work, or via one of the individual submission processes. The OPSEC WG may take on documents related to the practices of using such work. Goals and Milestones: Dec 2012 - WG Adoption of 'Virtual Private Network (VPN) traffic leakages in dual-stack hosts/networks' document Dec 2012 - WG Adoption of 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers' document Dec 2012 - WG Adoption of 'Network Reconnaissance in IPv6 Networks' document Dec 2012 - WG Adoption of 'BGP operations and security' document Jan 2013 - WG Last Call for 'Operational Security Considerations for IPv6 Networks' document Jan 2013 - WG Last Call for 'Recommendations for filtering ICMP messages' document Jan 2013 - WG Last Call for 'Recommendations on filtering of IPv4 packets containing IPv4 options' document Jan 2013 - WG Last Call for 'Security Implications of IPv6 on IPv4 networks' document Mar 2013 - WG Last Call for 'Using Only Link-Local Addressing Inside an IPv6 Network' document Mar 2013 - Submit 'Recommendations for filtering ICMP messages' document to IESG Mar 2013 - Submit 'Recommendations on filtering of IPv4 packets containing IPv4 options' document to IESG Mar 2013 - Submit 'Operational Security Considerations for IPv6 Networks' document to IESG Mar 2013 - Submit 'Recommendations for filtering ICMP messages' document to IESG May 2013 - Submit 'Using Only Link-Local Addressing Inside an IPv6 Network' document to IESG Jul 2013 - WG Last Call for 'BGP operations and security' document Jul 2013 - WG Last Call for 'Network Reconnaissance in IPv6 Networks' document Jul 2013 - WG Last Call for 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers' document Jul 2013 - WG Last Call for 'Virtual Private Network (VPN) traffic leakages in dual-stack hosts/networks' document Sep 2013 - Submit 'BGP operations and security' document to IESG Sep 2013 - Submit 'Network Reconnaissance in IPv6 Networks' document to IESG Sep 2013 - Submit 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers' document to IESG Done - Complete Charter Done - First draft of Framework Document as Internet Draft Done - First draft of Standards Survey Document as Internet Draft Done - First draft of Packet Filtering Capabilities Done - First draft of Event Logging Capabilities Done - First draft of Network Operator Current Security Practices Done - First draft of In-Band management capabilities Done - First draft of Out-of-Band management capabilities Done - First draft of Configuration and Management Interface Capabilities Done - Submit Network Operator Current Security Practices to IESG Internet-Drafts: - BGP Operations and Security [draft-ietf-opsec-bgp-security-07] (26 pages) - Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF) [draft-ietf-opsec-blackhole-urpf-04] (15 pages) - Operational Security Current Practices in Internet Service Provider Environments [draft-ietf-opsec-current-practices-07] (37 pages) - DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers [draft-ietf-opsec-dhcpv6-shield-08] (12 pages) - Security Best Practices Efforts and Documents [draft-ietf-opsec-efforts-20] (41 pages) - Filtering and Rate Limiting Capabilities for IP Network Infrastructure [draft-ietf-opsec-filter-caps-09] (30 pages) - Framework for Operational Security Capabilities for IP Network Infrastructure [draft-ietf-opsec-framework-05] (29 pages) - Recommendations for filtering ICMP messages [draft-ietf-opsec-icmp-filtering-04] (58 pages) - Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols [draft-ietf-opsec-igp-crypto-requirements-04] (11 pages) - Service Provider Infrastructure Security [draft-ietf-opsec-infrastructure-security-01] (17 pages) - Recommendations on Filtering of IPv4 Packets Containing IPv4 Options [draft-ietf-opsec-ip-options-filtering-07] (36 pages) - Security Assessment of the Internet Protocol Version 4 [draft-ietf-opsec-ip-security-07] (75 pages) - Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers [draft-ietf-opsec-ipv6-eh-filtering-06] (36 pages) - Network Reconnaissance in IPv6 Networks [draft-ietf-opsec-ipv6-host-scanning-08] (38 pages) - Security Implications of IPv6 on IPv4 Networks [draft-ietf-opsec-ipv6-implications-on-ipv4-nets-07] (19 pages) - Security Assessment of Neighbor Discovery (ND) for IPv6 [draft-ietf-opsec-ipv6-nd-security-00] (62 pages) - Using Only Link-Local Addressing inside an IPv6 Network [draft-ietf-opsec-lla-only-11] (10 pages) - Logging Capabilities for IP Network Infrastructure [draft-ietf-opsec-logging-caps-04] (35 pages) - Miscellaneous Capabilities for IP Network Infrastructure [draft-ietf-opsec-misc-cap-00] (21 pages) - Network Management Access Security Capabilities [draft-ietf-opsec-nmasc-00] (13 pages) - Protecting the Router Control Plane [draft-ietf-opsec-protect-control-plane-06] (25 pages) - Routing Control Plane Security Capabilities [draft-ietf-opsec-routing-capabilities-03] (20 pages) - Issues with Existing Cryptographic Protection Methods for Routing Protocols [draft-ietf-opsec-routing-protocols-crypto-issues-07] (21 pages) - Enhanced Feasible-Path Unicast Reverse Path Forwarding [draft-ietf-opsec-urpf-improvements-04] (17 pages) - Operational Security Considerations for IPv6 Networks [draft-ietf-opsec-v6-21] (52 pages) - Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks [draft-ietf-opsec-vpn-leakages-06] (12 pages) - Enhanced Feasible-Path Unicast Reverse Path Filtering [draft-sriram-opsec-urpf-improvements-03] (15 pages) Requests for Comments: BCP186: Recommendations on Filtering of IPv4 Packets Containing IPv4 Options (36 pages) BCP194: BGP Operations and Security (26 pages) BCP199: DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers (12 pages) RFC4778: Operational Security Current Practices in Internet Service Provider Environments (37 pages) RFC5635: Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF) (15 pages) RFC6039: Issues with Existing Cryptographic Protection Methods for Routing Protocols (21 pages) RFC6094: Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols (11 pages) RFC6192: Protecting the Router Control Plane (25 pages) RFC6274: Security Assessment of the Internet Protocol Version 4 (75 pages) RFC7123: Security Implications of IPv6 on IPv4 Networks (19 pages) RFC7126: Recommendations on Filtering of IPv4 Packets Containing IPv4 Options (36 pages) RFC7359: Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks (12 pages) RFC7404: Using Only Link-Local Addressing inside an IPv6 Network (10 pages) RFC7454: BGP Operations and Security (26 pages) RFC7610: DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers (12 pages) RFC7707: Network Reconnaissance in IPv6 Networks (38 pages) RFC8704: Enhanced Feasible-Path Unicast Reverse Path Forwarding (17 pages) Pseudowire And LDP-enabled Services (pals) ------------------------------------------ Charter Last Modified: 2018-05-11 Current Status: Active Chairs: Andrew G. Malis Stewart Bryant Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Deborah Brungard 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: Jun 2016 - Submit LDP-VPLS for Ethernet Broadcast and Multicast to the IESG Jun 2017 - Submit L2VPN applicability statement for data center applications to the IESG Done - Submit PW Congestion Considerations to the IESG Done - Submit STP Application of ICCP to the IESG Done - Submit Pseudowire Redundancy on S-PE to the IESG Done - Submit Unified Control Channel for PWs 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 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 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) - 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) 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) STD84: Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) (35 pages) Path Computation Element (pce) ------------------------------ Charter Last Modified: 2019-09-11 Current Status: Active Chairs: Dhruv Dhody Julien Meuric Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Deborah Brungard Secretary: Hariharan Ananthakrishnan Mailing Lists: General Discussion: pce@ietf.org To Subscribe: http://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 so as to enable a Path Computation Element (PCE)-based architecture for the computation of paths for MPLS and GMPLS Point to Point and Point to Multi-point Traffic Engineered LSPs. In this architecture path computation does not necessarily occur on the head-end (ingress) LSR, but on some other path computation entity that may not be physically located on each head-end LSR. 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 determines requirements for extensions to existing routing and signaling protocols in support of the PCE architecture and the signaling of inter-domain paths (e.g., RSVP-TE and its GMPLS variations). Any necessary extensions will be produced in collaboration with the Working Groups responsible for the protocols. The WG also works on the mechanisms to for multi-layer path computation and PCEP extensions for communication between several network layers. The WG defines the required PCEP extensions for Wavelength Switched Optical Networks (WSON) while keeping consistency with the GMPLS 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. - In cooperation with protocol specific Working Group (e.g., MPLS, CCAMP), development of LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models. - Specification of PCEP extensions for expressing path computation requests and responses in the various GMPLS-controlled networks, including WSON. - Definition of PCEP extensions for path computation in multi-layer networks. - Definition 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 receiving PCC/PCE chooses to not follow the recommendation. Goals and Milestones: Feb 2015 - Evaluate WG progress, recharter or close Done - Submit first draft of PCE architecture document Done - Submit first draft of PCE discovery requirements and protocol extensions documents Done - Submit first draft of the PCE communication protocol requirements Done - Submit first draft of the definition of objective metrics Done - Submit first draft of the PCE communication protocol specification Done - Submit PCE architecture specification to the IESG to be considered as Informational RFC Done - Submit first draft of the MIB module for the PCE protocol Done - Submit PCE communication protocol requirements to the IESG to be considered as an Informational RFC Done - Submit PCE discovery protocol extensions specifications to the IESG to be considered as a Proposed Standard Done - Submit PCE communication protocol specification to the IESG to be considered as a Proposed Standard Done - Submit first draft of the PCE P2MP communication requirements Done - Submit first draft of the PCE P2MP PCEP protocol extensions Done - Submit PCE P2MP communication requirements to the IESG to be considered as an Informational RFC Done - Submit PCE P2MP PCEP protocol extensions to the IESG to be considered as an Proposed Standard RFC Done - Submit applicability and metrics documents to the IESG Done - Submit the GMPLS requirements to the IESG to be considered as an Informational RFC Done - Submit inter-area/AS applicability statement to the IESG as an informational RFC Done - Submit PCEP extensions for GMPLS to the IESG to be considered as a Proposed Standard Done - Submit inter-layer extensions to the IESG to be considered as a Proposed Standard Done - Submit extensions for hierarchical model to the IESG to be considered as a Proposed Standard Done - Submit the PCEP MIB to the IESG to be considered as a Proposed Standard Done - Submit the stateful PCE document(s) to the IESG 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) - Experimental Codepoint Allocation for Path Computation Element communication Protocol (PCEP) [draft-dhody-pce-pcep-exp-codepoints-03] (6 pages) - PCEP Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with Stateful PCE [draft-dhody-pce-stateful-pce-auto-bandwidth-09] (25 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) - 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) - PCEP Extensions for Associated Bidirectional Label Switched Paths (LSPs) [draft-ietf-pce-association-bidir-06] (19 pages) - Path Computation Element Communication Protocol (PCEP) Extension for LSP Diversity Constraint Signaling [draft-ietf-pce-association-diversity-14] (24 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-09] (15 pages) - Carrying Binding Label/Segment-ID in PCE-based Networks. [draft-ietf-pce-binding-label-sid-02] (16 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 (PCE) Communication Protocol Generic Requirements [draft-ietf-pce-comm-protocol-gen-reqs-07] (21 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-07] (22 pages) - PCEP Extension for Flexible Grid Networks [draft-ietf-pce-flexible-grid-03] (18 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) - PCEP extensions for GMPLS [draft-ietf-pce-gmpls-pcep-extensions-16] (44 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) - 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) - 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) - Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) [draft-ietf-pce-interas-pcecp-reqs-06] (14 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) - 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) - 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) - 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 (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model [draft-ietf-pce-pce-initiated-lsp-11] (20 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 (PCE) Communication Protocol (PCEP) [draft-ietf-pce-pcep-19] (87 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) - PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs [draft-ietf-pce-pcep-extension-for-pce-controller-04] (34 pages) - PCEP Extension for Native IP Network [draft-ietf-pce-pcep-extension-native-ip-05] (11 pages) - PCEP Extension for Flow Specification [draft-ietf-pce-pcep-flowspec-08] (33 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) - 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) - 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) - Path Computation Element (PCE) Protocol Extensions for Stateful PCE Usage in GMPLS-controlled Networks [draft-ietf-pce-pcep-stateful-pce-gmpls-13] (19 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-13] (113 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) - 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) - PCEP Extensions for Segment Routing leveraging the IPv6 data plane [draft-ietf-pce-segment-routing-ipv6-04] (22 pages) - PCEP Extensions for Associated Bidirectional Segment Routing (SR) Paths [draft-ietf-pce-sr-bidir-path-02] (17 pages) - Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR) [draft-ietf-pce-sr-path-segment-01] (26 pages) - Updated Rules for Processing Stateful PCE Request Parameters Flags [draft-ietf-pce-stateful-flags-01] (7 pages) - Hierarchical Stateful Path Computation Element (PCE) [draft-ietf-pce-stateful-hpce-15] (21 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) - PCEP Extensions for LSP scheduling with stateful PCE [draft-ietf-pce-stateful-pce-lsp-scheduling-13] (25 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) - Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE [draft-ietf-pce-stateful-sync-optimizations-10] (26 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 LSPs and Virtual Networks [draft-ietf-pce-vn-association-02] (14 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) - PCEP Extension for WSON Routing and Wavelength Assignment [draft-ietf-pce-wson-rwa-ext-17] (33 pages) - Extensions to the Path Computation Element Protocol (PCEP) for residual path bandwidth support [draft-lazzeri-pce-residual-bw-01] (16 pages) - PCEP Extension for Flexible Grid Networks [draft-lee-pce-flexible-grid-03] (20 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 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) - 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) - Carrying Binding Label/Segment-ID in PCE-based Networks. [draft-sivabalan-pce-binding-label-sid-07] (16 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) RFC5089: IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery (17 pages) 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 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) 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) 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) Privacy Enhanced RTP Conferencing (perc) ---------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Nils Ohlmeier Suhas Nandakumar Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: perc@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/perc Archive: https://mailarchive.ietf.org/arch/browse/perc/ Description of Working Group: RTP-based real-time multi-party interactive media conferencing is in widespread use today. Many of the deployments use one or more centrally located media distribution devices that perform selective forwarding of mixed-media streams received from the participating endpoints. The media transport protocol commonly used is RTP (RFC3550). There are various signaling systems used to establish these multi-party conferences. These conferences require security to ensure that the RTP media and related metadata of the conference is kept private and only available to the set of invited participants and other devices trusted by those participants with their media. At the same time, multi-party media conferences need source authentication and integrity checks to protect against modifications, insertions, and replay attacks. Media distribution devices supporting these conferences may also perform RTP header changes, and they often consume and create RTCP messages for efficient media handling. To date, deployment models for these multi-party media distribution devices do not enable the devices to perform their functions without having keys to decrypt the participants' media, primarily using Secure RTP (RFC3711) to provide session security. This trust model has limitations and prevents or hampers deployment of secure RTP conferencing in a multitude of cases, including outsourcing, legal requirements on confidentiality, and utilization of virtualized servers. Thus, a new architectural model and related specifications are needed, with a focused effort from the RTP and Security communities. WG Objectives This WG will work on a solution that enables centralized SRTP-based conferencing, where the central device distributing the media is not required to be trusted with the keys to decrypt the participants' media. The media must be kept confidential and authenticated between an originating endpoint and the explicitly allowed receiving endpoints or other devices. The meta information provided to the central device is to be limited to the minimal required for it to perform its function to preserve the conference participants privacy. Further, it is desired that a solution still provides replay protection, so that the media distribution devices cannot replay previous parts of the media. The solution must also provide security for each hop between endpoints and multi-party media distribution devices and between multi-party media distribution devices. The RTCP messages and RTP header extensions required for the media distribution device to perform the selective media forwarding may require both source authentication and integrity as well as confidentiality. The solution may also consider providing end-to-end security for a subset of the RTCP messages or RTP header extensions. The solution should be implementable by both SIP (RFC3261) and WebRTC endpoints (draft-ietf-rtcweb-overview). How telepresence endpoints using the protocols defined in the CLUE working group could utilize the defined security solution needs to be considered. However, it is acknowledged that limitations may exist, resulting in restricted functionality or need for additional adaptations of the CLUE protocols. This working group will perform the following work: 1. Define a general architecture and RTP topology(s) that enables end-to-end media security for multi-party RTP conferencing. 2. Define the trust model and describe the resulting security properties. 3. Document models considered for integrating the solution with WebRTC, SIP and CLUE establishment of conferencing sessions. 4. Specify any necessary extensions to SRTP. 5. Define needed Key Management Functions that distribute the keys. The system needs to be able to bind the media to the identity of the sender of the media and/or the identity of the conference. Collaboration If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG. Potential items that might require work in other WGs are DTLS extensions (TLS WG) and RTP header extensions (AVTEXT WG). This work requires strong collaboration with the security area. We will notify, and when needed coordinate with, AVTCore, CLUE, MMUSIC, RTCWEB, SIPREC, W3C WebRTC, and other related groups about this work. Non-Goals The PERC working group is not chartered to extend any signaling system used to establish the RTP-based conferences. It will, however, need to consider in its architecture how the solution may integrate with these systems, and document such consideration for WebRTC, SIP, and CLUE. The specification of how a particular system integrates the security solution will happen outside of this working group, in suitable venues. The WG will not consider non-real-time usage, multicast-based media distribution, or Security descriptions-based keying (RFC4568). Input to the WG Proposals already existing relating to this charter proposal: https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-reqts/ https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-framework/ https://datatracker.ietf.org/doc/draft-cheng-avtcore-srtp-cloud/ Goals and Milestones: Dec 2017 - Submit SRTP protocol extension specification to IESG (Standards Track) Dec 2017 - Submit Key-management protocol specification to IESG (Standards Track) Mar 2018 - Submit documentation of how to integrate solution in SIP, WebRTC and CLUE to IESG (Informational) Done - Submit encrypted key transport specification to IESG (Standards Track) Done - Submit architecture or framework specification to IESG (Standards Track) Internet-Drafts: - Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP) [draft-ietf-perc-double-12] (18 pages) - DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange [draft-ietf-perc-dtls-tunnel-06] (17 pages) - A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing (PERC) [draft-ietf-perc-private-media-framework-12] (28 pages) - Encrypted Key Transport for DTLS and Secure RTP [draft-ietf-perc-srtp-ekt-diet-11] (25 pages) Requests for Comments: RFC8723: Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP) (18 pages) Protocols for IP Multicast (pim) -------------------------------- Charter Last Modified: 2018-07-12 Current Status: Active Chairs: Mike McBride Stig Venaas Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Alvaro Retana 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 - igmp yang model submitted to iesg Nov 2015 - mld 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: - Anycast-RP Using Protocol Independent Multicast (PIM) [draft-ietf-pim-anycast-rp-07] (12 pages) - PIM Assert Message Packing [draft-ietf-pim-assert-packing-00] (13 pages) - Bidirectional Forwarding Detection (BFD) for Multi-point Networks and Protocol Independent Multicast - Sparse Mode (PIM-SM) Use Case [draft-ietf-pim-bfd-p2mp-use-case-03] (8 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) - PIM DR Improvement [draft-ietf-pim-dr-improvement-09] (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) - 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) - 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) - IGMPv3/MLDv2 Message Extension [draft-ietf-pim-igmp-mld-extension-00] (8 pages) - A Yang Data Model for IGMP/MLD Proxy [draft-ietf-pim-igmp-mld-proxy-yang-02] (16 pages) - A Yang Data Model for IGMP and MLD Snooping [draft-ietf-pim-igmp-mld-snooping-yang-10] (48 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) - 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) - Host Threats to Protocol Independent Multicast (PIM) [draft-ietf-pim-lasthop-threats-04] (12 pages) - Protocol Independent Multicast MIB [draft-ietf-pim-mib-v2-10] (90 pages) - A YANG Data Model for Multicast Source Discovery Protocol (MSDP) [draft-ietf-pim-msdp-yang-18] (35 pages) - PIM Multi-Topology ID (MT-ID) Join Attribute [draft-ietf-pim-mtid-10] (13 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-05] (8 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) - Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments [draft-ietf-pim-rfc4601-update-survey-report-03] (12 pages) - Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) [draft-ietf-pim-rfc4601bis-06] (137 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) - 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) - A YANG Data Model for Protocol Independent Multicast (PIM) [draft-ietf-pim-yang-17] (106 pages) Requests for Comments: RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) (61 pages) * Updates RFC8736 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 RFC5059: Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM) (42 pages) * Updates RFC8736 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 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 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 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) RFC8775: PIM Designated Router Load Balancing (18 pages) STD83: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) (137 pages) QUIC (quic) ----------- Charter Last Modified: 2020-03-09 Current Status: Active Chairs: Lars Eggert Lucas Pardue Mark Nottingham Transport Area Directors: Martin Duke Magnus Westerlund Transport Area Advisor: Magnus Westerlund 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 working group will provide standards-track specifications for a UDP-based, stream-multiplexing, encrypted transport protocol, based on pre-standardization implementation and deployment experience. Key goals for QUIC are: - Minimizing connection establishment and overall transport latency for applications, starting with HTTP; - Providing multiplexing without head-of-line blocking; - Requiring only changes to path endpoints to enable deployment; - Enabling multipath and forward error correction extensions; and - Providing always-secure transport, using TLS 1.3 by default. The work of the group will have five main focus areas, corresponding to five core deliverables. The first of these is the core transport work, which will describe the wire format, along with the mechanisms for connection establishment, stream multiplexing, data reliability, loss detection and recovery, congestion control, and options negotiation. Work on congestion control will describe use of a standardized congestion controller as a default scheme for QUIC. Defining new congestion control schemes is explicitly out of scope for this group. QUIC is expected to support rapid, distributed development and testing of features. The second of these focus areas is security. This work will describe how the protocol uses TLS 1.3 for key negotiation and will also describe how those keys are used to provide confidentiality and integrity protection of both application data and QUIC headers. This work will ensure that QUIC has security and privacy properties that are at least as good as a stack composed of TLS 1.3 using TCP (or MPTCP when using multipath). The third focus area describes the mapping between the HTTP application protocol and the transport facilities of QUIC. This mapping will have performance characteristics comparable with HTTP/2, and provide extension mechanisms similar to HTTP/2. Upon completion of this mapping, work to define additional mappings may be included by updates to this charter, or may be worked on by other working groups. The fourth focus area will be on extensions to core protocol facilities, to enable datagram delivery, version negotiation, and multipath capabilities. Other extensions are out of the scope of this charter. The fifth focus area will provide an Applicability and Manageability Statement, describing how, and under what circumstances, QUIC may be safely used, and describing deployment and manageability implications of the protocol. Additionally, the Working Group will provide guidance on how to handle QUIC traffic in load balancers. Current practices for network management of transport protocols include the ability to apply access control lists (ACLs), hashing of flows for equal-cost multipath routing (ECMP), directional signaling of flows, signaling of flow setup and teardown, and the ability to export information about flows for accounting purposes. The QUIC protocol need not be defined to enable each of these abilities, or enable them in the same way as they are enabled by TCP when used with TLS 1.3, but the working group must consider the impact of the protocol on network management practices, reflecting the tensions described in RFC 7258. The QUIC working group will work closely with the HTTPbis working group, especially on the QUIC mapping for HTTP. Goals and Milestones: Jul 2020 - Core Protocol document to IESG Jul 2020 - Loss detection and Congestion Control document to IESG Jul 2020 - TLS 1.3 Mapping document to IESG Jul 2020 - HTTP/2 mapping document to IESG Jul 2020 - QUIC Applicability and Manageability Statement to IESG Jul 2020 - Version-Independent Properties of QUIC to IESG Jul 2020 - QPACK: Header Compression for HTTP over QUIC to IESG Dec 2020 - Working group adoption of Multipath extension document Mar 2021 - Datagram Extension to IESG Mar 2021 - Version Negotiation Extension to IESG Mar 2021 - QUIC-LB: Generating Routable QUIC Connection IDs to IESG Dec 2021 - Multipath extension document to IESG Internet-Drafts: - QUIC-LB: Generating Routable QUIC Connection IDs [draft-duke-quic-load-balancers-06] (31 pages) - QUIC: A UDP-Based Multiplexed and Secure Transport [draft-hamilton-quic-transport-protocol-01] (45 pages) - Applicability of the QUIC Transport Protocol [draft-ietf-quic-applicability-06] (16 pages) - An Unreliable Datagram Extension to QUIC [draft-ietf-quic-datagram-00] (9 pages) - Hypertext Transfer Protocol Version 3 (HTTP/3) [draft-ietf-quic-http-27] (61 pages) - Version-Independent Properties of QUIC [draft-ietf-quic-invariants-07] (10 pages) - QUIC-LB: Generating Routable QUIC Connection IDs [draft-ietf-quic-load-balancers-02] (27 pages) - Manageability of the QUIC Transport Protocol [draft-ietf-quic-manageability-06] (22 pages) - Header Compression for HTTP over QUIC [draft-ietf-quic-qcram-00] (11 pages) - QPACK: Header Compression for HTTP/3 [draft-ietf-quic-qpack-14] (38 pages) - QUIC Loss Detection and Congestion Control [draft-ietf-quic-recovery-27] (41 pages) - The QUIC Latency Spin Bit [draft-ietf-quic-spin-exp-01] (8 pages) - Using TLS to Secure QUIC [draft-ietf-quic-tls-27] (52 pages) - QUIC: A UDP-Based Multiplexed and Secure Transport [draft-ietf-quic-transport-27] (174 pages) - QUIC Version Aliasing [draft-ietf-quic-version-aliasing-00] (11 pages) - Compatible Version Negotiation for QUIC [draft-ietf-quic-version-negotiation-00] (8 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) - 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) - 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: REVIEW-IETF-EMU-RFC5448BIS-06-SECDIR-LC-ROSE-2020-01-27: QUIC-LB: Generating Routable QUIC Connection IDs (27 pages) RADIUS EXTensions (radext) -------------------------- Charter Last Modified: 2018-04-10 Current Status: Active Chairs: Lionel Morand Stefan Winter Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Benjamin Kaduk 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 pending approval of the new work from the Area Director and clarify its usage and definition. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restriction is imposed on extensions considered by the RADEXT WG: All documents produced must specify means of interoperation with legacy RADIUS and, if possible, be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090, 5176 and 6158. Transport profiles should, if possible, be compatible with RFC 3539. 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. Any changes to document tracks require approval by the responsible Area Director. Work Items The immediate goals of the RADEXT working group are to address the following issues: - CoA proxying. RFC 5176 permits proxying of CoA and Disconnect messages, but makes no provisions for how that is done in a roaming environment. This work item will provide descriptions of how to use the Operator-Name attribute in a roaming environment to proxy CoA packets in a way that ensures only authorized proxies can send these packets to the home CoA server. - Encoding Rules for EAP-Response/Identity packets over RADIUS. Neither EAP (RFC3748) nor EAP over RADIUS (RFC3579) demand specific character encoding and normalisation rules for EAP Identity responses. RADIUS (RFC2865) requires User-Name attributes to be encoded in UTF-8. When a NAS simply performs an exact copy of an EAP-Identity into a User-Name, invalid packets might be produced. This document will suggest restrictions on EAP Identities so that transport over AAA becomes correct under all circumstances (UTF-8) and deterministic (normalisation). - Data Types. RFC 2865 defines a number of data types, but later documents do not use those types in a consistent way. This work item will define data types, and update the IANA RADIUS Attribute Type registry so that each attribute has a data type. Where necessary, it will correct issues with previous specifications. - Larger Packets. Support RADIUS packets greater than 4096-octets over RADIUS transports with this capability. - RADIUS Attributes for IP Port Configuration and Reporting. These attributes are used by devices that implement IP port ranges to configure and report TCP/UDP ports and ICMP identifiers, as well as mapping behaviors. These attributes can be used in the context of address sharing (e.g., NAT44 [RFC3022], Dual-Stack Lite AFTR [RFC6333], CGN [RFC6888], NAT64 [RFC6146], Provider WLAN (e.g., [TR-146]), etc.). Goals and Milestones: Nov 2015 - Larger Packets for RADIUS over TCP I-D submitted as an Experimental RFC Nov 2015 - Submit CoA Proxying as Standards Track RFC Mar 2016 - IP Port RADIUS Extensions as Standards Track RFC Nov 2016 - Submit Populating EAP Identity as BCP RFC Nov 2016 - Data Types as Informational RFC Done - RFC 4282bis submitted as a Proposed Standard RFC Done - Dynamic Discovery I-D submitted as a Proposed Standard RFC Done - RADIUS packet fragmentation submitted as an Experimental RFC Internet-Drafts: - 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) - The Network Access Identifier [draft-dekok-radext-nai-02] (19 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) - 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) - 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) - Transport Layer Security (TLS) Encryption for RADIUS [draft-ietf-radext-radsec-12] (22 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) - 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) - 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) - Considerations regarding the correct use of EAP-Response/Identity [draft-winter-radext-populating-eapidentity-01] (7 pages) Requests for Comments: BCP158: RADIUS Design Guidelines (38 pages) 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) 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: 2019-03-27 Current Status: Active Chairs: Kathleen Moriarty Nancy Cam-Winget Ned Smith Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Roman Danyliw 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) enable relying parties to establish a level of confidence in the trustworthiness of remote system components through the creation of attestation evidence by remote system components and a processing chain towards the relying party. A relying party can then decide whether to consider a remote system component trustworthy or not. 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, * 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)/Trusted 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 ===== This WG will standardize formats for describing assertions/claims about system components and associated evidence; and procedures and protocols to convey these assertions/claims to relying parties. Given the security and privacy sensitive nature of these assertions/claims, the WG will specify approaches to protect this exchanged data. While a relying party may use reference, known, or expected values or thresholds to assess the assertions/claims, the procedures for this activity are out of scope for this WG (without rechartering). The working group will cooperate and coordinate with other IETF WGs such as TEEP, SUIT, and SACM, and work with organizations in the community, such as the TCG and the FIDO Alliance, as appropriate. The WG will also evaluate prior work such as NEA and proprietary attestation technologies like the Android Keystore. 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 terminology and architecture that enable attestation techniques. The architecture may include a system security model for the signing key material and involve at least the system component, system component provider, and the relying authority. 3. Standardize an information model for assertions/claims which provide information about system components characteristics 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. Standardize interoperable protocols to securely convey assertions/claims. Goals and Milestones: Mar 2019 - Begin work on use case documentation (may not be published as an RFC) Mar 2019 - Call for adoption on Tokbind draft Jul 2019 - Call for adoption on architecture draft Nov 2019 - Call for adoption on Yang Module draft Mar 2020 - Submit EAT draft to IESG for publication Mar 2020 - Submit Tokkbind draft to IESG for publication Mar 2020 - Submit Interaction Models draft to IESG for publication Mar 2020 - Submit YANG Module draft to IESG for publication Mar 2020 - Submit TUDA draft to IESG for publication Nov 2020 - Submit Claim format draft to IESG for publication Jul 2021 - Submit Architecture draft to IESG for publication Done - Call for adoption on EAT draft. Internet-Drafts: - Remote Attestation Procedures Architecture [draft-ietf-rats-architecture-02] (25 pages) - The Entity Attestation Token (EAT) [draft-ietf-rats-eat-03] (35 pages) - A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs [draft-ietf-rats-yang-tpm-charra-01] (34 pages) No Requests for Comments Reliable and Available Wireless (raw) ------------------------------------- Charter Last Modified: 2020-02-07 Current Status: Active Chairs: Eve Schooler Rick Taylor Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Deborah Brungard Mailing Lists: General Discussion: raw@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/raw Archive: https://mailarchive.ietf.org/arch/browse/raw/ Description of Working Group: Reliable and Available Wireless (RAW) provides for high reliability and availability for IP connectivity over a wireless medium. The wireless medium presents significant challenges to achieve deterministic properties such as low packet error rate, bounded consecutive losses, and bounded latency. RAW extends the DetNet Working Group concepts to provide for high reliability and availability for an IP network utilizing scheduled wireless segments and other 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. Similar to DetNet, RAW will stay abstract to the radio layers underneath, addressing the Layer 3 aspects in support of applications requiring high reliability and availability. While DetNet solutions apply to both wireless and wired, there has been recent industry interest for wireless applications which were not initially included in the DetNet use cases. One critical application is Aeronautical Data Communications. The Aeronautical standards work on a physical layer and data link layer for data communications is reaching maturity and there is significant interest in IP connectivity applications. Other examples of potential wireless applications include industrial, pro audio and video, gaming, and edge robotics. In the interests of providing timely solutions for these newly identified industry applications, RAW’s focus will be on specifying use cases associated with these new applications and defining requirements derived from them. RAW will solicit input on deployment plans, requirements, and operational practices (including security and privacy aspects) for these newer industrial applications. RAW’s primary focus is on identifying areas where the DetNet adaptation to wireless networks and other IETF technologies may require additional supporting mechanisms. The RAW Working Group will also examine the applicability of other existing IETF work, e.g., MANET's dynamic link exchange protocol (DLEP). The RAW Working Group will provide input to the DetNet Working Group, MANET Working Group, and other IETF Working Groups, and cooperate in reviewing solutions to RAW’s identified deployment problems. RAW is not chartered to work on a solution. If solution work is needed, the Working Group will coordinate with the IESG to determine where the work will be done. If RAW is chosen for the solution work, the Working Group will recharter. The RAW Working Group is planned to be a short timeframe (12-18 months) Working Group to quickly address these newer industry applications. The initial milestones will be published as Informational documents: Use Cases, Requirements, Architecture/Framework Aspects for a Wireless Network, and an Evaluation of Existing IETF Technologies and Gap Analysis. Additional documents may be published or exist on a git repository, the publication format will be agreed by the Working Group at the time the document is adopted by the group. The Use Case document may consist of one or more documents to allow users/operators the opportunity to provide comprehensive deployment plans for these new (to IETF) technologies, e.g., the Aeronautical Data Communication applications. The group will closely coordinate with the DetNet and MANET Working Groups. The work produced by this group may be of interest to other SDOs, 3GPP, IEEE, and the Aeronautical industry. Goals and Milestones: Sep 2020 - Working Group Adoption of Use Cases Document Sep 2020 - Working Group Adoption of Requirements Document Nov 2020 - Working Group Adoption of Architecture/Framework Aspects for a Wireless Network Document Nov 2020 - Use Cases Document submit to IESG Dec 2020 - Working Group Adoption of Evaluation of Existing IETF Technologies and Gap Analysis Document Dec 2020 - Requirements Document submit to IESG Apr 2021 - Architecture/Framework Aspects for a Wireless Network Document submit to IESG Jun 2021 - Evaluation of Existing IETF Technologies and Gap Analysis Document submit to IESG Internet-Drafts: No Requests for Comments Registration Protocols Extensions (regext) ------------------------------------------ Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Antoin Verschuren James Galvin Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba 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: Nov 2019 - Submit for publication "Registration Data Access Protocol (RDAP) Reverse search capabilities" Jul 2020 - Submit for publication "EPP Secure Authorization Information for Transfer" Jul 2020 - Submit for publication "EPP Unhandled Namespaces" Oct 2020 - Submit for publication "Registry Maintenance Notifications for the EPP" Mar 2021 - Submit for publication "Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect" 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" Internet-Drafts: - Extensible Provisioning Protocol (EPP) Unhandled Namespaces [draft-gould-casanova-regext-unhandled-namespaces-02] (18 pages) - Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer [draft-gould-regext-secure-authinfo-transfer-03] (24 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) - Registry Data Escrow Specification [draft-ietf-regext-data-escrow-09] (23 pages) - Domain Name Registration Data (DNRD) Objects Mapping [draft-ietf-regext-dnrd-objects-mapping-07] (178 pages) - Third Party DNS operator to Registrars/Registries Protocol [draft-ietf-regext-dnsoperator-to-rrr-protocol-05] (15 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 Notifications for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-epp-registry-maintenance-01] (20 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] (27 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) - 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-04] (25 pages) - Registration Data Access Protocol (RDAP) Partial Response [draft-ietf-regext-rdap-partial-response-10] (14 pages) - Registration Data Access Protocol (RDAP) Reverse search capabilities [draft-ietf-regext-rdap-reverse-search-03] (9 pages) - Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging [draft-ietf-regext-rdap-sorting-and-paging-12] (27 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) - Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer [draft-ietf-regext-secure-authinfo-transfer-01] (26 pages) - ICANN TMCH functional specifications [draft-ietf-regext-tmch-func-spec-08] (63 pages) - Extensible Provisioning Protocol (EPP) Unhandled Namespaces [draft-ietf-regext-unhandled-namespaces-01] (20 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) - 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: BCP221: Registration Data Access Protocol (RDAP) Object Tagging (13 pages) 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) Routing In Fat Trees (rift) --------------------------- Charter Last Modified: 2020-03-20 Current Status: Active Chairs: Jeff Tantsura Zhaohui (Jeffrey) Zhang Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Alvaro Retana Mailing Lists: General Discussion: rift@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/rift Archive: https://mailarchive.ietf.org/arch/search/?email_list=rift Description of Working Group: Data Centers have been steadily growing to commonly host tens of thousands of end points, or more, in a single network. Because of their topologies (traditional and emerging), traffic patterns, need for fast restoration, and for low human intervention, data center networks have a unique set of requirements that is resulting in the design of routing solutions specific to them. Clos and Fat-Tree topologies have gained popularity in data center networks as a result of a trend towards centralized data center network architectures that may deliver computation and storage services. The Routing in Fat Trees (RIFT) protocol addresses the demands of routing in Clos and Fat-Tree networks via a mixture of both link-state and distance-vector techniques colloquially described as 'link-state towards the spine and distance vector towards the leafs'. RIFT uses this hybrid approach to focus on networks with regular topologies with a high degree of connectivity, a defined directionality, and large scale. The RIFT Working Group will work on a standards track specification of a specialized, dynamic routing protocol for Clos and fat-tree network topologies. The protocol will: - deal with automatic construction of fat-tree topologies based on detection of links, - minimize the amount of routing state held at each topology level, - automatically prune topology distribution exchanges to a sufficient subset of links, - support automatic disaggregation of prefixes on link and node failures to prevent black-holing and suboptimal routing, - allow traffic steering and re-routing policies, - and provide mechanisms to synchronize a limited key-value data-store that can be used after protocol convergence. It is important that nodes participating in the protocol should need only very light configuration and should be able to join a network as leaf nodes simply by connecting to the network using default configuration. The protocol must support IPv6 and should also support IPv4. The Working Group may establish additional requirements to constrain and inform their work. The RIFT Working Group is chartered for the following list of items: - A Standards Track specification that will include: - an Implementation Status section as described in RFC 7942 - an Operational Considerations section to explain how the protocol is configured, deployed, and diagnosed, security and privacy mitigations for the protocol as identified in the threat analysis document. (q.v.) - A YANG module focused on configuration and monitoring of protocol instances - An Applicability Statement that describes how to deploy and configure the protocol in networks with different topologies - A Security Threat Analysis document that describes the attack vectors, which shall be sent for publication at the same time as the protocol specification Goals and Milestones: Apr 2020 - Submit protocol specification to IESG for publication Aug 2020 - Submit YANG module to IESG for publication Aug 2020 - Submit Applicability Statement to IESG for publication Done - Adopt a protocol specification document Internet-Drafts: - RIFT Applicability [draft-ietf-rift-applicability-01] (29 pages) - RIFT: Routing in Fat Trees [draft-ietf-rift-rift-11] (162 pages) - RIFT YANG Model [draft-ietf-rift-yang-00] (22 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 RTP Media Congestion Avoidance Techniques (rmcat) ------------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Anna Brunstrom Colin Perkins Transport Area Directors: Martin Duke Magnus Westerlund Transport Area Advisor: Martin Duke Mailing Lists: General Discussion: rmcat@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/rmcat Archive: https://mailarchive.ietf.org/arch/browse/rmcat/ Description of Working Group: Today's Internet traffic includes interactive real-time media, which is often carried via sets of flows using RTP over UDP. There is no generally accepted congestion control mechanism for this kind of data flow. With the deployment of applications using the RTCWEB protocol suite, the number of such flows is likely to increase, especially non-fixed-rate flows such as video or adaptive audio. There is therefore some urgency in specifying one or more congestion control mechanisms that can find general acceptance. Congestion control algorithms for interactive real time media may need to be quite different from the congestion control of TCP: for example, some applications can be more tolerant to loss than delay and jitter. The set of requirements for such an algorithm includes, but is not limited to: - Low delay and low jitter for the case where there is no competing traffic using other algorithms - Reasonable share of bandwidth when competing with RMCAT traffic, other real-time media protocols, and ideally also TCP and other protocols. A 'reasonable share' means that no flow has a significantly negative impact [RFC5033] on other flows and at minimum that no flow starves. - Effective use of signals like packet loss and ECN markings to adapt to congestion The working group will: - Develop a clear understanding of the congestion control requirements for RTP flows, and document deficiencies of existing mechanisms such as TFRC with regards to these requirements. This must be completed prior to finishing any Experimental algorithm specifications. - Identify interactions between applications and RTP flows to enable conveying helpful cross-layer information such as per-packet priorities, flow elasticity, etc. This information might be used to populate an API, but the WG will not define a specific API itself. - Determine if extensions to RTP/RTCP are needed for carrying congestion control feedback, using DCCP as a model. If so, provide the requirements for such extensions to the AVTCORE working group for standardization there. - Develop techniques to detect, instrument or diagnose failing to meet RT schedules due to failures of components outside of the charter scope, possibly in collaboration with IPPM. - Develop a mechanism for identifying shared bottlenecks between groups of flows, and means to flexibly allocate their rates within the aggregate hitting the shared bottleneck. - Define evaluation criteria for proposed congestion control mechanisms, and publish these as an Informational RFC. This must be completed prior to finishing any Proposed Standard algorithm specifications. - Find or develop candidate congestion control algorithms, verify that these can be tested on the Internet without significant risk, and publish one or more of these as Experimental RFCs. - Publish evaluation criteria and the result of experimentation with these Experimental algorithms on the Internet. This must be completed prior to finishing any Proposed Standard algorithm specifications. - Once an algorithm has been found or developed that meets the evaluation criteria, and has a satisfactory amount of documented experience on the Internet, publish this algorithm as a Standards Track RFC. There may be more than one algorithm; in this case it will be one of the objects of the experimentation to determine the applicabilities and relative merits of the algorithms. - For each of the Experimental algorithms that have not been selected for the Standards Track, the working group will review the algorithm and determine whether there are significant flaws, such as ones that turn out to be harmful to flows using or competing with them. If so, the WG will write a document describing the issues encountered and recommending to the IESG to move the specification to Historic status. The work will be guided by the advice laid out in RFC 5405 (UDP Usage Guidelines), RFC 2914 (congestion control principles), and RFC5033 (Specifying New Congestion Control Algorithms). The following topics are out of scope of this working group, on the assumption that work on them will proceed elsewhere: - Circuit-breaker algorithms for stopping media flows when network conditions render them useless; this work is done in AVTCORE - Media flows for non-interactive purposes like stored video playback; those are not as delay sensitive as interactive traffic - Defining active queue management algorithms or modifications to TCP of any kind - Multicast congestion control; common control of multiple unicast flows is in scope - Topologies other than point-to-point connections; implications on multi-hop connections will be considered at a later stage The working group is expected to work closely with the RAI area, including the underlying technologies being worked on in the AVTCORE and AVTEXT WGs, and the applications/protocol suites being developed in the CLUE and RTCWEB working groups. It will also coordinate closely with other Transport area groups working on congestion control, and with the Internet Congestion Control Research Group of the IRTF. Deliverables: - Requirements for congestion control algorithms for interactive real time media as an Informational RFC - Evaluation criteria for congestion control algorithms for interactive real time media as an Informational RFC - Requirements for RTCP extensions for use with congestion control algorithms as an input to the AVTCORE WG. - Interactions between applications and RTP flows as an Informational RFC - Identifying and controlling groups of flows as a Proposed Standard RFC - Techniques to detect, instrument or diagnose failing to meet RT schedules as either an Informational RFC or on the Standards Track if needed for interoperability or other aspects that would justify it. - Candidate congestion control algorithm for interactive real time media as Experimental RFCs (likely more than one) - Experimentation and evaluation results for candidate congestion control algorithms as an Informational RFC - One or more recommended congestion control algorithms for interactive real time media as Proposed Standard RFCs Goals and Milestones: Nov 2020 - Publish first draft of evaluation results Nov 2020 - Publish first draft of Standards Track congestion control algorithm Mar 2021 - Submit congestion control to IESG for Proposed Standard Done - Adopt first WG draft on requirements Done - Adopt first WG draft on evaluation criteria Done - Adopt first WG draft of RTCP extensions for use with congestion control algorithms and interactions between applications and RTP flows (if needed) Done - Adopt first congestion control candidate as WG draft Done - Adopt first WG draft on identifying and controlling groups of flows Done - Submit identifying and controlling groups of flows to IESG for Experimental publication Done - Submit first congestion control candidate to IESG for Experimental publication Done - Submit RTCP extension requirements for use with congestion control algorithms to AVTCORE (if needed) Done - Submit requirements and evaluation criteria to IESG as Informational Internet-Drafts: - A Google Congestion Control Algorithm for Real-Time Communication [draft-alvestrand-rmcat-congestion-03] (19 pages) - RTP Control Protocol (RTCP) Feedback for Congestion Control [draft-dt-rmcat-feedback-message-04] (10 pages) - Shared Bottleneck Detection for Coupled Congestion Control for RTP Media. [draft-hayes-rmcat-sbd-02] (18 pages) - RTP Application Interaction with Congestion Control [draft-ietf-rmcat-app-interaction-01] (15 pages) - Congestion Control and Codec interactions in RTP Applications [draft-ietf-rmcat-cc-codec-interactions-02] (12 pages) - Congestion Control Requirements for Interactive Real-Time Media [draft-ietf-rmcat-cc-requirements-09] (12 pages) - Coupled Congestion Control for RTP Media [draft-ietf-rmcat-coupled-cc-09] (20 pages) - Evaluating Congestion Control for Interactive Real-time Media [draft-ietf-rmcat-eval-criteria-14] (17 pages) - Test Cases for Evaluating RMCAT Proposals [draft-ietf-rmcat-eval-test-10] (33 pages) - A Google Congestion Control Algorithm for Real-Time Communication [draft-ietf-rmcat-gcc-02] (19 pages) - Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media [draft-ietf-rmcat-nada-13] (26 pages) - RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences [draft-ietf-rmcat-rtp-cc-feedback-05] (12 pages) - Shared Bottleneck Detection for Coupled Congestion Control for RTP Media [draft-ietf-rmcat-sbd-11] (25 pages) - Self-Clocked Rate Adaptation for Multimedia [draft-ietf-rmcat-scream-cc-13] (36 pages) - Video Traffic Models for RTP Congestion Control Evaluations [draft-ietf-rmcat-video-traffic-model-07] (19 pages) - Evaluation Test Cases for Interactive Real-Time Media over Wireless Networks [draft-ietf-rmcat-wireless-tests-11] (23 pages) - Congestion Control Requirements For RMCAT [draft-jesup-rmcat-reqs-01] (9 pages) - Self-Clocked Rate Adaptation for Multimedia [draft-johansson-rmcat-scream-cc-05] (27 pages) - Test Cases for Evaluating RMCAT Proposals [draft-sarker-rmcat-eval-test-01] (36 pages) - Evaluating Congestion Control for Interactive Real-time Media [draft-singh-rmcat-cc-eval-04] (19 pages) - Coupled congestion control for RTP media [draft-welzl-rmcat-coupled-cc-05] (20 pages) - RTP Application Interaction with Congestion Control [draft-zanaty-rmcat-app-interaction-01] (14 pages) - Congestion Control and Codec interactions in RTP Applications [draft-zanaty-rmcat-cc-codec-interactions-00] (11 pages) - Framework for Real-time Media Congestion Avoidance Techniques [draft-zhu-rmcat-framework-00] (8 pages) - NADA: A Unified Congestion Control Scheme for Real-Time Media [draft-zhu-rmcat-nada-06] (18 pages) Requests for Comments: RFC8298: Self-Clocked Rate Adaptation for Multimedia (36 pages) RFC8382: Shared Bottleneck Detection for Coupled Congestion Control for RTP Media (25 pages) RFC8593: Video Traffic Models for RTP Congestion Control Evaluations (19 pages) RFC8698: Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media (26 pages) RFC8699: Coupled Congestion Control for RTP Media (20 pages) Routing Over Low power and Lossy networks (roll) ------------------------------------------------ Charter Last Modified: 2019-11-27 Current Status: Active Chairs: Dominique Barthel Ines Robles Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Alvaro Retana 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: Mar 2020 - Initial Submission of a proposal with uses cases for RPI, RH3 and IPv6-in-IPv6 encapsulation to the IESG Mar 2020 - Initial submission of a reactive P2P route discovery mechanism based on AODV-RPL protocol to the IESG Mar 2020 - Initial submission of Common Ancestor Objective Functions and Parent Set DAG Metric Container Extension to the IESG Jun 2020 - Initial submission of a proposal for Source-Route Multicast for RPL to the IESG Jun 2020 - Initial submission of a proposal to augment DIS flags and options to the IESG Jun 2020 - Initial submission of Enabling secure network enrollment in RPL networks draft to the IESG Jul 2020 - Initial submission of a YANG model for MPL to the IESG Jul 2020 - Initial submission of a root initiated routing state in RPL to the IESG Oct 2020 - Recharter WG or close Dec 2020 - Initial submission of Mode of Operation extension and Capabilities for RPL to the IESG 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 to the IESG of mechanism to turn on RFC8138 compression feature within a RPL network 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) - AODV based RPL Extensions for Supporting Asymmetric P2P Links in Low-Power and Lossy Networks [draft-ietf-roll-aodv-rpl-08] (27 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-04] (12 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-10] (32 pages) - DIS Modifications [draft-ietf-roll-dis-modifications-01] (15 pages) - Efficient Route Invalidation [draft-ietf-roll-efficient-npdao-18] (23 pages) - Enabling secure network enrollment in RPL networks [draft-ietf-roll-enrollment-priority-02] (8 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-00] (7 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-08] (17 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) - 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-03] (18 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 RPL Configuration Option for the 6LoWPAN Routing Header [draft-ietf-roll-turnon-rfc8138-07] (10 pages) - Routing for RPL Leaves [draft-ietf-roll-unaware-leaves-15] (35 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-38] (63 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) 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) Routing Area Working Group (rtgwg) ---------------------------------- Charter Last Modified: 2018-03-21 Current Status: Active Chairs: Chris Bowers Jeff Tantsura Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Martin Vigoureux Secretary: Yingzhen Qu 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: Nov 2014 - Submit Remote LFA (link protection) for publication as Proposed Standard Mar 2015 - Submit Composite-Link Requirements to IESG for publication as Informational Mar 2015 - Submit initial Internet Draft on Multicast IP Fast Reroute Architecture Mar 2015 - Submit Composite-Link Framework to IESG for publication as Informational Jul 2015 - Submit specification on Advanced IP Fast Reroute mechanism to IESG for publication as Proposed Standard Jul 2015 - Submit Document on Operational Experience of using BGP in a Data Center for publication as Informational Jul 2015 - Submit Operational Management for LFA for publication as Proposed Standard Jul 2015 - Submit Remote LFA (node protection) for publication as Proposed Standard Nov 2015 - Submit MIB for IP Fast-Reroute for publication as Proposed Standard 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) - YANG Data Model for ARP [draft-ding-rtgwg-arp-yang-model-02] (15 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) - YANG Data Model for ARP [draft-ietf-rtgwg-arp-yang-model-03] (17 pages) - A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network [draft-ietf-rtgwg-atn-bgp-05] (20 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-11] (30 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) - 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) - A Framework for Loop-Free Convergence [draft-ietf-rtgwg-lf-conv-frmwk-07] (22 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) - 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) - Networks Connecting to Hybrid Cloud DCs: Gap Analysis [draft-ietf-rtgwg-net2cloud-gap-analysis-06] (20 pages) - Dynamic Networks to Hybrid Cloud DCs Problem Statement [draft-ietf-rtgwg-net2cloud-problem-statement-10] (21 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 Management [draft-ietf-rtgwg-policy-model-09] (37 pages) - YANG Model for QoS [draft-ietf-rtgwg-qos-model-01] (90 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-03] (25 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-00] (16 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-00] (27 pages) - YANG Data Model for Key Chains [draft-ietf-rtgwg-yang-key-chain-24] (25 pages) - RIB YANG Data Model [draft-ietf-rtgwg-yang-rib-extend-03] (21 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) Relay User Machine (rum) ------------------------ Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Brian Rosen Paul Kyzivat Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: rum@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/rum Archive: https://mailarchive.ietf.org/arch/browse/rum/ Description of Working Group: Many current instances of Video Relay Service (VRS), sometimes called Video Interpretation Service, use the Session Initiation Protocol (SIP) and other IETF multimedia protocols. VRS is used by deaf/hard-of-hearing persons and by persons with speech impairments to communicate with hearing persons. The deaf, hard-of-hearing, or speech-impaired person (D-HOH-SI) uses a SIP-based video phone to connect with an interpreter, and the interpreter places a phone call to the hearing person. The hearing person can also reach D-HOH-SI individuals in the same manner as calling any hearing user. The D-HOH-SI person uses sign language and possibly real-time text with the interpreter and the interpreter uses spoken language with the hearing person, providing on-line, real-time, two-way communication. Having a standard interface between the end-user device and the VRS provider allows vendors and open-source developers to build devices that work with multiple service providers; devices can also be retained when changing providers. In this instance, “device” could be a purpose-built videophone or could be downloadable software on a general purpose computing platform or mobile phone. To ensure interoperability of the key features of this service, certain aspects (e.g., codecs, media transport, addressing and SIP features) must be specified as mandatory-to-implement for SIP-based VRS devices. These specified features effectively form a profile for SIP and the media it negotiates. This working group will produce a single document: a profile of SIP and media features for use with video relay services (which includes video, real time text, and audio), and other similar interpretation services that require multimedia. It will reference the IETF’s current thinking on multimedia communication, including references to work beyond SIP (e.g., WebRTC and SLIM). The profile will require best-practice security mechanisms for SIP-based end devices. The working group will consider issues related to authentication of the parties involved in the video relay call. No protocol changes are anticipated by this work. Often, the hearing user is on the PSTN, and RUM will include interoperability specifications for that use, including the use of telephone numbers. RUM will not assume hearing users are on the PSTN. While WebRTC could be used to implement a profile to fulfill RUM's requirements, the group’s work will focus on the device-to-provider interface. The working group will consider ways for WebRTC based services to interwork with a RUM-compliant provider, but is not required to make such interwork possible. RUM devices will be expected to be able to place emergency calls conforming to the current IETF emergency call recommendations. The scope of the work includes mechanisms to provision the user’s device with common features such as speed dial lists, provider to contact, videomail service interface point and similar items. These features allow users to more easily switch providers temporarily (a feature known as “dial around”) or permanently, while retaining their data. Devices used in VRS can be used to place point-to-point calls where both communicating parties use sign language. When used for point-to-point calling where the participants are not served by the same VRS provider, or when one provider provides the originating multimedia transport environment, but another provides the interpreter (“dial-around call”), the call traverses two providers. Both of these uses impose additional requirements on a RUM device and are in scope for this work. Although the interface between providers also requires standardization to enable multi-provider point-to-point and dial-around calls, that interface has already been defined in a SIP Forum document and is thus out of scope for RUM. Goals and Milestones: Dec 2019 - Submit a profile of SIP and media features for use with video relay services to the IESG for publication Internet-Drafts: - Interoperability Profile for Relay User Equipment [draft-ietf-rum-rue-02] (28 pages) No Requests for Comments Security Automation and Continuous Monitoring (sacm) ---------------------------------------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Christopher Inacio Karen O'Donoghue Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Roman Danyliw Mailing Lists: General Discussion: sacm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sacm Archive: https://mailarchive.ietf.org/arch/browse/sacm/ Description of Working Group: Securing information and the systems that store, process, and transmit that information is a challenging task for enterprises of all sizes, and many security practitioners spend much of their time on manual processes. Standardized protocols and models aiding collection and evaluation of endpoint elements enable automation, thus freeing practitioners to focus on high priority tasks. Due to the breadth of this work, the working group will address enterprise use cases pertaining to the assessment of endpoint posture (using the definitions of Endpoint and Posture from RFC 5209). In alignment with RFC 5209, a network device is an endpoint. Posture assessment entails the following five steps which the working will create solutions to automate: 1. Identify and characterize target endpoints 2. Determine specific endpoint elements to assess 3. Collect and make available specified elements' actual values 4. Compare actual element values to policy compliant element values 5. Make results available This working group will focus on collection, evaluation, and orchestration and communication, as described herein. A. Collection. The WG will define a standardized way to provide two types of guidance to collectors over varying collection mechanisms: 1) Which target endpoints to collect from, and 2) What elements to collect from these target endpoints. A set of instructions (such as vulnerability description data, YANG filter expressions, Windows Management Instrumentation classes, etc.) can be brokered to the appropriate collectors using the control plane functions defined by "C. Orchestration and Communication" (below). Element collection from different sources may require orchestrating functions that go beyond the set of capabilities a collector can provide. This will inform the requirements and characteristics for "C. Orchestration and Communication". The working group recognizes that manual configuration of targets and corresponding collection profiles will not scale and does not seem to be a viable option. B. Evaluation. The working group will standardize a criteria language enabling evaluation of actual endpoint posture information against desired endpoint posture information to produce a standardized result. This extensible language will support complex Boolean statements, comparison operators, logical flow statements, and functions for string manipulation. Additionally, the working group will seek to discover an approach that allows data from any posture collection mechanism to be generically evaluated. C. Orchestration and Communication. The working group will define a set of control plane functions to enable the orchestration between element collectors. These element collectors can then provide the requisite elements sought by posture collectors, posture evaluators, and data repositories. Specific work items may include the following: - Define a way to provide three types of guidance to the correct SACM collectors: 1) Which target endpoints to collect from and 2) what to collect from these target endpoints, and 3) how quickly after an attribute change information must be collected. When applied, a set of instructions, such as vulnerability description data or YANG expressions, can be brokered to the appropriate collectors. - Define an extension of IETF NEA [https://ietf.org/wg/concluded/nea.html] to collect and deliver information about firmware, operating systems, and software installed on an endpoint. - Describe a criteria language capable of being evaluated against endpoint posture information to produce a standardized result. The language will support complex Boolean statements, comparison operators, and functions for string manipulation; and will be extensible enough to be applicable to the full range of collected posture attributes. Additionally, this document will describe an approach that allows data from any posture collection mechanism to be evaluated. - Define a control plane function to enable the discovery and orchestration between devices that can provide the requisite information sought by posture collectors, posture evaluators or both. For example, XMPP capable host/endpoint interactions may be defined through XMPP control plane and data transfer protocol extensions. Likewise, the asynchronous push of selected attributes on switches and routers may be framed using YANG Push for periodic and on-change triggers. - Define a method of expressing software metadata that is suitable for use by constrained devices including a CBOR-based format derived from the ISO/IEC 19770-2 Software Identification (SWID) tag standard. - Define best practices for the collection of posture information from endpoints and its delivery to a collector, from which it can be distributed using the SACM messaging standards. - Extend existing standards for information exchange to support the sharing of software, configuration information, and other forms of guidance including extensions to the Resource-Oriented Lightweight Information Exchange (ROLIE). - Describe a SACM Information Model and a SACM Architecture including protocol requirements and their associated use cases as well as a description of how SACM protocols fit together into a system. Goals and Milestones: Jan 2018 - WGLC ROLIE configuration checklist information type Mar 2018 - Submit ROLIE configuration checklist information type to IESG May 2018 - Initial Draft on ECP over transfer mechanism May 2018 - Initial Draft on YANG-push over transfer mechanism Aug 2019 - Submit ROLIE software descriptor to IESG Aug 2019 - Submit CoSWID to IESG Feb 2020 - WGLC SACM Architecture Done - Submit SWIMA to IESG Done - Initial Draft on SACM Architecture Done - WGLC ROLIE software descriptor Done - WGLC Endpoint Compliance Profile Done - WGLC CoSWID Internet-Drafts: - Definition of the ROLIE Software Descriptor Extension [draft-banghart-sacm-rolie-softwaredescriptor-01] (10 pages) - Concise Software Identifiers [draft-birkholz-sacm-coswid-01] (13 pages) - Software Inventory Message and Attributes (SWIMA) for PA-TNC [draft-coffin-sacm-nea-swid-patnc-03] (85 pages) - SACM Vulnerability Assessment Scenario [draft-coffin-sacm-vuln-scenario-01] (29 pages) - Endpoint Compliance Profile [draft-haynes-sacm-ecp-02] (36 pages) - Security Automation and Continuous Monitoring (SACM) Architecture [draft-ietf-sacm-arch-06] (31 pages) - Secure Automation and Continuous Monitoring (SACM) Architecture [draft-ietf-sacm-architecture-05] (20 pages) - Concise Software Identification Tags [draft-ietf-sacm-coswid-15] (72 pages) - Endpoint Posture Collection Profile [draft-ietf-sacm-ecp-05] (41 pages) - Endpoint Posture Collection Profile [draft-ietf-sacm-epcp-01] (41 pages) - Endpoint Compliance Standard [draft-ietf-sacm-fitzgeraldmckay-endpointcompliance-00] (6 pages) - SACM Information Model [draft-ietf-sacm-information-model-10] (158 pages) - Software Inventory Message and Attributes (SWIMA) for PA-TNC [draft-ietf-sacm-nea-swid-patnc-01] (91 pages) - Software Inventory Message and Attributes (SWIMA) for PA-TNC [draft-ietf-sacm-nea-swima-patnc-05] (101 pages) - Security Automation and Continuous Monitoring (SACM) Requirements [draft-ietf-sacm-requirements-18] (20 pages) - Definition of the ROLIE Software Descriptor Extension [draft-ietf-sacm-rolie-softwaredescriptor-08] (13 pages) - Security Automation and Continuous Monitoring (SACM) Terminology [draft-ietf-sacm-terminology-16] (30 pages) - Endpoint Security Posture Assessment: Enterprise Use Cases [draft-ietf-sacm-use-cases-10] (23 pages) - SACM Vulnerability Assessment Scenario [draft-ietf-sacm-vuln-scenario-02] (24 pages) - Security Automation and Continuous Monitoring (SACM) Architecture [draft-mandm-sacm-architecture-01] (18 pages) - Definition of the ROLIE configuration checklist Extension [draft-mandm-sacm-rolie-configuration-checklist-01] (9 pages) Requests for Comments: RFC7632: Endpoint Security Posture Assessment: Enterprise Use Cases (23 pages) RFC8248: Security Automation and Continuous Monitoring (SACM) Requirements (20 pages) RFC8412: Software Inventory Message and Attributes (SWIMA) for PA-TNC (101 pages) Security Dispatch (secdispatch) ------------------------------- Charter Last Modified: 2020-02-20 Current Status: Active Chairs: Francesca Palombini Kathleen Moriarty Richard Barnes Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Roman Danyliw 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 Security Events (secevent) -------------------------- Charter Last Modified: 2018-03-21 Current Status: Active Chairs: Dick Hardt Yaron Sheffer Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Benjamin Kaduk Mailing Lists: General Discussion: id-event@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/id-event Archive: https://mailarchive.ietf.org/arch/browse/id-event/ Description of Working Group: Many HTTP web services and APIs depend on a web security infrastructure that: * identifies security subjects and regulates their access to services * and provides profile and rights information to applications. Examples are systems that leverage user-agent session cookies (RFC6265), and OAuth2 (RFC6749). In order to prevent or mitigate security risks, or to provide out-of-band information as necessary, these systems need to share security event messages. For example, an OAuth authorization server, having received a token revocation request (RFC7009) may need to inform affected resource servers; a cloud provider may wish to inform another cloud provider of suspected fraudulent use of identity information; an identity provider may wish to signal a session logout to a relying party and does not wish to rely solely upon clearing a session cookie. It is expected that several identity and security working groups and organizations will use Identity Event Tokens to describe area-specific events such as: SCIM Provisioning Events, OpenID RISC Events, and OpenID Connect Backchannel Logout, among others. The Security Events working group will produce a standards-track Event Token specification that includes: - A JWT extension for expressing security events - A syntax that enables event-specific data to be conveyed This Event Token specification will be event transport independent. The working group will also develop a simple standards-track Event Delivery specification that includes: - A mechanism for delivering events using HTTP POST (push) - Metadata for describing event feeds - Methods for subscribing to and managing event feeds - Methods for validating event feed subscriptions Goals and Milestones: Nov 2017 - WG last call of event delivery draft Jan 2018 - Event delivery draft to IESG as a Proposed Standard Mar 2018 - Recharter or Conclude Done - Initial adoption of event token and event delivery drafts Done - WG last call of event token draft Done - Event token draft to IESG as a Proposed Standard Internet-Drafts: - SET Token Distribution and Subscription Management Profile [draft-hunt-idevent-distribution-01] (30 pages) - Security Event Token (SET) [draft-hunt-idevent-token-08] (18 pages) - SET Token Delivery Using HTTP [draft-ietf-secevent-delivery-02] (26 pages) - Poll-Based Security Event Token (SET) Delivery Using HTTP [draft-ietf-secevent-http-poll-09] (20 pages) - Push-Based Security Event Token (SET) Delivery Using HTTP [draft-ietf-secevent-http-push-10] (21 pages) - Security Event Token (SET) [draft-ietf-secevent-token-13] (28 pages) Requests for Comments: RFC8417: Security Event Token (SET) (28 pages) Service Function Chaining (sfc) ------------------------------- Charter Last Modified: 2018-03-21 Current Status: Active Chairs: Jim Guichard Joel M. Halpern Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Martin Vigoureux Secretary: Tal Mizrahi Mailing Lists: General Discussion: sfc@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sfc Archive: https://mailarchive.ietf.org/arch/browse/sfc/ Description of Working Group: Network operators frequently utilize service functions such as packet filtering at firewalls, load-balancing and transactional proxies (for example spam filters) in the delivery of services to end users. Delivery of these types of services is undergoing significant change with the introduction of virtualization, network overlays, and orchestration. The SFC Working Group has developed an Architecture [RFC 7665] and the Network Service Header [RFC 8300] for service function chaining. The focus of the SFC working group moving forward is on aspects of the architecture and/or protocol that need to be addressed to enable effective deployment and usage of this work. In order to maintain focus, the working group primarily produces and advances documents on four topics: 1) Metadata - Define the common type-length-value encoded metadata types with Standards Track RFCs, and produce Informational RFCs to describe common fixed-length (MD-1) metadata usages. 2) Security and Privacy - Mechanisms and guidance for securing metadata via authentication, integrity protection, confidentiality, and/or data minimization are not yet defined. What can be effectively provided, for which scenarios, and how those tools can be provided need to be determined and the tools standardized. 3) OAM and Operations & Management - In order for operators to use these tools in production networks, they need Operations, Administration, and Maintenance tools, as well as management mechanisms. This includes YANG models, OAM frameworks, and specific OAM mechanisms to address operational needs. 4) Transport Considerations - This will capture the expectations SFC places on transport behavior, including dealing with issues such as congestion indications and responses. This should define how NSH works on standardized transports that are expected to see widespread use. Specifically, the SFC WG is chartered to deliver the following: 1. A Standards Track base set of the metadata MD-2 type codes within the metadata class reserved for IETF usage, as specified in RFC 8300. 2. Related Metadata drafts that require more explanation than is reasonable to include in the base MD-2 draft, including MD-1 descriptions and items done once the base draft is complete. 3. YANG models for the management of SFC Components. 4. One or more security related Standards Track and / or Informational RFCs. At least one Standards Track security mechanism RFC is needed. 5. OAM Framework document to provide a common basis for OAM work. This draft will include guidance on how active, passive, and hybrid OAM are to be supported if at all. 6. Specific OAM mechanism documents to provide the tools needed for operational environments. 7. Transport Considerations RFC to cover the expectations SFC and NSH place on transport, and the operational constraints transports used by NSH need to meet. The SFC WG may work on Informational applicability documents that show how the technology, meta-data, and associated control-plane mechanisms can be used in specific use-cases. The SFC WG may work on Informational documents that provide operational considerations. The SFC WG will coordinate with BESS and PCE on the control-plane work related to SFC. Goals and Milestones: Apr 2014 - Consult with OPS area on possible SFC charter modifications for management and configuration of SFC components related to the support of Service Function Chaining Oct 2018 - Informational document defining the Operation, Administration and Maintenance (OAM) framework for SFC Dec 2018 - Submit to IESG Informational documents specifying the format of MD-type 1 metadata in DC and Broadband environments Dec 2018 - Submit to IESG Standards Track document specifying MD-type 2 metadata formats Mar 2019 - YANG models for SFF and classifier Jul 2019 - Submit to IESG Informational document defining authentication, integrity protection, and confidentiality of SFC metadata Jul 2019 - Informational document defining transport considerations applicable to SFC Internet-Drafts: - Proof of Transit [draft-brockners-proof-of-transit-05] (23 pages) - NSH Encapsulation for In-situ OAM Data [draft-brockners-sfc-ioam-nsh-01] (9 pages) - Explicit Congestion Notification (ECN) and Congestion Feedback Using the Network Service Header (NSH) [draft-eastlake-sfc-nsh-ecn-support-03] (21 pages) - Operating the Network Service Header (NSH) with Next Protocol "None" [draft-farrel-sfc-convent-06] (12 pages) - Network Service Header (NSH) MD Type 1: Context Header Allocation (Data Center) [draft-guichard-sfc-nsh-dc-allocation-07] (9 pages) - A Service Chain Aggregation Architecture [draft-ietf-sfc-aggregation-00] (5 pages) - Service Function Chaining (SFC) Architecture [draft-ietf-sfc-architecture-11] (32 pages) - Service Function Chaining (SFC) Control Plane Components & Requirements [draft-ietf-sfc-control-plane-08] (29 pages) - Service Function Chaining Use Cases In Data Centers [draft-ietf-sfc-dc-use-cases-06] (23 pages) - Hierarchical Service Function Chaining (hSFC) [draft-ietf-sfc-hierarchical-11] (29 pages) - Network Service Header (NSH) Encapsulation for In-situ OAM (IOAM) Data [draft-ietf-sfc-ioam-nsh-03] (9 pages) - SFC Long-lived Flow Use Cases [draft-ietf-sfc-long-lived-flow-use-cases-03] (10 pages) - Active OAM for Service Function Chains in Networks [draft-ietf-sfc-multi-layer-oam-04] (18 pages) - Network Service Header (NSH) [draft-ietf-sfc-nsh-28] (40 pages) - NSH Context Header Allocation for Broadband [draft-ietf-sfc-nsh-broadband-allocation-01] (9 pages) - Network Service Header (NSH) MD Type 1: Context Header Allocation (Data Center) [draft-ietf-sfc-nsh-dc-allocation-02] (8 pages) - Explicit Congestion Notification (ECN) and Congestion Feedback Using the Network Service Header (NSH) [draft-ietf-sfc-nsh-ecn-support-02] (21 pages) - Network Service Header TLVs [draft-ietf-sfc-nsh-tlv-02] (11 pages) - Service Function Chaining (SFC) Operations, Administration and Maintenance (OAM) Framework [draft-ietf-sfc-oam-framework-13] (21 pages) - Service Function Simple Offloads [draft-ietf-sfc-offloads-00] (17 pages) - Problem Statement for Service Function Chaining [draft-ietf-sfc-problem-statement-13] (13 pages) - Proof of Transit [draft-ietf-sfc-proof-of-transit-04] (29 pages) - Service Function Chaining: Subscriber and Performance Policy Identification Variable-Length Network Service Header (NSH) Context Headers [draft-ietf-sfc-serviceid-header-07] (10 pages) - Service Function Chaining Use Cases in Mobile Networks [draft-ietf-sfc-use-case-mobility-09] (26 pages) - Performance Measurement (PM) with Alternate Marking Method in Service Function Chaining (SFC) Domain [draft-mirsky-sfc-pmamm-09] (8 pages) - NSH Context Header Allocation -- Broadband [draft-napper-sfc-nsh-broadband-allocation-04] (9 pages) - Network Service Header TLVs [draft-quinn-sfc-nsh-tlv-04] (8 pages) - Service Function Chaining: Subscriber and Service Identification Use Cases and Variable-Length NSH Context Headers [draft-sarikaya-sfc-hostid-serviceheader-07] (15 pages) - Service Function Chaining: Subscriber and Policy Identification Variable-Length Network Service Header (NSH) Context Headers [draft-sfc-serviceid-header-02] (9 pages) - Active OAM for Service Function Chains in Networks [draft-wang-sfc-multi-layer-oam-12] (15 pages) Requests for Comments: RFC7498: Problem Statement for Service Function Chaining (13 pages) RFC7665: Service Function Chaining (SFC) Architecture (32 pages) RFC8300: Network Service Header (NSH) (40 pages) RFC8393: Operating the Network Service Header (NSH) with Next Protocol "None" (12 pages) RFC8459: Hierarchical Service Function Chaining (hSFC) (29 pages) SIDR Operations (sidrops) ------------------------- Charter Last Modified: 2019-12-06 Current Status: Active Chairs: Chris Morrow Keyur Patel Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Warren Kumari Secretary: Nathalie Trenaman 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) - 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) - The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2 [draft-ietf-sidrops-8210bis-00] (37 pages) - A Profile for Autonomous System Provider Authorization [draft-ietf-sidrops-aspa-profile-02] (9 pages) - Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization [draft-ietf-sidrops-aspa-verification-04] (12 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) - 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) - Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI) [draft-ietf-sidrops-ov-clarify-05] (5 pages) - BGP RPKI-Based Origin Validation on Export [draft-ietf-sidrops-ov-egress-04] (5 pages) - Signaling Prefix Origin Validation Results from a Route Server to Peers [draft-ietf-sidrops-route-server-rpki-light-02] (7 pages) - Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties [draft-ietf-sidrops-rp-06] (12 pages) - RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation [draft-ietf-sidrops-rpki-tree-validation-03] (17 pages) - The Use of Maxlength in the RPKI [draft-ietf-sidrops-rpkimaxlen-04] (12 pages) - Router Keying for BGPsec [draft-ietf-sidrops-rtr-keying-06] (21 pages) - RPKI Signed Object for Trust Anchor Keys [draft-ietf-sidrops-signed-tal-05] (16 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) - BGPsec Validation State Signaling [draft-sidrops-bgpsec-validation-signaling-01] (8 pages) Requests for Comments: BCP224: BGPsec Router Certificate Rollover (11 pages) RFC8481: Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI) (5 pages) 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) SIP Best-practice Recommendations Against Network Dangers to privacY (sipbrandy) -------------------------------------------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Gonzalo Camarillo Gonzalo Salgueiro Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: sipbrandy@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sipbrandy Archive: https://mailarchive.ietf.org/arch/browse/sipbrandy/ Description of Working Group: SIP with the SDP Offer/Answer model, along with RTP are widely used in modern communications networks. But while secure RTP (SRTP) is available to provide integrity and privacy protection to such communication, it is rarely used end-to-end. This lack is due to several factors, notably the pervasive use of signaling and media intermediaries in such networks and the difficulties involved in deployment of strong identity mechanisms for SIP. These factors are complicated by the fact that there are several incompatible approaches to SRTP key exchange. The current situation is unacceptable in the face of pervasive monitoring, which RFC 7258 describes as "an attack on privacy". In addition, the STIR working group is, at the time of this writing, revising RFC 4744 to make strong identity attestations for SIP easier to deploy. This gives the IETF an opportunity to define best practices to improve privacy protections for users of SIP based communication, in ways that improve upon the status-quo. Objectives: The SIPBRANDY working group will define best practices for establishing two-party, SIP-signaled SRTP sessions with end-to-end security associations, including a single, preferred SRTP key exchange mechanism. These practices are expected to be deployable across typical SIP networks, without the sharing of SRTP keying material with intermediaries or third parties. These practices should protect against man-in-the-middle attacks. While confidentiality is the first priority of the working group, it may work on aligning these practices with WebRTC, for example by defining best practices for ensuring recipients of media flows have indicated the desire to receive them, in order to prevent or mitigate the denial-of- service attack described in RFC 5245, section 18.5.1. Likewise, the WG may consider compatibility with aspects of PERC. The working group will additionally coordinate with the MMUSIC working group to define opportunistic security [RFC 7435] for SIP-signaled media sessions for situations where strong protections are not necessary or not feasible. Non-Goals: The working group is not expected to define practices for multi-party session topologies, especially those involving media distribution devices. The working group is not expected to define new protocols or modify existing ones; rather it will define practices for using existing protocols. If the working group discovers gaps that require creation or modification protocols, it will forward those gaps to the appropriate working groups. Inputs and Collaboration: The WG will consider draft-peterson-dispatch-rtpsec and draft-johnston-dispatch-osrtp as input to the work. The WG is expected to collaborate closely with SIPCORE, AVTCORE, STIR, MMUSIC, RTCWEB, PERC, and possibly DISPATCH. Goals and Milestones: Mar 2019 - Submit Opportunistic SRTP draft to IESG for consideration as BCP Done - Draft Adoption - Best Practices for end-to-end SRTP Done - Draft Adoption - Best Practices for Opportunistic SRTP Done - Inform MMUSIC or other appropriate WGs of any changes needed to support Opportunistic SRTP (Not expected to be published as an RFC) Done - Submit End-to-End SRTP draft to the IESG for consideration as BCP Internet-Drafts: - An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP) [draft-ietf-sipbrandy-osrtp-10] (8 pages) - Best Practices for Securing RTP Media Signaled with SIP [draft-ietf-sipbrandy-rtpsec-08] (14 pages) Requests for Comments: RFC8643: An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP) (8 pages) Session Initiation Protocol Core (sipcore) ------------------------------------------ Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Brian Rosen Jean Mahoney Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba 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 Done - INFO package framework to IESG (PS) Done - Termination of early dialog prior to final response to IESG (PS) Done - Invite Transaction Handling Correction to IESG (PS) Done - Extension for use in etags in conditional notification to IESG (PS) Done - SIP Events throttling mechanism to IESG (PS) Done - Presence Scaling Requirements to IESG as Info Done - Mechanism for indicating support for keep-alives (PS) Done - Example security flows to IESG (Informational) Done - Location Conveyance with SIP to IESG (PS) Done - Error corrections and clarifications to RFC3265 to IESG (PS) 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 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) - 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-02] (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) - 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] (17 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 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) Source Packet Routing in Networking (spring) -------------------------------------------- Charter Last Modified: 2019-11-08 Current Status: Active Chairs: Bruno Decraene Rob Shakir Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Martin Vigoureux 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 2018 - SR-MPLS configuration YANG model sent to IESG Jul 2019 - SR-TE policy sent to IESG Jul 2019 - SR-MPLS OAM sent to IESG Jul 2019 - SR-MPLS Performance Measurement to IESG Jul 2019 - SR-IPv6 OAM sent to IESG Dec 2019 - SRv6 Network Programming to IESG Dec 2019 - SR policies YANG model sent to IESG Dec 2019 - Stateless service chaining with SR sent to IESG Done - SR-MPLS sent to IESG Internet-Drafts: - 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) - 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) - Segment Routing MPLS Conflict Resolution [draft-ietf-spring-conflict-resolution-05] (22 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 in MPLS Based Segment Routing Network [draft-ietf-spring-mpls-path-segment-02] (13 pages) - Network Service Header (NSH) and Segment Routing Integration for Service Function Chaining (SFC) [draft-ietf-spring-nsh-sr-02] (17 pages) - A Scalable and Topology-Aware MPLS Data-Plane Monitoring System [draft-ietf-spring-oam-usecase-10] (19 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) - 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] (19 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-07] (35 pages) - OAM Requirements for Segment Routing Network [draft-ietf-spring-sr-oam-requirement-03] (7 pages) - Service Programming with Segment Routing [draft-ietf-spring-sr-service-programming-02] (39 pages) - YANG Data Model for Segment Routing [draft-ietf-spring-sr-yang-15] (30 pages) - SRv6 Network Programming [draft-ietf-spring-srv6-network-programming-15] (39 pages) - OAM Requirements for Segment Routing Network [draft-kumar-spring-sr-oam-requirement-03] (6 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) - 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) - SR Replication Segment for Multi-point Service Delivery [draft-voyer-spring-sr-replication-segment-02] (8 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) 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) Secure Telephone Identity Revisited (stir) ------------------------------------------ Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Robert Sparks Russ Housley Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Murray Kucherawy 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, 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 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 consider a mechanism 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. However, the in-band and the out-of-band mechanisms should share as much in common as possible, especially the credentials. The in-band mechanism must be sent to the IESG for approval and publication prior to the out-of-band mechanism. 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 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 RAI 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. 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. 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. Input to working group discussions shall include: - Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks [RFC 3325] - Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) [RFC 4474] - Secure Call Origin Identification [draft-cooper-iab-secure-origin-00] - Secure Origin Identification: Problem Statement, Requirements, and Roadmap [draft-peterson-secure-origin-ps-00] - Authenticated Identity Management in the Session Initiation Protocol (SIP) [draft-jennings-dispatch-rfc4474bis-00] The working group will deliver the following: - A problem statement detailing the deployment environment and situations that motivate work on secure telephone identity - A threat model for the secure telephone identity mechanisms - A privacy analysis of the secure telephone identity mechanisms - A document describing the SIP in-band mechanism for telephone number-based identities during call setup - A document describing the credentials required to support telephone number identity authentication - A document describing the out-of-band mechanism for telephone number-based identities during call setup Goals and Milestones: Nov 2019 - Submit PASSPorT Extension for rich call data for publication as Proposed Standard - Submit Assertion Values for a Resource Priority Header Claim in Support of Emergency Services Networks as Proposed Standard - Submit STIR Certificate Delegation as Proposed Standard Mar 2020 - Submit Privacy analysis for Informational Done - Submit problem statement for Informational Done - Submit threat model for Informational Done - Submit in-band mechanism for Proposed Standard Done - Submit credential specification for Proposed Standard Done - Submit PASSporT Extension for Resource Priority Authorization for publication as Proposed Standard Done - Submit PASSPorT SHAKEN extension for publication as Proposed Standard Done - Submit PASSPorT extension for diverted calls as Proposed Standard Done - Submit out-of-band architecture and use-cases for Informational 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) - STIR Certificate Delegation [draft-ietf-stir-cert-delegation-02] (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-00] (12 pages) - STIR Out-of-Band Architecture and Use Cases [draft-ietf-stir-oob-07] (28 pages) - PASSporT: Personal Assertion Token [draft-ietf-stir-passport-11] (25 pages) - PASSporT Extension for Diverted Calls [draft-ietf-stir-passport-divert-08] (18 pages) - PASSporT Extension for Rich Call Data [draft-ietf-stir-passport-rcd-06] (21 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) - Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization [draft-ietf-stir-rph-06] (10 pages) - Assertion Values for a Resource Priority Header Claim in Support of Emergency Services Networks [draft-ietf-stir-rph-emergency-services-01] (6 pages) - Secure Telephone Identity Threat Model [draft-ietf-stir-threats-04] (13 pages) - STIR Certificate Delegation [draft-peterson-stir-cert-delegation-00] (9 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) RFC8225: PASSporT: Personal Assertion Token (25 pages) RFC8226: Secure Telephone Identity Credentials: Certificates (24 pages) 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) Software Updates for Internet of Things (suit) ---------------------------------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Dave Thaler David Waltermire Russ Housley Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Roman Danyliw Mailing Lists: General Discussion: suit@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/suit Archive: https://mailarchive.ietf.org/arch/search/?email_list=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 of 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. This group will focus on defining a firmware update solution (taking into account past learnings from RFC 4108 and other firmware update solutions) that will be 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. This group will not define any new transport or discovery mechanisms, but may describe how to use existing mechanisms within the architecture. In particular this group aims to publish several documents, namely: * An IoT firmware update architecture that includes a description of the involved entities, security threats, and assumptions. * One or more manifest format specifications. To support specification of manifest format(s), this group will first develop the information model for the contents of a manifest. Once there is general agreement on the contents, the group will pick a small number of serialization formats such as CBOR and/or ASN.1 (and their associated cryptographic mechanisms) to encode the manifest. A small number of formats is preferred to reduce the complexity of a firmware management solution, where each IoT device would typically only support one format, but the same tool or service might support all such formats. 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. This group does not aim to create a standard for a generic application software update mechanism, but instead this group will focus on firmware development practices in the embedded industry. Software update solutions that target updating software other than the firmware binaries (e.g., applications) are also out of scope. This group will aim to maintain a close relationship with silicon vendors and OEMs that develop IoT operating systems. Goals and Milestones: Nov 2019 - Submit manifest information model to the IESG for publication as Informational. Nov 2019 - Submit architecture to the IESG for publication as Informational Mar 2020 - Submit an initial manifest serialization format to the IESG for publication as a Proposed Standard. Done - Adopt "Architecture" document as WG item. Done - Adopt a manifest information model as a WG item. Done - Calendar item: First interoperability event at IETF 101. Done - Calendar item: Second interoperability event at IETF 102. Done - Adopt initial manifest serialization format(s) as WG item(s). Internet-Drafts: - A Firmware Update Architecture for Internet of Things [draft-ietf-suit-architecture-08] (30 pages) - An Information Model for Firmware Updates in IoT Devices [draft-ietf-suit-information-model-05] (42 pages) - A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest [draft-ietf-suit-manifest-04] (87 pages) - A Firmware Update Architecture for Internet of Things Devices [draft-moran-suit-architecture-03] (30 pages) No Requests for Comments Transport Services (taps) ------------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Aaron Falk Zaheduzzaman Sarker Transport Area Directors: Martin Duke Magnus Westerlund Transport Area Advisor: Magnus Westerlund 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: Mar 2019 - Submit an Informational document defining a set of security-related Transport Services Nov 2019 - 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 Nov 2019 - Recharter or conclude. Done - Submit an Informational document to the IESG recommending a minimal set of Transport Services that end systems should support 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) - An Architecture for Transport Services [draft-ietf-taps-arch-07] (28 pages) - Implementing Interfaces to Transport Services [draft-ietf-taps-impl-06] (51 pages) - An Abstract Application Layer Interface to Transport Services [draft-ietf-taps-interface-06] (69 pages) - A Minimal Set of Transport Services for End Systems [draft-ietf-taps-minset-11] (50 pages) - A Survey of the Interaction Between Security Protocols and Transport Services [draft-ietf-taps-transport-security-12] (23 pages) - Services Provided by IETF Transport Protocols and Congestion Control Mechanisms [draft-ietf-taps-transports-14] (54 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) TCP Maintenance and Minor Extensions (tcpm) ------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Michael Scharf Michael Tüxen Yoshifumi Nishida Transport Area Directors: Martin Duke Magnus Westerlund Transport Area Advisor: Martin Duke 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 the Internet's predominant transport protocol. 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 (as community energy is available for such efforts). * The WG maintains Multipath TCP (MPTCP) and is a home for minor MPTCP enhancements including updates to the existing multipath congestion control. * The focus of the working group is TCP. In cases where small changes are directly applicable to other transports (e.g., SCTP or DCCP), the mappings to other transports may be specified alongside that for TCP, but other significant additions and changes to other transports are not in scope. TCPM also provides a venue for standardization of incremental enhancements of TCP's standard congestion control. In addition, TCPM may document alternative TCP congestion control algorithms that are known to be widely deployed, and that are considered safe for large-scale deployment in the Internet. Changes of algorithms may require additional review by the IRTF Congestion Control Research Group (ICCRG). Fundamental changes to TCP or its congestion control algorithms (e.g., departure from loss-based congestion control) will be handled by other working groups or will require rechartering. TCP's congestion control algorithms are the model followed by other IETF transports (e.g., SCTP or DCCP), which are standardized in other working groups, such as the Transport Area WG (tsvwg). In the past, the IETF has worked on several documents about algorithms that are specified for multiple protocols (e.g., TCP and SCTP) in the same document. Which WG shepherds such documents will be determined on a case-by-case basis. In any case, the TCPM WG will remain in close contact with other relevant WGs working on these protocols to ensure openness and stringent review from all angles. 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: Apr 2020 - Submit document on a time-based fast loss detection algorithm for TCP to the IESG for publication as a Proposed Standard RFC Jun 2020 - Submit RFC793bis document to the IESG for publication as Internet Standard Jul 2020 - Submit document on TCP Control Block Interdependence to the IESG for publication as Informational RFC Aug 2020 - Submit specification of more accurate ECN feedback in TCP to the IESG for publication as an Experimental RFC Sep 2020 - Submit document on adding Explicit Congestion Notification (ECN) to TCP Control Packets to the IESG for publication as Experimental RFC Nov 2020 - Submit document on a TCP Extended Data Offset Option to the IESG as a Proposed Standard RFC Done - Submit document on Retransmission Timeout Considerations as Best Current Practice 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-05] (33 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 ECN Feedback in TCP [draft-ietf-tcpm-accurate-ecn-11] (58 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) - 0-RTT TCP Convert Protocol [draft-ietf-tcpm-converters-19] (52 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-05] (46 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) - RACK: a time-based fast loss detection algorithm for TCP [draft-ietf-tcpm-rack-08] (30 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 Specification [draft-ietf-tcpm-rfc793bis-16] (106 pages) - Requirements for Time-Based Loss Detection [draft-ietf-tcpm-rto-consider-14] (11 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-10] (23 pages) - Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD) [draft-ietf-tcpm-tcp-lcd-03] (23 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) - 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) - TCP Options and Maximum Segment Size (MSS) [draft-ietf-tcpm-tcpmss-05] (9 pages) - Improving TCP's Robustness to Blind In-Window Attacks [draft-ietf-tcpm-tcpsecure-13] (19 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) - 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: BCP159: Reducing the TIME-WAIT State Using TCP Timestamps (10 pages) 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) 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) RFC6069: Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD) (23 pages) RFC6093: On the Implementation of the TCP Urgent Mechanism (12 pages) 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) RFC6528: Defending against Sequence Number Attacks (12 pages) 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) 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) RFC8511: TCP Alternative Backoff with ECN (ABE) (12 pages) Traffic Engineering Architecture and Signaling (teas) ----------------------------------------------------- Charter Last Modified: 2018-07-27 Current Status: Active Chairs: Lou Berger Vishnu Pavan Beeram Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Deborah Brungard Tech Advisor: Adrian Farrel Secretary: Matt Hartley 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) - 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) - 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) - 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) - 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 VN/TE Performance Monitoring Telemetry and Scaling Intent Autonomics [draft-ietf-teas-actn-pm-telemetry-autonomics-02] (29 pages) - Requirements for Abstraction and Control of TE Networks [draft-ietf-teas-actn-requirements-09] (12 pages) - A Yang Data Model for VN Operation [draft-ietf-teas-actn-vn-yang-08] (54 pages) - Applicability of YANG models for Abstraction and Control of Traffic Engineered Networks [draft-ietf-teas-actn-yang-05] (19 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 Enhanced Virtual Private Networks (VPN+) Services [draft-ietf-teas-enhanced-vpn-05] (40 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 System [draft-ietf-teas-gmpls-controller-inter-work-03] (22 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-03] (11 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) - 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) - 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 in Native IP Network [draft-ietf-teas-pce-native-ip-06] (11 pages) - The Use Cases for Path Computation Element (PCE) as a Central Controller (PCECC). [draft-ietf-teas-pcecc-use-cases-05] (34 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-02] (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-05] (43 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 Model [draft-ietf-teas-te-service-mapping-yang-03] (41 pages) - TE Topology and Tunnel Modeling for Transport Networks [draft-ietf-teas-te-topo-and-tunnel-modeling-05] (109 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-07] (67 pages) - Yang model for requesting Path Computation [draft-ietf-teas-yang-path-computation-08] (78 pages) - A YANG Data Model for Resource Reservation Protocol (RSVP) [draft-ietf-teas-yang-rsvp-12] (50 pages) - A YANG Data Model for RSVP-TE Protocol [draft-ietf-teas-yang-rsvp-te-08] (47 pages) - YANG Data Model for SR and SR TE Topologies [draft-ietf-teas-yang-sr-te-topo-06] (31 pages) - A YANG Data Model for Traffic Engineering Tunnels and Interfaces [draft-ietf-teas-yang-te-23] (115 pages) - A YANG Data Model for MPLS Traffic Engineering Tunnels [draft-ietf-teas-yang-te-mpls-03] (21 pages) - YANG Data Model for Traffic Engineering (TE) Topologies [draft-ietf-teas-yang-te-topo-22] (211 pages) - Traffic Engineering Common YANG Types [draft-ietf-teas-yang-te-types-13] (86 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) - 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) - 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) - 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: BCP206: Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks (67 pages) 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) Trusted Execution Environment Provisioning (teep) ------------------------------------------------- Charter Last Modified: 2019-11-18 Current Status: Active Chairs: Nancy Cam-Winget Tirumaleswar Reddy.K Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Benjamin Kaduk 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: Dec 2019 - Begin WGLC for Architecture document Apr 2020 - Progress Architecture document to the IESG for publication Jul 2020 - Begin WGLC for Solution document Dec 2020 - Progress Solution document to the IESG for publication Done - Adopt an Architecture document Done - Adopt a solution document Internet-Drafts: - Trusted Execution Environment Provisioning (TEEP) Architecture [draft-ietf-teep-architecture-08] (29 pages) - The Open Trust Protocol (OTrP) [draft-ietf-teep-opentrustprotocol-03] (111 pages) - HTTP Transport for Trusted Execution Environment Provisioning: Agent-to- TAM Communication [draft-ietf-teep-otrp-over-http-06] (14 pages) - Trusted Execution Environment Provisioning (TEEP) Protocol [draft-ietf-teep-protocol-02] (25 pages) - Trusted Execution Environment Provisioning Protocol (teep-p) [draft-tschofenig-teep-protocol-01] (20 pages) No Requests for Comments Timing over IP Connection and Transfer of Clock (tictoc) -------------------------------------------------------- Charter Last Modified: 2020-03-25 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-16] (13 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: 2019-03-03 Current Status: Active Chairs: Christopher A. Wood Joseph A. Salowey Sean Turner Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Benjamin Kaduk 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 [RFC5346], 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: Jul 2020 - Submit "Deprecating MD5 and SHA-1 signature hashes in TLS 1.2" to the IESG Sep 2020 - Submit "Delegated Credentials for TLS" to the IESG Nov 2020 - Submit "TLS Ticket Requests" to the IESG Nov 2020 - Submit "A Flags Extension for TLS 1.3" to the IESG Jan 2021 - Submit "Importing External PSKs for TLS" to the IESG Mar 2021 - Submit "Encrypted Server Name Indication for TLS 1.3" to the IESG Mar 2021 - Submit "Batch Signing for TLS" to the IESG Jul 2021 - Submit "Semi-Static Diffie-Hellman Key Establishment for TLS 1.3" to the IESG Jul 2021 - Submit "Compact TLS 1.3" to the IESG Nov 2021 - Submit "Hybrid key exchange in TLS 1.3" to the IESG Internet-Drafts: - Transport Layer Security (TLS) False Start [draft-bmoeller-tls-falsestart-01] (11 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) - Transport Layer Security (TLS) Certificate Compression [draft-ghedini-tls-certificate-compression-00] (6 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) - 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) - 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) - Compact TLS 1.3 [draft-ietf-tls-ctls-00] (17 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) - 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) - Connection Identifiers for DTLS 1.2 [draft-ietf-tls-dtls-connection-id-07] (16 pages) - Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension [draft-ietf-tls-dtls-heartbeat-04] (9 pages) - The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 [draft-ietf-tls-dtls13-37] (53 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) - 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) - Encrypted Server Name Indication for TLS 1.3 [draft-ietf-tls-esni-06] (27 pages) - Exported Authenticators in TLS [draft-ietf-tls-exported-authenticator-12] (14 pages) - Transport Layer Security (TLS) Extensions [draft-ietf-tls-extensions-06] (29 pages) - Importing External PSKs for TLS [draft-ietf-tls-external-psk-importer-04] (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) - Upgrading to TLS Within HTTP/1.1 [draft-ietf-tls-http-upgrade-05] (13 pages) - HTTP Over TLS [draft-ietf-tls-https-03] (7 pages) - Hybrid key exchange in TLS 1.3 [draft-ietf-tls-hybrid-design-00] (34 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) - Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 [draft-ietf-tls-md5-sha1-deprecate-03] (6 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 TLSv1.0 and TLSv1.1 [draft-ietf-tls-oldversions-deprecate-06] (22 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) - 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 SNI Encryption in TLS [draft-ietf-tls-sni-encryption-09] (14 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) - Modifications to the SSL protocol for TLS [draft-ietf-tls-ssl-mods-00] (4 pages) - The SSL Protocol Version 3.0 [draft-ietf-tls-ssl-version3-00] (63 pages) - Prohibiting Secure Sockets Layer (SSL) Version 2.0 [draft-ietf-tls-ssl2-must-not-04] (4 pages) - Deprecating Secure Sockets Layer Version 3.0 [draft-ietf-tls-sslv3-diediedie-03] (7 pages) - Delegated Credentials for TLS [draft-ietf-tls-subcerts-07] (16 pages) - Suite B Cipher Suites for TLS [draft-ietf-tls-suiteb-00] (8 pages) - TLS Ticket Requests [draft-ietf-tls-ticketrequests-05] (8 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) - 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-02] (8 pages) - Wireless Extensions to TLS [draft-ietf-tls-wireless-00] (13 pages) - Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 [draft-lvelvindron-tls-md5-sha1-deprecate-05] (5 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) Connection Identifier [draft-rescorla-tls-dtls-connection-id-02] (12 pages) - The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 [draft-rescorla-tls-dtls13-01] (36 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) - 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) - Record Size Limit Extension for Transport Layer Security (TLS) [draft-thomson-tls-record-limit-00] (6 pages) - Example Handshake Traces for TLS 1.3 [draft-thomson-tls-tls13-vectors-01] (28 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 RFC7231 * Updates RFC7230 RFC2818: HTTP Over TLS (7 pages) * Updates RFC5785 * Updates RFC7230 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 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) 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) RFC5054: Using the Secure Remote Password (SRP) Protocol for TLS Authentication (24 pages) 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 RFC5288: AES Galois Counter Mode (GCM) Cipher Suites for TLS (8 pages) 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) 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 RFC6176: Prohibiting Secure Sockets Layer (SSL) Version 2.0 (4 pages) RFC6347: Datagram Transport Layer Security Version 1.2 (32 pages) * Updates RFC7507 * Updates RFC7905 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) RFC7507: TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks (8 pages) RFC7568: Deprecating Secure Sockets Layer Version 3.0 (7 pages) 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) 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) RFC8773: TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key (11 pages) Token Binding (tokbind) ----------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chairs: John Bradley Leif Johansson Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Roman Danyliw Mailing Lists: General Discussion: unbearable@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/unbearable Archive: https://mailarchive.ietf.org/arch/browse/unbearable/ Description of Working Group: Web services generate various security tokens (e.g. HTTP cookies, OAuth tokens, etc.) for web applications to access protected resources. Currently these are bearer tokens, i.e. any party in possession of such token gains access to the protected resource. Attackers export bearer tokens from client machines or from compromised network connections, present these bearer tokens to Web services, and impersonate authenticated users. Token Binding enables defense against such attacks by cryptographically binding security tokens to a secret held by the client. The tasks of this working group are as follows: 1. Specify the Token Binding protocol v1.0. 2. Specify the use of the Token Binding protocol in combination with HTTPS. It is a goal of this working group to enable defense against attacks that involve unauthorized replay of security tokens. Other issues associated with the use of security tokens are out of scope. Another goal of this working group is to design the Token Binding protocol such that it would be also useable with application protocols other than HTTPS. Specifying alternative application protocols is not a primary goal. The main design objectives for the Token Binding protocol, in no particular order: 1. Allow applications and services to prevent unauthorized replay of security tokens. 2. Allow strong key protection, e.g. using hardware-bound keys. 3. Support both first-party (server generates a token for later use with this server) and federation (server generates a token for use with another server) scenarios. 4. Preserve user privacy. 5. Make the Token Binding protocol useable in combination with a variety of application protocols. 6. Allow the negotiation of the Token Binding protocol without additional round-trips. 7. Allow the use of multiple cryptographic algorithms, so that a variety of secure hardware modules with different cryptographic capabilities could be used with Token Binding. 8. Propose Token Binding specification that can be implemented in Web browsers (but is not limited to them). E.g. Web browsers require that the same bound security token must be presentable over multiple TLS sessions and connections. The working group will use the following documents as a starting point for its work: - draft-popov-token-binding-00; - draft-balfanz-https-token-binding-00. This WG will collaborate with other IETF WGs, in particular with the TLS, HTTPbis and Oauth WGs and with the W3C webappsec WG. Goals and Milestones: Mar 2015 - WG document for the Token Binding Protocol v1.0. Mar 2015 - WG document for HTTPS Token Binding. May 2015 - TLS extension for Token Binding as WG document Dec 2017 - HTTPS Token Binding to IESG. Dec 2017 - Token Binding Protocol v1.0 to IESG. Internet-Drafts: - Token Binding over HTTP [draft-balfanz-https-token-binding-00] (9 pages) - Token Binding over HTTP [draft-ietf-tokbind-https-18] (25 pages) - Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation [draft-ietf-tokbind-negotiation-14] (8 pages) - The Token Binding Protocol Version 1.0 [draft-ietf-tokbind-protocol-19] (18 pages) - Token Binding for Transport Layer Security (TLS) Version 1.3 Connections [draft-ietf-tokbind-tls13-03] (4 pages) - Token Binding for 0-RTT TLS 1.3 Connections [draft-ietf-tokbind-tls13-0rtt-02] (11 pages) - HTTPS Token Binding with TLS Terminating Reverse Proxies [draft-ietf-tokbind-ttrp-09] (14 pages) - The Token Binding Protocol Version 1.0 [draft-popov-token-binding-00] (13 pages) Requests for Comments: RFC8471: The Token Binding Protocol Version 1.0 (18 pages) RFC8472: Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation (8 pages) RFC8473: Token Binding over HTTP (25 pages) TURN Revised and Modernized (tram) ---------------------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Gonzalo Camarillo Simon Perreault Transport Area Directors: Martin Duke Magnus Westerlund Transport Area Advisor: Magnus Westerlund Mailing Lists: General Discussion: tram@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tram Archive: https://mailarchive.ietf.org/arch/browse/tram/ Description of Working Group: Traversal Using Relays around NAT (TURN) was published as RFC 5766 in April 2010. For a few years, the protocol had seen rather limited deployment. This is largely because its primary use case is as one of the NAT traversal methods of the Interactive Connectivity Establishment (ICE) framework (RFC 5245), and ICE itself was slow to achieve widespread adoption, as other mechanisms were already being used by the VoIP industry. This situation has changed drastically as ICE, and consequently TURN, are mandatory to implement in WebRTC, a set of technologies developed at the IETF and W3C to standardize Real Time Communication on the Web. Together with the arrival of WebRTC, there is a renewed interest in TURN and ICE, as evidenced by recent work updating the ICE framework (still in progress), and standardizing the URIs used to access a STUN (RFC 7064) or TURN (RFC 7065) server. The goal of the TRAM Working Group is to consolidate the various initiatives to update TURN and STUN to make them more suitable for NAT traversal in a variety of environments, whether for realtime media establishment protocols such as the Offer-Answer Session Description Protocol (RFC 3264), XMPP (XEP-0176), RTSP (draft-ietf-mmusic-rtsp-nat), and RTCWeb (draft-ietf-rtcweb-jsep), or for non-realtime protocols such as HIP (RFC 5770) and RELOAD (RFC 6940). The work will include authentication mechanisms, a path MTU discovery mechanism, an IP address mobility solution for TURN, and extensions to TURN and STUN. The Working Group will closely coordinate with the appropriate Working Groups, including ICE, RTCWEB, MMUSIC, and HTTPBIS. In developing upgrades to TURN, the group will consider the passive monitoring risks introduced by the centralization of call traffic through a TURN server. When such risks arise, they will recommend appropriate mitigations. For example, a mechanism for directing traffic to a TURN server other than one configured by the application could be used to direct calls through a TURN server configured to do monitoring. When such a mechanism is used, it is important that the endpoints to the call apply end-to-end encryption and authentication to ensure that they are protected from the TURN server. Goals and Milestones: Nov 2015 - Send new TURN server discovery mechanism for enterprises and ISPs to IESG for publication as Proposed Standard Nov 2015 - Send path characteristic measurement mechanism to IESG for publication as Proposed Standard Nov 2015 - Adopt TURN PMTUD draft Nov 2015 - Adopt TURN IP address mobility draft Jan 2016 - Send STUN-bis draft to IESG for publication as Proposed Standard Jan 2016 - Send TURN-bis draft to IESG for publication as Proposed Standard Mar 2016 - Send new authentication mechanism(s) to IESG for publication as Proposed Standard Mar 2016 - Submit TURN PMTUD draft to IESG Jul 2016 - Submit TURN IP address mobility draft to IESG Internet-Drafts: - Application-Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages [draft-ietf-tram-alpn-08] (5 pages) - Problems with Session Traversal Utilities for NAT (STUN) Long-Term Authentication for Traversal Using Relays around NAT (TURN) [draft-ietf-tram-auth-problems-05] (8 pages) - Measurement of Round Trip Time and Fractional Loss Using STUN [draft-ietf-tram-measurement-rtt-loss-00] (9 pages) - Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN) [draft-ietf-tram-stun-dtls-05] (16 pages) - An Origin Attribute for the STUN Protocol [draft-ietf-tram-stun-origin-06] (13 pages) - Measurement of Round-Trip Time and Fractional Loss Using Session Traversal Utilities for NAT (STUN) [draft-ietf-tram-stun-path-data-05] (10 pages) - Packetization Layer Path MTU Discovery (PLMTUD) For UDP Transports Using Session Traversal Utilities for NAT (STUN) [draft-ietf-tram-stun-pmtud-16] (21 pages) - Session Traversal Utilities for NAT (STUN) [draft-ietf-tram-stunbis-21] (67 pages) - Mobility with Traversal Using Relays around NAT (TURN) [draft-ietf-tram-turn-mobility-09] (13 pages) - Traversal Using Relays around NAT (TURN) Server Auto Discovery [draft-ietf-tram-turn-server-discovery-12] (16 pages) - Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization [draft-ietf-tram-turn-third-party-authz-16] (24 pages) - Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) [draft-ietf-tram-turnbis-29] (79 pages) Requests for Comments: RFC7350: Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN) (16 pages) RFC7376: Problems with Session Traversal Utilities for NAT (STUN) Long-Term Authentication for Traversal Using Relays around NAT (TURN) (8 pages) RFC7443: Application-Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages (5 pages) RFC7635: Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization (24 pages) RFC7982: Measurement of Round-Trip Time and Fractional Loss Using Session Traversal Utilities for NAT (STUN) (10 pages) RFC8016: Mobility with Traversal Using Relays around NAT (TURN) (13 pages) RFC8155: Traversal Using Relays around NAT (TURN) Server Auto Discovery (16 pages) RFC8489: Session Traversal Utilities for NAT (STUN) (67 pages) RFC8656: Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) (79 pages) Public Notary Transparency (trans) ---------------------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Melinda Shore Paul Wouters Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Roman Danyliw Mailing Lists: General Discussion: trans@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/trans Archive: https://mailarchive.ietf.org/arch/browse/trans/ Description of Working Group: Mitigating web site certificate mis-issuance is the initial problem of interest for this working group. Certificate Transparency (CT, RFC6962) allows such mis-issuance to be detected in interesting and useful cases, for example by an auditor acting for the web site, or one acting to check general CA behaviour. The working group will produce a standards-track version of the experimental RFC 6962 for HTTP over TLS, reflecting implementation and deployment experience since that specification was completed. Many Internet protocols for example, SMTPS, IPsec, DNSSEC, OpenPGP and HTTPS, require a mapping between some kind of identifier and some kind of public key. These protocols rely on either ad-hoc mappings, (as in a web of trust), or on authorities (such as CAs) that attest to the mappings. History shows that neither of these mechanisms is entirely satisfactory. Ad-hoc mappings are difficult to discover and maintain, and authorities make mistakes or are subverted. Cryptographically verifiable logs can help to ameliorate these problems by making it possible to discover errors quickly, so that other mechanisms can be applied to rectify them. A cryptographically verifiable log is an append-only log of hashes of more-or-less anything that is structured in such a way as to provide efficiently-accessible, cryptographically-supported evidence of correct log behaviour. For example, RFC 6962 says: "The append-only property of each log is technically achieved using Merkle Trees, which can be used to show that any particular version of the log is a superset of any particular previous version. Likewise, Merkle Trees avoid the need to blindly trust logs: if a log attempts to show different things to different people, this can be efficiently detected by comparing tree roots and consistency proofs. Similarly, other misbehaviors of any log (e.g., issuing signed timestamps for certificates they then don't log) can be efficiently detected and proved to the world at large." These logs can potentially also assist with other interesting problems, such as how to assure end users that software they are running is, indeed, the software they intend to run. While the privacy issues related to use of RFC6962 for public web sites are minimal, the working group will consider privacy as it might impact on uses of CT e.g. within enterprises or for other uses of logs. Work items: - Publish an update to RFC 6962 as a standards-track mechanism to apply verifiable logs to HTTP over TLS. As DANE (RFC6698) provides an alternative keying infrastructure to that used in the current web PKI, the working group should consider appropriate client behavior in the presence of both DANE-based keying and current web PKI when standardising CT. - Discuss mechanisms and techniques that allow cryptographically verifiable logs to be deployed to improve the security of protocols other than HTTP over TLS, for example SMTP/TLS or software distribution. Where such mechanisms appear sufficiently useful, the WG will re-charter to add relevant new work items. Should no such items be chartered the WG will close when documents associated with the first work item are complete. Goals and Milestones: Dec 2015 - 6962bis to IESG Jul 2016 - Threat analysis to working group last call Oct 2016 - Gossip draft to working group last call Internet-Drafts: - Gossiping in CT [draft-ietf-trans-gossip-05] (57 pages) - Certificate Transparency Version 2.0 [draft-ietf-trans-rfc6962-bis-34] (55 pages) - Attack and Threat Model for Certificate Transparency [draft-ietf-trans-threat-analysis-16] (32 pages) No Requests for Comments Transport Area Working Group (tsvwg) ------------------------------------ Charter Last Modified: 2020-03-25 Current Status: Active Chairs: David L. Black Gorry Fairhurst Wesley Eddy Transport Area Directors: Martin Duke Magnus Westerlund Transport Area Advisor: Martin Duke 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 Area receives occasional proposals for the development and publication of RFCs dealing with transport topics that are not in scope of an existing working group or do not justify the formation of a new working group. TSVWG will serve as the forum for developing such work items in the IETF. The TSVWG mailing list is an open discussion forum for such work items, when they arise. The working group meets if there are active proposals that require discussion. The working group milestones are updated as needed to reflect the current work items and their associated milestones. The currently active TSVWG work items mostly fall under the Following topics: (A) Maintenance of the Stream Control Transmission Protocol (SCTP), which involves bug fixes to the SCTP specifications and their progression along the standards track. This work item also includes a small number of modular extensions to SCTP. In order to maintain stable specifications, additional work on SCTP in TSVWG requires Area Director approval. (B) Maintenance of the Resource Reservation Protocol (RSVP) which involves bug fixes to RSVP specifications and their progression along the standards track. This work item may also include a small number of extensions to both RSVP and Integrated Services or advisory documents to address specific application scenarios. In order to maintain stable specifications, additional work on RSVP and/or Integrated Services in TSVWG requires Area Director approval. (C) Maintenance of IP Differentiated Services (DiffServ) mechanisms, which involves mostly advisory documents on the use of DiffServ in specific application scenarios. Other work items related to DiffServ require Area Director approval. (D) Selected other work items, which are mostly in TSVWG for historic reasons. Additional work that does not fall under one of the above topics in TSVWG must satisfy four conditions: (1) WG consensus on the suitability and projected quality of the proposed work item. (2) A core group of WG participants with sufficient energy and expertise to advance the work item according to the proposed schedule. (3) Commitment from the WG as a whole to provide sufficient and timely review of the proposed work item. (4) Agreement by the ADs, who, depending on the scope of the proposed work item, may decide that an IESG review is needed first. Goals and Milestones: Jan 2020 - Submit 'Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP' as a BCP RFC Apr 2020 - Submit 'SCTP NAT Support' to IESG for consideration as a PS RFC Apr 2020 - Submit 'Packetization Layer Path MTU Discovery for Datagram Transports' as a Proposed Standard RFC Apr 2020 - Submit “The Impact of Transport Header Confidentiality on Network Operation and Evolution of the Internet” as an Informational RFC Jun 2020 - Submit " Transport Options for UDP" as a Proposed Standard RFC Jul 2020 - Submit 'Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim' as a Proposed Standard RFC Sep 2020 - Submit "Stream Control Transmission Protocol" aka RFC4960.bis as a Proposed Standard RFC Oct 2020 - Submit "Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture" as an Informational RFC Oct 2020 - Submit "DualQ Coupled AQM for Low Latency, Low Loss and Scalable Throughput" as an Experimental RFC Oct 2020 - Submit "Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing Delay" as an Experimental RFC Dec 2020 - Submit 'Tunnel Congestion Feedback' as an Informational RFC Dec 2020 - Submit "A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services" as a Proposed Standard RFC Done - Updates to RFC 793 to resolve conflict between diffserv and TCP interpretation of IP Precedence submitted for publication as Proposed Standard Done - Addition to RFC 2018 to use TCP SACK for detecting unnecessary retransmissions submitted for publication as Proposed Standard Done - Submit I-D on TCP Congestion Window Validation to IESG for consideration as a Proposed Standard Done - Submit I-D on Computing TCP's Retransmission Timer to IESG for consideration as a Proposed Standard. Done - Submit revised ID for ECN to IESG for consideration as a proposed standard Done - Submit ID on UDP-lite to IESG for consideration as a proposed standard Done - TCP-Friendly Rate Control (TFRC) unicast congestion control algorithm submitted to IESG for consideration as a proposed standard Done - Submit ID for SCTP unreliable transport mode to IESG for consideration as a Proposed Standard Done - Submit 'Alternate Semantics for the ECN Field' to IESG for consideration as BCP Done - Submit 'Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels' to IESG for consideration as PS Done - Submit Submit 'QoS Signaling in a Nested Virtual Private Network' to IESG for consideration as Informational Done - Submit 'Generic Aggregate RSVP Reservations' to IESG for consideration as PS Done - Submit 'Quick-Start for TCP and IP' to IESG for consideration as Experimental Done - Submit 'TCP Extended Statistics MIB' to IESG for consideration as PS Done - Submit 'Authenticated Chunks for Stream Control Transmission Protocol' to IESG as consideration as PS Done - Submit 'Padding Chunk and Parameter for SCTP' to IESG for consideration as PS Done - Submit 'SCTP Dynamic Address Reconfiguration' to IESG for consideration as Proposed Standard Done - Submit revision of 'Stream Control Transmission Protocol' to IESG for consideration as Proposed Standard Done - Submit 'Security Attacks Found Against SCTP and Current Countermeasures' to IESG for consideration as Informational Done - Submit 'Specifying New Congestion Control Algorithms' to IESG for consideration as Best Current Practice Done - Submit 'Aggregation of DiffServ Service Classes' to IESG for consideration as Informational Done - Submit 'Explicit Congestion Marking in MPLS' to IESG for consideration as Proposed Standard Done - Submit 'User-Defined Errors for RSVP' to IESG for consideration as Proposed Standard Done - Submit 'RSVP Extensions for Emergency Services' to IESG for consideration as Proposed Standard Done - Submit 'DSCPs for Capacity-Admitted Traffic' to IESG for consideration as Proposed Standard Done - Submit 'RSVP Proxy Approaches' to IESG for consideration as Informational Done - Submit 'RSVP Extensions for Path-Triggered RSVP Receiver Proxy' to IESG for consideration as Proposed Standard Done - Submit 'UDP Usage Guidelines for Application Designers' to IESG for consideration as Best Current Practice Done - Request publication of 'Support for RSVP in Layer 3 VPNs' as Proposed Standard RFC Done - Submit 'Port Randomization for Transport Protocols' to the IESG for consideration as a Best Current Practice Done - Submit 'Applicability of Keying Methods for RSVP Security' to IESG for consideration as Informational Done - Request publication of 'IANA Procedures for the Transport Protocol Port Number Space' as BCP RFC Done - Request publication of 'Datagram Transport Layer Security for Stream Control Transmission' as Proposed Standard Done - Request publication of 'Layered Encapsulation of Congestion Notification' as Proposed Standard Done - Submit 'SCTP Chunk Flags Registration' to IESG for consideration as a Proposed Standard Done - Submit 'Sockets API Extensions for SCTP' to IESG for consideration as Informational Done - Submit 'SCTP Stream Reconfiguration' to IESG for consideration as a Proposed Standard Done - Submit 'Deprecation of ICMP Source Quench messages' to IESG for consideration as a Proposed Standard Done - Submit 'Byte and Packet Congestion Notification' to IESG for consideration as a Best Current Practice RFC Done - Submit 'UDP Encapsulation of SCTP Packets' to IESG for consideration as a Proposed Standard RFC Done - Submit 'SCTP SACK Immediately' to IESG for consideration as a Proposed Standard RFC Done - Submit 'Encoding and Transport of (Pre-) Congestion Information from the Domain Egress to the Ingress' to the IESG for consideration as an Experimental RFC Done - Submit 'SCTP PR Polices' as a PS RFC Done - Submit 'Recommendations for Transport Port Uses' to the IESG Done - Submit 'DTLS Encapsulation of SCTP Packets for RTCWEB ' to IESG for consideration as a Proposed Standard RFC Done - Submit 'Quick Failover Algorithm in SCTP' to the IESG for consideration as a Proposed Standard RFC Done - Submit 'Behavioral Requirements Updates'’ as a BCP RFC Done - Submit 'Network Transport Circuit Breakers' to IESG Done - Submit 'UDP Usage Guidelines' as a BCP RFC Done - Submit 'DiffServ interconnection classes and practice' as an Informational RFC Done - Submit 'DSCP packet markings for RTCWeb QoS' to IESG as a Proposed Standard RFC Done - Submit 'Specification of GRE in UDP encapsulation' to IESG as a PS RFC Done - Submit 'SCTP New Data Chunk' as a Proposed Standard RFC Done - Submit ‘Explicit Congestion Notification (ECN) Experimentation’ as a Proposed Standard RFC Done - Submit "Guidelines for DiffServ to IEEE 802.11 Mapping" as a Proposed Standard RFC Done - Submit 'RFC 4960 Errata and Issues' (SCTP) as an Informational RFC Done - Submit "Forward Error Correction (FEC) Framework Extension to Sliding Window Codes" as a Proposed Standard RFC Done - Submit "Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Scheme for FECFRAME" as a Proposed Standard RFC Done - Submit 'A Lower Effort Per-Hop Behavior (LE PHB)' 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) - 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) - 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) - 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) - DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput (L4S) [draft-ietf-tsvwg-aqm-dualq-coupled-11] (53 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) - 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-21] (48 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) - Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP) [draft-ietf-tsvwg-dtls-for-sctp-06] (9 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-13] (38 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) - Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing Delay (L4S) [draft-ietf-tsvwg-ecn-l4s-id-10] (45 pages) - Explicit Congestion Marking in MPLS [draft-ietf-tsvwg-ecn-mpls-02] (21 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) - Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets [draft-ietf-tsvwg-ecnsyn-00] (14 pages) - RSVP Extensions for Admission Priority [draft-ietf-tsvwg-emergency-rsvp-15] (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, Scalable Throughput (L4S) Internet Service: Architecture [draft-ietf-tsvwg-l4s-arch-06] (36 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) - Stream Control Transmission Protocol (SCTP) Network Address Translation Support [draft-ietf-tsvwg-natsupp-16] (47 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-01] (10 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) - Stream Control Transmission Protocol [draft-ietf-tsvwg-rfc4960-bis-06] (147 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-10] (22 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) - DSCP Packet Markings for WebRTC QoS [draft-ietf-tsvwg-rtcweb-qos-18] (11 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) - 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 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) - Stream Control Transmission Protocol (SCTP) Stream Reconfiguration [draft-ietf-tsvwg-sctp-strrst-13] (34 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) - Stream Control Transmission Protocol (SCTP) Checksum Change [draft-ietf-tsvwg-sctpcsum-07] (17 pages) - Stream Control Transmission Protocol (SCTP) Specification Errata and Issues [draft-ietf-tsvwg-sctpimpguide-16] (109 pages) - Sockets API Extensions for the Stream Control Transmission Protocol (SCTP) [draft-ietf-tsvwg-sctpsocket-32] (115 pages) - Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures [draft-ietf-tsvwg-sctpthreat-05] (14 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-15] (52 pages) - Tunnel Congestion Feedback [draft-ietf-tsvwg-tunnel-congestion-feedback-07] (18 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) - Transport Options for UDP [draft-ietf-tsvwg-udp-options-08] (33 pages) - MIB for the UDP-Lite protocol [draft-ietf-tsvwg-udplite-mib-03] (23 pages) - SCTP Unreliable Data Mode Extension [draft-ietf-tsvwg-usctp-00] (10 pages) - Quality of Service (QoS) Signaling in a Nested Virtual Private Network [draft-ietf-tsvwg-vpn-signaled-preemption-02] (38 pages) - Computing TCP's Retransmission Timer [draft-paxson-tcp-rto-01] (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) - RFC 4960 Errata and Issues [draft-tuexen-tsvwg-rfc4960-errata-04] (44 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: BCP124: Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field (15 pages) BCP133: Specifying New Congestion Control Algorithms (10 pages) BCP145: Unicast UDP Usage Guidelines for Application Designers (27 pages) BCP156: Recommendations for Transport-Protocol Port Randomization (29 pages) BCP165: Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry (33 pages) BCP208: Network Transport Circuit Breakers (24 pages) RFC2861: TCP Congestion Window Validation (11 pages) * Obsoletes RFC7661 RFC2873: TCP Processing of the IPv4 Precedence Field (8 pages) 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) 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) 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 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) RFC6056: Recommendations for Transport-Protocol Port Randomization (29 pages) RFC6083: Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP) (9 pages) RFC6096: Stream Control Transmission Protocol (SCTP) Chunk Flags Registration (8 pages) 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) RFC7053: SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol (8 pages) 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) 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) 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) 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) Using TLS in Applications (uta) ------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Leif Johansson Valery Smyslov Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba 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: Jun 2019 - Use of TLS for Email Submission and Access to IETF LC Internet-Drafts: - 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) - SMTP Require TLS Option [draft-ietf-uta-smtp-require-tls-09] (16 pages) - SMTP TLS Reporting [draft-ietf-uta-smtp-tlsrpt-23] (34 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 use of TLS 1.1 for Email Submission and Access [draft-ietf-uta-tls-for-email-05] (6 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) - 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: BCP195: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) (27 pages) 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) 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) RFC8460: SMTP TLS Reporting (34 pages) RFC8461: SMTP MTA Strict Transport Security (MTA-STS) (29 pages) RFC8689: SMTP Require TLS Option (16 pages) IPv6 Operations (v6ops) ----------------------- Charter Last Modified: 2018-06-01 Current Status: Active Chairs: Fred Baker Ron Bonica Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Warren Kumari 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: Jul 2019 - Recommendations for DNS in an IPv6 Network 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) - 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/NAT64 Optimization [draft-ietf-v6ops-464xlat-optimization-00] (18 pages) - Basic Requirements for IPv6 Customer Edge Routers [draft-ietf-v6ops-6204bis-12] (21 pages) - Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link [draft-ietf-v6ops-64share-10] (10 pages) - Advisory Guidelines for 6to4 Deployment [draft-ietf-v6ops-6to4-advisory-02] (20 pages) - Security Considerations for 6to4 [draft-ietf-v6ops-6to4-security-04] (41 pages) - Deprecating the Anycast Prefix for 6to4 Relay Routers [draft-ietf-v6ops-6to4-to-historic-11] (10 pages) - IPv6 Deployment Scenarios in 802.16 Networks [draft-ietf-v6ops-802-16-deployment-scenarios-07] (16 pages) - IPv6 Unicast Address Assignment Considerations [draft-ietf-v6ops-addcon-10] (35 pages) - Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules [draft-ietf-v6ops-addr-select-ps-09] (17 pages) - Requirements for Address Selection Mechanisms [draft-ietf-v6ops-addr-select-req-07] (7 pages) - Application Aspects of IPv6 Transition [draft-ietf-v6ops-application-transition-03] (33 pages) - Goals for Registered Assisted Tunneling [draft-ietf-v6ops-assisted-tunneling-requirements-01] (14 pages) - Balanced Security for IPv6 Residential CPE [draft-ietf-v6ops-balanced-ipv6-security-01] (9 pages) - ISP IPv6 Deployment Scenarios in Broadband Access Networks [draft-ietf-v6ops-bb-deployment-scenarios-05] (81 pages) - IPv6 Campus Transition Scenario Description and Analysis [draft-ietf-v6ops-campus-transition-01] (28 pages) - IPv6 Prefix Length Recommendation for Forwarding [draft-ietf-v6ops-cidr-prefix-03] (6 pages) - IPv4 Service Continuity Prefix [draft-ietf-v6ops-clatip-04] (4 pages) - Using Conditional Router Advertisements for Enterprise Multihoming [draft-ietf-v6ops-conditional-ras-08] (21 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 Renumbering Events [draft-ietf-v6ops-cpe-slaac-renum-01] (6 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) - 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) - IPv6 Enterprise Network Scenarios [draft-ietf-v6ops-ent-scenarios-05] (17 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) - Happy Eyeballs: Success with Dual-Stack Hosts [draft-ietf-v6ops-happy-eyeballs-07] (15 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) - 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) - IPv6 Multihoming without Network Address Translation [draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06] (22 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-01] (11 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) - Happy Eyeballs Version 2: Better Connectivity Using Concurrency [draft-ietf-v6ops-rfc6555bis-07] (15 pages) - Basic Requirements for IPv6 Customer Edge Routers [draft-ietf-v6ops-rfc7084-bis-04] (31 pages) - Rogue IPv6 Router Advertisement Problem Statement [draft-ietf-v6ops-rogue-ra-02] (16 pages) - IPv6 Routing Policies Guidelines [draft-ietf-v6ops-routing-guidelines-01] (8 pages) - IPv6 Implications for Network Scanning [draft-ietf-v6ops-scanning-implications-04] (13 pages) - IPv6 Transition/Co-existence Security Considerations [draft-ietf-v6ops-security-overview-06] (41 pages) - SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments [draft-ietf-v6ops-siit-dc-03] (24 pages) - Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode [draft-ietf-v6ops-siit-dc-2xlat-02] (17 pages) - Explicit Address Mappings for Stateless IP/ICMP Translation [draft-ietf-v6ops-siit-eam-03] (19 pages) - Reaction of Stateless Address Autoconfiguration (SLAAC) to Flash- Renumbering Events [draft-ietf-v6ops-slaac-renum-02] (12 pages) - Teredo Security Concerns [draft-ietf-v6ops-teredo-security-concerns-02] (20 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) - Considerations For Using Unique Local Addresses [draft-ietf-v6ops-ula-usage-considerations-02] (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) - Unmanaged Networks IPv6 Transition Scenarios [draft-ietf-v6ops-unman-scenarios-03] (20 pages) - Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks [draft-ietf-v6ops-unmaneval-03] (19 pages) - Local-Use IPv4/IPv6 Translation Prefix [draft-ietf-v6ops-v4v6-xlat-prefix-02] (7 pages) - Framework for IP Version Transition Scenarios [draft-ietf-v6ops-v4v6tran-framework-02] (7 pages) - Considerations for Transitioning Content to IPv6 [draft-ietf-v6ops-v6-aaaa-whitelisting-implications-11] (27 pages) - Mobile Networks Considerations for IPv6 Deployment [draft-ietf-v6ops-v6-in-mobile-networks-05] (17 pages) - IPv6 Deployment in Internet Exchange Points (IXPs) [draft-ietf-v6ops-v6inixp-09] (10 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) - 464XLAT Optimization [draft-palet-v6ops-464xlat-opt-cdn-caches-04] (17 pages) Requests for Comments: BCP157: IPv6 Address Assignment to End Sites (9 pages) BCP196: Deprecating the Anycast Prefix for 6to4 Relay Routers (10 pages) BCP198: IPv6 Prefix Length Recommendation for Forwarding (6 pages) BCP202: Reducing Energy Consumption of Router Advertisements (6 pages) BCP204: Host Address Availability Recommendations (15 pages) 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) 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) 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) WebTransport (webtrans) ----------------------- Charter Last Modified: 2020-03-06 Current Status: Active Chairs: David Schinazi Dr. Bernard D. Aboba Ph.D. Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba 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: Mar 2020 - Adopt a WebTransport Overview draft as a WG work item Mar 2020 - Adopt a draft defining a WebTransport protocol as a WG work item Oct 2020 - Issue WG last call of the WebTransport Overview document. Jan 2021 - Issue WG last call on the first WebTransport protocol document Internet-Drafts: - The WebTransport Protocol Framework [draft-ietf-webtrans-overview-00] (12 pages) - The WebTransport Protocol Framework [draft-vvv-webtransport-overview-01] (11 pages) No Requests for Comments Web Packaging (wpack) --------------------- Charter Last Modified: 2020-03-26 Current Status: Active Chairs: David C Lawrence Sean Turner Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: wpack@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/wpack Archive: https://mailarchive.ietf.org/arch/browse/wpack/ Description of Working Group: The WPACK working group will develop a specification for a web packaging format that efficiently bundles multiple HTTP representations. It will also specify a way for the publisher to authenticate these resources such that a user agent can trust that they came from their claimed web origins. Key goals for WPACK are: * Efficient (binary) storage across a range of resource combinations. Three use cases to be supported are: a client-generated snapshot of a complete web page, a web page's tree of JavaScript modules, and a selection of the whole web for peer-to-peer distribution in a country when access to authoritative servers is unavailable. * The ability to create a snapshot of a web page without the cooperation of its publisher. * The ability to receive a web package from an entity other than the origin server and have continuity of experience and state (especially that created by active content such as JavaScript) between the offline and online versions. * When a bundle is streamed, the client must be able to start using a subresource before the entire bundle is downloaded, and for large subresources, before the entire subresource is downloaded. * When a bundle is loaded from random-access storage, the client must be able to use a subresource without necessarily reading the entire prefix of the bundle before that subresource. * When a bundle is authenticated, the client must be able to validate the authentication without extra requests over the network. * Being extensible and crypto agile. * Security and privacy properties of using authenticated bundles as close as practical to TLS 1.3 transport of the same resources. Where properties do change, the group will document exactly what changed and how affected people, including content publishers and users, can compensate. Part of this is analyzing how the shift from transport security to object security changes the security properties of the web's existing features. * Specifying constraints on how clients load the formats without describing specific loading algorithm to help achieve the above goals. The packaging format will also aim to achieve the following secondary goals as long as they don't compromise or delay the above properties. * Optimizations in encoding and processing when only a single resource (as opposed to a collection thereof) is being packaged * Support signed statements about subresources beyond just assertions that they're accurate representations of particular URLs. * Address the threat model of a website's frontend compromised after a user first uses the site. * Support books being published in the format: support for bundles that have no expiration date; ability to reference a resource withing a bundle (e.g. chapter) * Optimize storage of large numbers of small same-origin resources (e.g. using compression) * Allow publishers to efficiently combine sub-packages from other publishers. The following goals are out of scope under this charter: * DRM (Digital Rights Management) * A way to distribute the private portions of a website. For example, WPACK might define a way to distribute a messaging application but wouldn't define a way to distribute individual messages without a direct connection to the messaging application's origin server. * A way to automatically discover the URL for an accessible (retrievable) package that includes specific content. Note that consensus is required both for changes to the initially proposed protocol mechanisms and for their retention. In particular, because something is in an initial working group draft does not imply that there is consensus around the feature or around how it is specified. Relationship to Other WGs and SDOs WPACK will work with the W3C and WHATWG to identify the existing security and privacy models for the web, and to ensure those SDOs can define how this format is used by web browsers. The WPACK working group will work closely with the HTTPbis working group, in particular WPACK will attempt to reuse HTTPBIS work on HTTP signing. Goals and Milestones: Jun 2020 - Working group adoption of use cases document (will not be published as an RFC) Jun 2020 - Working group adoption of bundling document Jun 2020 - Working group adoption of security analysis document Jun 2020 - Working group adoption of privacy analysis document Jun 2020 - Working group adoption of one or more signing document Sep 2021 - Submit the Bundling document to IESG Mar 2022 - Submit the Privacy analysis document to IESG Mar 2022 - Submit the Security analysis document to IESG Mar 2022 - Submit Signing document (this might just reference HTTPBIS work) to IESG Internet-Drafts: No Requests for Comments