This commit removes all Domain Prefix configuration and management logic
from the OpenThread stack, CLI commands, unit tests, and GRL harness
THCI wrapper.
- Removed public Backbone Router Domain Prefix APIs.
- Removed Domain Prefix flag ('mDp') and 'D' flag parser/formatter
from core network data types, Spinel, and CLI.
- Cleaned up local Backbone Router and Leader logic to exclude Domain
Prefix configuration, tracking, and events.
- Updated RoutingManager prefix advertisement (RIO) to exclude
special handling for Domain Prefix.
- Updated CLI documentation to remove Domain Prefix references.
- Removed domain prefix helper methods from python test certification
scripts.
- Removed auto-addition of default domain prefix and D flag support
from GRL harness OpenThread.py.
This commit updates the codebase to use the `Icmp6Header` type
directly, replacing the nested `Ip6::Icmp::Header` definition.
This change aligns the ICMPv6 header type definition with the
conventions used for other network protocol headers and simplifies
type references across the network, border router, and utility
modules.
This commit renames several methods in `Ip6::Address`,
`Ip6::InterfaceIdentifier`, `Ip6::Prefix`, and `Ip4::Address` that
fully initialize the object from `Set...()` to `Init...()`.
This creates a clear semantic distinction in the API:
- `Init...()`: Fully (re-)initializing the object.
- `Set...()`: Modifies a specific property or a sub-component of
the object (e.g., `SetPrefix()`, `SetLocator()`,
`SetSubnetId()`).
Some examples of renames include:
- `SetFromExtAddress()` -> `InitFromExtAddress()`
- `SetToLocator()` -> `InitAsLocator()`
- `SetToLinkLocalAddress()` -> `InitAsLinkLocalAddress()`
- `SetToRoutingLocator()` -> `InitAsRoutingLocator()`
- `SetToAnycastLocator()` -> `InitAsAnycastLocator()`
- `SetToIp4Mapped()` -> `InitAsIp4Mapped()`
All calls to these methods across the codebase have been updated
to reflect the new names.
This commit introduces `testResetInstance()` in the unit test platform
layer to finalize an existing `ot::Instance` and re-initialize it
using the same underlying memory buffer, simulating a device reset.
This commit also updates `test_routing_manager.cpp` to use this new
function to streamline the test implementation.
This commit refactors the `OmrPrefixManager` to decouple it from the main
`RoutingManager` policy evaluation cycle. This allows the OMR prefix to
be managed independently and published faster into the Network Data.
Previously, `OmrPrefixManager` relied on its `Evaluate()` method being
called during the main `RoutingManager::EvaluateRoutingPolicy()` cycle.
This meant it had to wait for other components to be ready — such as
sending Router Solicitations to discover other routers on the Adjacent
Infrastructure Link (AIL)—before taking action.
With this change, `OmrPrefixManager` operates independently. It can
evaluate its state as soon as the Border Router function is enabled and
`Start()` is called.
Additional improvements supporting this independent operation include:
- Replaces the `mIsLocalAddedInNetData` boolean with a `LocalPrefixState`
enum (`kNotAdded`, `kToAdd`, `kAdded`) to manage addition state and
support delayed updates.
- Introduces a random delay (`kMinDelayToAdd` to `kMaxDelayToAdd`)
before adding a self-generated OMR prefix to Network Data. This gives
the network time to settle, allowing other BRs or the `PdPrefixManager`
time to establish a prefix.
- Implements a retry mechanism with jitter for Network Data addition
failures, rather than silently ignoring them.
- Refactors `PdPrefixManager` to batch state changes via an `mEvents`
bitmask and process them through `mEventTask`. Changes are now handled
explicitly by `OmrPrefixManager::HandlePdPrefixManagerEvent()`, further
reducing unnecessary main routing policy evaluations.
This commit provides the platform-level implementation for the
instance-aware logging API `otPlatLogOutput()`. This API is used when
`OPENTHREAD_CONFIG_LOG_INSTANCE_AWARE_API_ENABLE` is enabled, allowing
the platform to receive the `otInstance` pointer with each log line.
The new API is implemented across:
- The simulation platform logging.
- The POSIX platform using `syslog()`.
- The NCP base to route logs to the NCP host.
- The CLI logging module.
- Unit tests and mock platforms.
The `OPENTHREAD_CONFIG_LOG_INSTANCE_AWARE_API_ENABLE` configuration is
also enabled for Toranj simulations to support multi-instance log
testing.
This commit updates the following `otPlatInfraIf` platform APIs to
include an `otInstance *` as their first parameter:
- `otPlatInfraIfHasAddress()`
- `otPlatInfraIfSendIcmp6Nd()`
- `otPlatInfraIfDiscoverNat64Prefix()`
Other APIs under `otPlatInfraIf` already follow this pattern. Passing
the `otInstance` pointer is the required standard for all platform
and public APIs; however, it was missed during the initial design of
these specific APIs.
While missing this parameter is often not a blocker on platforms using
a single OpenThread instance, it has become a blocker for simulations,
especially when multiple Border Routers are emulated in the same
simulation setup.
This change introduces a compatibility break for existing platform
implementations, however, it is necessary to support new use cases
(simulation of BRs). It also helps ensure consistent API design
across the stack.
This commit enhances the DHCPv6 PD prefix conflict detection logic
to check against Route Information Options (RIOs) present in received
Router Advertisements, in addition to the existing check against
on-link prefixes (PIOs).
The conflict detection behavior is event-driven to correctly handle
network propagation delays and valid advertisements:
1. On new prefix assignment (`kPdPrefixChanged`): A strict check is
performed. If the prefix matches any existing RIO from another
router, it is flagged as a conflict.
2. On RA table updates (`kRxRaPrefixTableChanged`): The check focuses
on conflict resolution. Crucially, it ignores new RIO matches
appearing after the prefix has been adopted. This is necessary
because once the BR publishes the PD prefix in Thread Network
Data as the OMR prefix, other BRs will naturally start
advertising it as a RIO to announce reachability.
The unit test `TestDhcp6PdConflict` is updated to verify both the
detection of conflict, its resolution, and that the subsequent RIO
advertisements do not cause a conflict after PD prefix is published
as OMR.
This commit updates `RoutingManager` to detect if a delegated DHCPv6
PD prefix conflicts with any on-link prefix advertised on the
infrastructure link.
This protects against potential DHCPv6 server misbehavior and bugs
where the same prefix might be assigned to multiple requesters.
If a conflict is detected, the delegated PD prefix is marked as
conflicted and is no longer used as the OMR prefix. Instead, we
revert to using the locally generated OMR prefix. If the conflict
is resolved, the delegated PD prefix is used again.
A new unit test `TestDhcp6PdConflict()` is added to verify this
behavior.
This change renames the `mInfraIfPrefix` in Nat64PrefixManager to
`mPlatformPrefix`.
The original name was ambiguous because both the RA-discovered prefix
`mRaTrackerPrefix` and this prefix are sourced from the infrastructure
link. The new name `mPlatformPrefix` clarifies that this prefix is
discovered through a platform-specific mechanism (e.g., DNS-based
discovery per RFC 7050), distinguishing it from prefixes discovered
directly via RA.
This commit updates the Multi-AIL Detection feature to operate
independently of the Border Routing Manager. This fundamental change
allows the detector to be enabled/disabled on its own, rather than
being tied to the Border Routing Manager's state.
This change also moves the Multi-AIL detection API into a separate
`openthread/multi_ail_detection.h` header and introduces new APIs to
control the detector independently. Corresponding CLI commands are
also added.
The `test-505-multi-ail-detection.py` is also updated to validate
this new independent behavior. In particular that a device that is
not enabled to act as a BR can independently run multi-AIL detection
and determine whether, if it becomes a BR, it will cause multi-AIL
issues.
This commit enhances the `TestNat64PrefixSelection` unit test by
adding more detailed verification of the RA-discovered NAT64 prefix
table managed by `RxRaTracker`.
This commit introduces support for discovering NAT64 prefixes as
specified in RFC 8781.
The key changes include:
- New `Nat64PrefixInfoOption`: A new `Nat64PrefixInfoOption` class is
added to represent the PREF64 option in ND messages. This handles
parsing the prefix and its lifetime from incoming RAs.
- `RxRaTracker` Enhancement: The `RxRaTracker` is updated to process
`Nat64PrefixInfoOption` from RAs. It now maintains a list of
discovered NAT64 prefixes from routers on the infrastructure link
and determines a "favored" prefix among them.
- `RoutingManager` Update: The `Nat64PrefixManager` is enhanced to
utilize the RA-discovered prefix.
- `test_routing_manager` Update: The `TestNat64PrefixSelection` is
updated to include cases with RA-discovered prefixes.
Adds a new state, `mInitialDiscoveryFinished`, to `RxRaTracker` to
track the completion of the initial router discovery (RS transmission)
process. A new method, `IsInitialRouterDiscoveryFinished()`, exposes
this state.
This new method replaces `IsRsTxInProgress()`, which previously
checked if any RS transmission was ongoing. The new model ensures
the initial discovery is tracked only once after `RxRaTracker`
starts, rather than every time RS messages are sent (e.g., due to
stale timer expiration).
Additionally, the `RoutingManager` now checks this state and ignores
incoming RS messages until the initial router discovery is complete.
This prevents the BR from replying to its own RS messages or sending
an RA prematurely with incomplete information before all routers
are discovered and decision factors are determined.
This commit separates the `RxRaTracker` logic from `RoutingManager`
into its own class and source files.
Previously, `RxRaTracker` was a nested class within `RoutingManager`.
This change moves it to `src/core/border_router/rx_ra_tracker.hpp`
and `src/core/border_router/rx_ra_tracker.cpp`, making it a
standalone class within the `ot::BorderRouter` namespace.
This separation improves modularity and prepares for future changes
where `RxRaTracker` may operate independently of `RoutingManager`.
Introduces a new `br_types.hpp` header and `br_types.cpp` source
file to centralize common data structures and type definitions used
across border router modules.
This change moves several classes from `routing_manager.hpp` to the
new `br_types.hpp` header. The moved classes include
`LifetimedPrefix`, `OnLinkPrefix`, `RoutePrefix`, `RdnssAddress`,
`IfAddress`, `OmrPrefix`, and `FavoredOmrPrefix`.
Additionally, common `typedef`s (e.g., `RoutePreference`,
`PrefixTableEntry`) and helper functions like `IsValidOmrPrefix()` are
relocated to the new files.
This improves the code structure by decoupling these shared types from
the main `RoutingManager` class, making them more reusable and easier
to maintain.
This change enhances `NetDataBrTracker` to support filtering of Border
Routers.
The `NetDataPeerBrTracker` is renamed to `NetDataBrTracker` to reflect
that it can now track all Border Routers, not just peers.
A new `Filter` enum is introduced with `kAllBorderRouters` and
`kExcludeThisDevice` options. This allows callers to specify whether
to include the current device in the list of Border Routers.
The `CountPeerBrs()` and `GetNext()` methods are updated to
`CountBrs()` and `GetNext()` respectively, and now accept a `Filter`
parameter.
This change provides more flexibility to the `NetDataBrTracker` and
makes the code more reusable. The unit tests are also updated to
clean up resources to avoid heap allocation leaks at the end of
tests.
Removes the `IsValidOnLinkPrefix()` helper functions which required a PIO
to have both the on-link (`L`) flag and either the autonomous address
configuration (`A`) or DHCPv6-PD preferred (`P`) flag to be considered
valid.
The `RxRaTracker` is updated to track any received valid PIO as long as
the on-link (`L`) flag is set, regardless of the `A` or `P` flags.
The `OnLinkPrefix` class is updated to store the state of the `A` and
`P` flags from the PIO. These flags are now checked within
`OnLinkPrefix::IsFavoredOver()` to determine if a prefix is eligible
to be a "favored" on-link prefix, but their absence no longer prevents
the prefix from being tracked.
This change ensures that the routing manager is aware of all non-ULA
on-link prefixes (even those with only the L flag set), which correctly
informs the decision to publish a default route.
This commit also:
- Updates `PrefixInfoOption` in `nd6.hpp` to use a `Flags` typedef and
named constants instead of bitmasks.
- Updates `LogPrefixInfoOption` to log the state of L, A, and P flags.
- Adds a new unit test, `TestNonUlaPioWithOnlyOnLinkFlag`, to verify
the new behavior.
This commit enables the `-Wimplicit-int-conversion` compiler flag for
`ftd`, `mtd`, and `radio` to improve code quality by detecting
potential data loss from implicit type conversions. This is enabled
when clang toolchain is used.
All resulting warnings have been addressed by either:
- Changing variable, parameter, or return types to ensure consistency
and prevent overflows.
- Adding explicit `static_cast` where the type conversion is intended
and safe.
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.
Jonathan Hui