This commit renames DHCPv6-PD related types and methods in
`RoutingManager` to consistently use the `Dhcp6Pd` term.
This commit also updates the related unit test in
`test_routing_manager`. The test is renamed to `TestDhcp6Pd()`, and
the code style is updated to align with other test cases in the same
file. No changes are made to the actual test steps or what is covered
by the test itself. The method for reporting PD prefixes to the
OpenThread stack is modified within the unit test. Instead of using
`otPlat` APIs, `RoutingManager` methods are now directly invoked.
This helps make the unit tests independent of the configuration,
allowing for more flexible models where platform-provided APIs may
not be provided (e.g., DHCPv6 client as part of OpenThread code).
This commit introduces a new mechanism in `RoutingManager` to
configure OMR prefix handling on a Border Router. This provides
manual administration options to explicitly set a custom OMR prefix
or disable it, in addition to the existing default behavior where the
BR automatically selects and manages the OMR prefix. These new
administrative configurations can also be used during testing,
particularly for certification tests.
This commit adds new public OpenThread APIs and a CLI command,
`br omrconfig`, for this functionality. Notably, the new APIs allow
updating the OMR configuration while the BR is enabled and running,
and the implementation correctly adjusts to the new requested
behavior.
A new detailed test case is added to the `test_routing_manager` unit
test, covering the new behavior.
This commit introduces a mechanism in `RoutingManager` to parse and
process Recursive DNS Server (RDNSS) options within received Router
Advertisement (RA) messages. The list of discovered RDNSS addresses
is tracked (per router) by `RoutingManager`, applying the advertised
lifetime to properly age the discovered entries.
This commit adds a new public API to retrieve the list of tracked
RDNSS addresses, along with a callback mechanism where OpenThread
users can register to be notified of changes to the RDNSS list. This
callback is invoked when any of the following changes occur:
- A new RDNSS address is advertised by a router.
- A previously discovered address is removed due to the router
advertising it with a zero lifetime.
- A previously discovered address has aged out (its lifetime expired
without being re-advertised).
- `RoutingManager` determines that the router advertising the address
is now unreachable, resulting in the removal of all its associated
entries.
This commit also adds corresponding CLI commands for the new API.
Furthermore, `test_routing_manager` is updated to include a test case
covering all the newly added behaviors in detail.
This commit introduces a platform API to get the InfraIf link-layer
address. And add the source link-layer address option to all ND6
messages generated from OpenThread.
In some cases, the platform may send the new prefix without
deprecating the existing prefix when renewing the prefix allocated by
PD.
The existing code will stop the timer, causing the prefix to be active
forever.
This commit fixes this issue.
This commit adds a new IDLE state to PdPrefixManager.
PdPrefixManager enters idle state when PD is enabled and there is
already a BR requesting PD prefix. When there are multiple BRs
publishing PD prefix at the same time, the one with lexcial smaller
prefix wins.
This commit updates the `RouteingManager` to set the newly
allocated "SNAC Router Flag" (bit 6) in emitted RA messages from
Thread BR. The flag is also parsed and tracked in received RA
messages.
This replaces the previous model where an experimental flag bit
in "Flags Extension Option" indicated a "stub router". This commit
also removes the `STUB_ROUTER_FLAG_IN_EMITTED_RA_ENABLE` confg
(no longer optional/experimental) and renames `mStubRouterFlag` to
`mSnacRouterFlag`.
This commit updates `RoutingManager::RioAdvertiser` to advertise
deprecating prefixes with `NetworkData::kkRoutePreferenceLow`.
`test_routing_manager` is updated to validate this new behavior.
This commit adds the `OnLinkPrefix::IsFavoredOver()` method to
determine if an on-link prefix is eligible to be considered as a
favored prefix, and if so, is favored over another prefix. A
numerically smaller prefix is considered favored.
Additionally, a new test case is added to `test_routing_manager` to
validate the selection of favored on-link prefixes, including the
the requirement of a minimum preferred lifetime of 1800 seconds
for a prefix to be considered eligible.
This commit changes unit test `TestPrefixStaleTime()` so that a route
prefix is advertised with a lifetime of 800 seconds, which is longer
than the `kStaleTime` of 600 seconds. With this change, the entry
will not expire and become stale at the same time. This simultaneous
expiration could cause issues depending on the order of execution of
`mStaleTimer` and `mExpirationTimer`, which would be scheduled for
the same time. With this change, the entry will still be valid (due
to the lifetime of 800 seconds) when the stale timer fires after 600
seconds. This ensures that the test runs consistently and does not
depend on the order in which timer callbacks fire.
This commit renames the entry stale time constant to `kStaleTime` and
sets it to 10 minutes (from 30 minutes). This change aligns the
`RoutingManager` with the recommended value in the latest stub router
RFC draft (`STALE_RA_TIME`).
The unit test `test_routing_manager` is also updated to reflect this
new constant.
This commit updates the determination of stale times for discovered
on-link or route prefixes. The stale time is now calculated per
unique prefix. If multiple routers advertise the same on-link or
route prefix, the stale time for the prefix is set to the latest
among all corresponding entries.
This addresses an issue in the previous implementation where, for
on-link prefixes, the stale time was determined as the latest stale
time over all on-link entries, regardless of the actual prefixes. For
route prefixes, the earliest stale time was used, also disregarding
the possibility of multiple routers advertising the same prefix.
This commit also updates the `test_routing_manager` unit test to
validate the corrected stale time calculation.
This commit updates `PdPrefixManager` to use the newly added
`GetDeprecationTime()` method for managing the lifetime of a DHCPv6
PD prefix. This method calculates the deprecation time using the
prefix preferred lifetime directly, instead of relying on the RA
stale time constant `GetStaleTime()`.
While the PD prefix may be determined by processing RA messages
received on the Thread interface, the RA stale time is not relevant
in this context. The RA stale time is only applicable to RA messages
received over infra-if. It specifies the time that can pass after the
last RA from a particular router on infra-if before assuming the
router might be unavailable and triggering Router Solicitation
(RS) messages.
This commit adds `mIsLocalDevice` in the `Router` class to track
whether it represents the local device (e.g., another software entity
on this device). This information is used to skip sending NS probes
to this router. Tracking this information directly in the `Router`
class is safer than checking the address using `mInfra.HasAddress()`,
as the addresses may have changed since the last RA was received.
This commit exposes this information through the public APIs and CLI
command, and updates `test_routing_manager` unit test to validate the
new flag.
This commit modifies the `CalculateHash()` method to use a zero
checksum value for RA (ICMPv6) header for both received and emitted
RA message. In prepared RA messages, the checksum is always set to
zero, and the platform layer is responsible for calculating and
updating it. For a received RA, while platforms typically zero out
the checksum after validation, this behavior isn't explicitly
required by `otPlatInfraIf` APIs. By ignoring the checksum(setting it
to zero) during hash calculation, this change ensures correct
calculation regardless of platform behavior.
This commit also updates `test_routing_manager` to intentionally
modify the checksum field in an emitted RA message before passing it
back to the OT stack. This validates the updated hash calculation
behavior.
This commit adds `RouterAdvOrigin` enumeration to track the origin of
a received RA message, whether it is from another router on the
infrastructure, or self-generated by either the `RoutingManager`
module or another software entity running on the device.
This is used to exclude prefixes from self-generated `RoutingManager`
RAs in the prefix table and simplifies learning and adopting of RA
headers from other software entities on the same device.
The origin is now logged when a new RA is received for improved
debugging.
This commit also updates `test_routing_manager` to pass back any sent
RA messages to the OT stack. This validates the mechanism for
identifying self-generated RA messages.
This commit enhances dataset handling:
- Adds `ValidateTlvs()` which parses and validates all known TLVs
within the `Dataset` and checks for any duplicates.
- Introduces a set of `SetFrom()` methods for constructing a `Dataset`
from various types of inputs, e.g., other `Dataset`, TLV sequences,
`DatasetInfo` structures, bytes read from `Message`. Now they
consistently clear the `Dataset` before setting it.
- Adds `WriteTlvsFrom()` to update a `Dataset` replacing/appending a
set of TLVs.
- Adds `AppendTlvsFrom()` to append an already encoded sequence of
TLVs without validating/checking the format.
- Renames `Get/SetSize()` to `Get/SetLength()` for consistency.
- Adds `test_dataset.cpp` unit test for basic `Dataset` validation.
This commit updates how `RoutingManager` differentiates between
self-generated RA messages and those from other sources sending RA on
the same device. This enables learning of the RA header, specifically
the default route lifetime.
This commit introduces a new mechanism to calculate and store a SHA256
hash of recently emitted RAs. Received RAs are cross-referenced
against the stored hashes to determine their origin. This replaces
the prior method, which relied on parsing and analyzing the included
options in the received RA.
A new test case is added in `test_routing_manager` to validate the
learning of RA header from other sources on same device.
This commit enhances flexibility in Router Advertisement (RA) message
construction by employing `Heap::Array`. This eliminates the need for
a pre-allocated buffer and removes the constraint of predetermining
the maximum RA message size.
Additionally, introduces `TxMessage` and `RxMessage` nested classes
within `Ip6::Nd::RouterAdvert` for efficient handling of outgoing and
incoming RA messages:
- `TxMessage`: Facilitates appending elements to an RA message with
dynamic buffer allocation.
- `RxMessage`: Enables parsing and iterating over options within a
received RA message.
This commit fixes `DiscoveredPrefixTable::Entry::IsDeprecated()` to
properly handle larger preferred lifetime values. It uses the method
`CalculateExpireDelay()` to handle time delay calculation, avoiding
overflow. The `test_routing_manager` test has also been updated to
check for larger preferred/valid lifetime values.
This commit adds `RioAdvertiser` component to `RoutingManager`, which
manages the list of prefixes advertised as RIO in emitted RA messages
by BR. The RIO prefixes are discovered from on-mesh prefixes in
Thread Network Data, including OMR prefixes from `OmrPrefixManager`
and other prefixes. Existing code for maintaining the list, appending
RIOs, and determining/setting the RIO preference is moved to the
`RioAdvertiser` class.
The `RioAdvertiser` adds a new mechanism to deprecate prefixes removed
from Network Data such that any removed prefix is still advertised as
RIO in emitted RA messages up to a deprecation interval of 300
seconds (using a shorter route lifetime in RIO). This mechanism
ensures that when an OMR prefix is withdrawn, traffic can still be
routed during deprecation time from AIL to Thread devices using the
old OMR address.
This commit also updates `test_routing_manager` to validate the new
behavior.
This commit implements a mechanism in `RoutingManager` to learn the
Managed Address Config `M` and Other Config `O` flags in received RA
message from discovered routers on the infrastructure link and copy
the same flags in the emitted RA message from BR.
If any discovered router on the infrastructure that is not itself a
stub router (i.e., does not include the Stub Router flag) includes
the `M` or `O` flags, the same flag are included in the emitted RA
message. If a discovered router has failed to respond to the maximum
number of NS probe attempts, we consider it as offline and ignore its
flags.
This commit also adds a detailed test case in `test_routing_manager`
to validate the newly added mechanism.
This commit adds `otBorderRoutingGetNextRouterEntry` as a new API to
iterate over discovered routers on the infrastructure link and get
information about them such as their address, their Managed Address
Configuration (`M`), Other Configuration (`O`), and Stub Router
flags.
The `otBorderRoutingPrefixTableEntry` is also updated to contain
the same information.
This commit also updates the CLI `br` sub-commands to provide this
information, adding `br routers` to obtain a list of discovered
routers.
This commit updates unit test modules to be defined under the `ot`
namespace. This aligns all the unit tests to follow the same
model, eliminating the need to use `ot::` prefix in unit test
code.
This commit addresses occasional failures in `test_routing_manager` in
the `TestBorderRoutingProcessPlatfromGeneratedNd` case. Unlike other
tests, this test sets the `heapAllocations` after the call `InitTest
(/* aEnableBorderRouting */ true)` (which enables `RoutingManager`).
This means that depending on the random timing, the `heapAllocations`
may already count some allocated heap items by `RoutingManager`
itself. With the change in this commit, at the end of the test, we
check that the number of remaining heap allocations is less than
`heapAllocations`.
This commit moves the `instance` module to a newly added folder
`core/instance` (from `core/common`. Header file `extension.hpp`
and its example is also moved to the same folder.
Some equation checks accidentally became non-zero checks due to
typo. Such tests may fail in certain build configurations when the
heap allocation is zero after initialization of the test.
This commit updates `RoutingManager` to include the Flags Extension
Option with Stub Router flag in its emitted Router Advertisement
messages.
Config `STUB_ROUTER_FLAG_IN_EMITTED_RA_ENABLE` can be used to enable
or disable this behavior which is enabled by default.
This commit introduces a new configuration option for the routing
manager to use heap-allocated entries in the `DiscoveredPrefixTable`,
which maintains a list of discovered routers and their advertised
on-link prefixes. This makes the implementation more flexible when
dealing with a large number of routers and/or discovered prefix
entries.
The config option `OPENTHREAD_CONFIG_BORDER_ROUTING_USE_HEAP_ENABLE`
enables this behavior. By default, it is enabled. When disabled, the
previous model, which uses pre-allocated arrays and pools, is used
instead.
This commit also updates the unit test `test_routing_manager` to track
heap allocations and validate that all heap allocations by the
routing manager are freed when it is stopped.
This commit adds support for the Advertising PIO (AP) flag in Network
Data `ExternalRoute` entries. It also updates the `RoutingManager`
class to set the AP flag on its published Network Data route when the
local on-link prefix is included as PIO in emitted RA messages, which
is equivalent to when the local on-link prefix is being published,
advertised, or deprecated.
This commit also updates the `test_routing_manager` unit test to
validate the AP flag in the published route under different
scenarios.
This commit updates the unit tests that emulate the radio platform API
to define `otPlatRadioGetCaps()`, which returns the ACK_TIMEOUT and
CSMA capabilities. This is to avoid having CSMA being implemented by
the `SubMac`, which then uses the microsecond timer that is not
emulated in the unit test platform.
It also updates the `InitTest()` function to clear the radio platform
variable `sRadioTxOngoing`. This is to avoid the possible
(though unlikely) situation where an earlier test finishes in the
middle of a transmission, causing an extra `TxDone` event in the
following test.
This commit adds the following new API:
- otBorderRoutingProcessIcmp6Ra
And related APIs:
- otBorderRoutingDhcp6PdSetEnabled
- otBorderRoutingGetPdOmrPrefix
They are used to support the DHCPv6 PD on Thread Border Routers. On a
typical OS, the DHCPv6 Client of the platform network stack will
request a IPv6 subnet via DHCPv6-PD, then invoke the daemon for
sending router advertisements on the given interface.
With this commit, the RA will be catched by the processTransmit in
netif.cpp, which will then pass the message to
otBorderRoutingAddPrefixByRouterAdvertisement, RoutingManager will
then add the prefix according to the PIO in the router advertisement,
and take care of the lifetime of the prefix added.
This commit adds a new mechanism to update the default route flag on
the local OMR prefix based on whether or not the BR is publishing
the `::/0` external route prefix.
When `RoutePublisher` (the component that determines which route
prefix to publish) decides to publish/unpublish the default route as
`::/0`, it will inform `LocalOmrPrefix` (the component that manages
when the local OMR prefix is added/removed in Thread Network Data) of
the def-route flag to use.
- If the local OMR prefix is not yet added, the def-route flag will be
remembered to be used when/if it is added.
- If the local OMR prefix is already added, the entry in Network Data
is updated to use the new def-route flag.
This change addresses a backward compatibility issue with devices running
1.2 or earlier Thread versions. These devices may not correctly parse or
accept a zero-length `::/0` route prefix in the Network Data. Adding
the default-route flag on the OMR prefix ensures that these devices
can reach the border router that added the OMR prefix.
This commit updates the `RoutingManager` module to implement a new
model for publishing routes. The new model replaces the previous
model, which explicitly published all discovered routes and on-link
prefixes (from processing Router Advertisements on AIL) as external
routes in the Network Data.
The new model simplifies this logic by publishing either a `fc00::/7`
(ULA) route or a `::/0` (default) route in the Network Data,
depending on the set of discovered routes and on-link prefixes, and
the currently favored OMR prefix.
This commit adds the `RoutePublisher` class, a nested sub-component of
the `RoutingManager` class. The `RoutePublisher` class is responsible
for determining the route prefix to publish and its preference. The
preference of the published route is determined based on the current
role of the Border Router (BR): low preference if the BR is a child,
and medium preference if the BR is acting as a router.
This commit also updates `test_routing_manager` unit test validating
the new behavior.
According to Thread 1.3.0 Section 4.7.1.3, router synchronization
after reset requires the multicast link request message to be
retransmitted until a response is received, or the maximum
transmission limit has been reached. If the router was a leader or had
more than 5 children prior to reset, it MUST be retransmitted as a
critical message. Each multicast retransmission of an MLE Message on a
TL1 or TL2 Link must be delayed by MLE_MULTICAST_RETRANSMISSION_DELAY
multiplied by a random value between 0.9 and 1.1 with a resolution of
at least 1 ms.
This commit implements the above requirement. With this requirement,
in the cases when a router is reset and there is no other router to
respond to the link request then it takes longer time for the router
to join thread network. Thus some test cases are modified to allow
longer router sync time in such cases.
This commit updates `RoutingManager` to check if a change to xpanid
does impact the generated local on-link prefix. This can address two
situations: (1) when BR is started before Thread/MLE operation where
we can get a signal that xpanid is changed on MLE start (without it
actually changing), (2) if the xpanid does change but since not all
the xpanid bytes are used in the derivation of the local prefix, it
can remain as before.
This commit also updates the unit test to start the BR early (along
with MLE operation) under the `TestSavedOnLinkPrefixes()` case.
This commit updates the `RoutingManager` unit test to check that
there are no duplicate PIO/RIO prefixes in the emitted RA message.
It also updates the `TestSavedOnLinkPrefixes()` to check behavior
after device resets/restarts while it was advertising its local
on-link prefix or deprecating it.
This commit adds mechanism to save deprecating old on-link prefixes
in non-volatile `Settings`. With this, if the BR is restarted, it
will remember the old prefixes and keep deprecating them (advertising
them in emitted RA and publish them in Thread Network Data).
This commit also adds `TestSavedOnLinkPrefixes()` test case in
`test_routing_manager` to cover the behavior of the newly added
mechanism.
This commit adds a new mechanism in `RoutingManager` to periodically
check that discovered routers are still active and operational, so
that if the router providing the favored on-link prefix becomes
offline, we can detect it more quickly (instead of waiting for the
prefix lifetime to expire) and then the BR can start advertising its
own on-link prefix.
Receiving a Router or Neighbor Advertisement message from a router
indicates that it is active. After a timeout interval passes from the
last receive from a router we start sending Neighbor Solidification
(NS) probes to it. This timeout interval can be specified by newly
added build-time OT config parameter (default value is set to one
minute). If no response is received after multiple NS attempts, the
router is considered to be inactive and the discovered prefix entries
associated with the router are removed or deprecated.
This commit also updates the unit test for routing manager to validate
the behavior of the newly added mechanism.
This commit updates how `OnLinkPrefixManager` retains and deprecates
old local on-link prefixes. Instead of remembering a single old
prefix, a list of old prefixes are remembered and the number of
entries in the list can be configured at build-time using an OT
config.
If the BR is stopped, the deprecating prefixes are still remembered
and the the expire timer keeps running. They are removed from the
list when they expire. If the BR is started again the deprecating old
prefixes are again included as PIO in the emitted RA and also
published in Network Data.
The changes in this commit also ensure we can correctly handle the
situation where the extended PAN ID is changed to a previous value
before the corresponding on-link prefix expires, i.e. when a
currently deprecating prefix becomes the current local on-link prefix
again.
This commit also updates the unit test case validating the behavior of
newly added mechanism under different situations.
This commit enhances `RoutingManager` so that when we decide to
advertise the local on-link prefix and publish it in Network Data as
an external route, we wait for it to be seen in the leader's Network
Data before including it in the emitted RA messages as PIO. If the
prefix is already present in Network Data (e.g., may have been added
by another BR on the same Thread mesh) we start advertising it
immediately. When publishing prefixes in Network Data, it may take a
short random time before the entry is registered with leader and the
updated Network Data is propagated to all Thread nodes. This change
delays the advertisement of the on-link prefix on the infra link side
till it is configured as an external route on the Thread side.
This commit updates and enhances the mechanism in `RoutingManager`
to publish/unpublish external route prefixes in Thread Network Data.
Instead of each sub-component (e.g., `DiscoveredPrefixTable`,
`LocalOnLinkPrefix`, `Nat64PrefixManager`, ...) directly trying to
publish/unpublish its entries which can lead to conflicting requests
that then needs to be checked and handled by each component, this
commit adds a new method `EvaluatePublishingPrefix()`. This method
makes a collective decision by checking with different sub-components
to see whether or not each wants this prefix published and if so at
what preference level and flags.
This change help simplify the code and handling of conflicting
situations and edge cases (e.g., while deprecating current/old local
on-link prefix, other routers adding/removing same prefix as PIO or
RIO in their emitted RAs).
Abtin Keshavarzian