MANET D. Eastlake Internet-Draft Independent Obsoletes: 2930 (if approved) 5 July 2026 Intended status: Standards Track Expires: 6 January 2027 Babel for Wi-Fi (IEEE Std 802.11) Mesh draft-eastlake-manet-babel-wi-fi-00 Abstract The BABEL routing protocol (RFC 8966) is well applicable (RFC 8967) to networks with unstable link metrics such as wireless networks. Wi-Fi (IEEE Std 802.11-2024) is an example of such a network and the Wi-Fi standard includes a mesh feature which was specified to be configurable for different routing protocols and link metrics. This document specifies how, in Wi-Fi mesh, to use BABEL and/or the delay based link metric specified in RFC 9616. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Eastlake Expires 6 January 2027 [Page 1] Internet-Draft Babel for Wi-Fi Mesh July 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. IEEE Std 802.11 Specifics . . . . . . . . . . . . . . . . . . 3 2.1. Mesh Discovery and Formation . . . . . . . . . . . . . . 3 3. Babel Specifics . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Router ID . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Babel Messages . . . . . . . . . . . . . . . . . . . . . 5 4. Multicast and Broadcast . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5.1. Babel Address Encoding . . . . . . . . . . . . . . . . . 5 5.2. IANA Parameters for Wi-Fi (IEEE 802.11) . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 8. Informative References . . . . . . . . . . . . . . . . . . . 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction [[[This is an incomplete early draft.]]] The BABEL routing protocol (RFC 8966) is well applicable (RFC 8967) to networks with unstable link metrics such as wireless networks. Wi-Fi (IEEE Std 802.11-2024) is an example of such a network and the Wi-Fi standard includes a mesh feature which was specified to be configurable for different routing protocols and link metrics. This document specifies how, in Wi-Fi mesh, to use BABEL and/or the delay based link metric specified in RFC 9616. Not only is the Wi-Fi mesh protocol explicitly designed to allow the specification of other Path Selection Protocols (routing protocols) and Path Selection Metrics (link metrics), but [IEEE802.11] has sent the IETF a [Liaison] stating that it has no objection to this work. Eastlake Expires 6 January 2027 [Page 2] Internet-Draft Babel for Wi-Fi Mesh July 2026 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Clause Parts of [IEEE.802.11_2024] are referred to as Clauses which are hierarchically numbered. These can be nested multiple levels. Frame Roughly the Layer 2 term equivalent to packet. MAC Media Access Control, not message authentication code. Path Selection Metric The Wi-Fi mesh term for a link cost metric. Path Selection Protocol The Wi-Fi mesh term for a routing protocol. Station A logical Wi-Fi entity that is a singly addressable instance of a medium access control and physical layer interface to the wireless medium. Wi-Fi The IEEE Std 802.11-2024 [IEEE.802.11_2024] wireless communication standard. 2. IEEE Std 802.11 Specifics 2.1. Mesh Discovery and Formation Mesh Stations generally discover each other through the transmission and reception of mesh beacon frames. (A mesh Station can also transmit a Probe with the intent of soliciting a Probe Response from a potential peer.) While the interval between beacons is configurable, the common value used is 100 milliseconds. For two Stations to peer, there are a number of fields, called the mesh profile ([IEEE.802.11_2024] Clause 14.2.3), that have to match between the stations which are included in a mesh beacon. These fields include the Mesh ID, Path Selection Protocol ID, and Link Metric ID. In particular, mesh beacon frames include the Mesh Configuration element ([IEEE.802.11_2024] Clause 9.4.2.97) which in turn contains an Active Path Selection Protocol Identifier (Clause 9.4.2.97.2) and Active Path Selection Metric Identifier (Clause 9.4.2.97.3). (The Mesh Configuration element is also included in Probe Response, Mesh Peering Open, and Mesh Peering Confirm Wi-Fi control frames.) The Path Selection and Path Metric identifiers are one-byte fields for Eastlake Expires 6 January 2027 [Page 3] Internet-Draft Babel for Wi-Fi Mesh July 2026 which the value 255 (0xFF) indicates that a "vendor specific" protocol or metric, respectively, is in use by the transmitting Station. The vendor specifics are indicated in one or more Vendor Specific elements (Clause 9.4.2.25) included in the same Wi-Fi frame with the Mesh Configuration element. Figure 1 shows such an element where IANA is the "vendor". 1 1 1 1 1 1 1 1 1 1 2 2 2 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +----------------+---------------+ | Element ID=221 | Length | +----------------+---------------+---------------+ | IANA OUI = 0x00000E | +----------------+---------------+---------------+ | Subtype | Content +----------------+------------- Figure 1: IETF "Vendor Specific" Wi-Fi Element Element ID 221 (0xDD). Length Length of the element in bytes excluding the Element ID and Length field as a one-byte unsigned integer. IANA OUI 0x00005E Subtype Type of content. Content Subtype specific information. May be null. If the Babel path selection protocol is in use, but not the delay- based path metric, then the Active Path Selection Protocol Identifier field MUST be set to 255 (0xFF) and there MUST be an IANA OUI Vendor Specific element present with a subtype of 1. If the delay based path metric in use, but not the Babel path selection protocol is, then the Active Path Selection Metric Identifier field MUST be set to 255 (0xFF) and there MUST be an IANA OUI Vendor Specific element present with a subtype of 2. To indicate that both the Bable path selection protocol and the delay based path metric are in use, the Active Path Selection Protocol Identifier field and the Active Path Selection Metric Identifier in the Mesh Configuration element MUST be set to 255 (0xFF) and there MUST be an IANA OUI Vendor Specific element present with a subtype of 3. The use of a single Vendor Specific element for this case is to minimize the burden of increased beacon size. The Content portion of the Vendor Specific element can be null or can be a Babel routing message such as a Hello. Eastlake Expires 6 January 2027 [Page 4] Internet-Draft Babel for Wi-Fi Mesh July 2026 3. Babel Specifics 3.1. Addresses Wi-Fi operates on Layer 2 of the OSI model using 48-bit MAC addresses which form a flat rather than a hierarchical address space. Thus frames are routed based on a destination MAC address. TBD is assigned as the Babel Address Encoding type for 48-bit MAC addresses 3.2. Router ID Each mesh Station (router) using Babel has an arbitrary 8 byte router-id that must be unique within the routing domain. It is RECOMMENDED that this be derived from the MAC addresses of the Station's interfaces by treating them as 48-bit unsigned integers, selecting the one with the least magnitude, and padding it 16 low order zero bits. 3.3. Babel Messages More TBD. If a mesh Station using Babel is sending beacons, it may be convenient to include a Hello message in the contents of the beacon's IANA Vendor Specific Element being used to announce that the Station is using Babel. More TBD. 4. Multicast and Broadcast Wi-Fi mesh can inherently handle multicase and broadcast data traffic independent of routing by numbering such messages, flooding them inside the mesh, and deleting duplicates. 5. IANA Considerations This section is to be interpreted as provided in [RFC8126]. 5.1. Babel Address Encoding IANA is requested to assign a codepoint in the Babel Address Encoding registry as follows: Eastlake Expires 6 January 2027 [Page 5] Internet-Draft Babel for Wi-Fi Mesh July 2026 +=====+====================+=================+ | AE | Name | Reference | +=====+====================+=================+ | TBD | 48-Bit MAC Address | [this document] | +-----+--------------------+-----------------+ Table 1 5.2. IANA Parameters for Wi-Fi (IEEE 802.11) In conformance with Section 4 of [RFC9542] IANA is requested to create a registry in the "IANA OUI Ethernet Numbers" Registry Group as follows: Name: IETF Parameters for Wi-Fi (IEEE Std 802.11) References: [this document] [IEEE.802.11_2024] Note: This registry provides subtypes, under the IANA OUI, for the "vendor specific" elements that may be used in the IEEE Std 802.11-2024 protocol. The initial contents of the registry are as follows: +=========+==========================+=================+ | Subtype | Description | Reference | +=========+==========================+=================+ | 0 | Reserved | [this document] | +---------+--------------------------+-----------------+ | 1 | Babel Path Selection | [this document] | +---------+--------------------------+-----------------+ | 2 | Delay Based Link Metric | [this document] | +---------+--------------------------+-----------------+ | 3 | Babel Path Selection and | [this document] | | | Delay Based Link Metric | | +---------+--------------------------+-----------------+ | 4-41 | Unassigned | | +---------+--------------------------+-----------------+ | 42 | Example for use in | [this document] | | | documentation | | +---------+--------------------------+-----------------+ | 43-254 | Unassigned | | +---------+--------------------------+-----------------+ Table 2 Eastlake Expires 6 January 2027 [Page 6] Internet-Draft Babel for Wi-Fi Mesh July 2026 6. Security Considerations For IEEE Std 802.11 security considerations, see [IEEE.802.11_2024]. When Wi-Fi mesh Stations peer, they negotiate security and keys. For Babel security considerations, see [RFC8966]. 7. Normative References [IEEE.802.11_2024] IEEE, "IEEE Standard for Information technology-- Telecommunications and information exchange between systems Local and metropolitan area networks--Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std 802.11-2024, 26 September 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8. Informative References [IEEE802.11] Group, I. 8. W., "Wireless Local Area Networks Working Group", . [Liaison] Stanley, D., "Liaison Statement from IEEE 802.11 Working Group to IETF BABEL Working Group", 30 May 2023, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Eastlake Expires 6 January 2027 [Page 7] Internet-Draft Babel for Wi-Fi Mesh July 2026 [RFC9542] Eastlake 3rd, D., Abley, J., and Y. Li, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 9542, DOI 10.17487/RFC9542, April 2024, . Acknowledgements The comments and suggestions of the following are gratefully acknowledged: Author's Address Donald E. Eastlake 3rd Independent 2386 Panoramic Circle Apopka, Florida 32703 United States of America Email: d3e3e3@gmail.com Eastlake Expires 6 January 2027 [Page 8]