| Internet-Draft | Babel for Wi-Fi Mesh | July 2026 |
| Eastlake | Expires 6 January 2027 | [Page] |
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.¶
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 (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
[[[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.¶
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.¶
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 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
+----------------+-------------
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.¶
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¶
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.¶
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.¶
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.¶
This section is to be interpreted as provided in [RFC8126].¶
IANA is requested to assign a codepoint in the Babel Address Encoding registry as follows:¶
| AE | Name | Reference |
|---|---|---|
| TBD | 48-Bit MAC Address | [this document] |
In conformance with Section 4 of [RFC9542] IANA is requested to create a registry in the "IANA OUI Ethernet Numbers" Registry Group as follows:¶
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 Delay Based Link Metric | [this document] |
| 4-41 | Unassigned | |
| 42 | Example for use in documentation | [this document] |
| 43-254 | Unassigned |
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].¶
The comments and suggestions of the following are gratefully acknowledged:¶