Generic Address Assignment Option for 6LoWPAN Neighbor Discovery
draft-ietf-6lo-nd-gaao-11
| Document | Type | Active Internet-Draft (6lo WG) | |
|---|---|---|---|
| Authors | Luigi Iannone , David Lou , Adnan Rashid | ||
| Last updated | 2026-07-31 (Latest revision 2026-07-19) | ||
| Replaces | draft-iannone-6lo-nd-gaao | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Reviews |
INTDIR Early review
(of
-03)
by Brian Haberman
On the right track
GENART Early review
(of
-03)
by Joel Halpern
Almost ready
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Associated WG milestone |
|
||
| Document shepherd | Carles Gomez | ||
| Shepherd write-up | Show Last changed 2026-07-08 | ||
| IESG | IESG state | AD Evaluation::Revised I-D Needed | |
| Action Holders | |||
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | Éric Vyncke | ||
| Send notices to | carles.gomez@upc.edu |
draft-ietf-6lo-nd-gaao-11
6lo Working Group L. Iannone
Internet-Draft D. Lou
Intended status: Standards Track Huawei
Expires: 20 January 2027 A. Rashid
19 July 2026
Generic Address Assignment Option for 6LoWPAN Neighbor Discovery
draft-ietf-6lo-nd-gaao-11
Abstract
This document specifies an extension to the IPv6 Neighbor Discovery
in Low Power and Lossy Networks (LLNs), enabling a node to request to
be assigned an address or a prefix from neighbor routers, without
introducing a centralized infrastructure and without relying on
multicast messages. Such a mechanism makes it possible to
algorithmically assign addresses and prefixes to nodes in a 6LoWPAN
deployment. The proposed mechanism is more efficient in such
specific scenario with respect to DHCPv6.
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 20 January 2027.
Copyright Notice
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
Iannone, et al. Expires 20 January 2027 [Page 1]
Internet-Draft GAAO July 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Algorithmic and Distributed Address Assignment . . . . . 3
1.2. Limitations of DHCPv6 in Constrained LLNs . . . . . . . . 4
1.3. Generic Address Assignment Option (GAAO) . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Definition of Terms . . . . . . . . . . . . . . . . . . . 6
3. Algorithmically Assigned Addresses and Prefixes . . . . . . . 6
4. Generic Address Assignment Option Format . . . . . . . . . . 8
5. Messages Sequence and Processing . . . . . . . . . . . . . . 10
5.1. Request Phase . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Explicit Registration Phase (Optional) . . . . . . . . . 11
5.3. Message Exchange Optimization . . . . . . . . . . . . . . 12
5.3.1. GAAO with Router Discovery . . . . . . . . . . . . . 13
5.3.2. GAAO with Address Registration . . . . . . . . . . . 13
5.4. Error Conditions . . . . . . . . . . . . . . . . . . . . 14
6. Signaling GAAO Support . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.1. IPv6 Neighbor Discovery (ND) Option Types . . . . . . . . 15
7.2. 6LoWPAN Capability Bits . . . . . . . . . . . . . . . . . 15
7.3. GAAO Error code . . . . . . . . . . . . . . . . . . . . . 16
7.4. Address Assignment Function Registry . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Normative References . . . . . . . . . . . . . . . . . . . . . 18
Informative References . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Analytical comparison of GAAO and DHCPv6 . . . . . . 22
A.1. DHCPv6 Message Structure . . . . . . . . . . . . . . . . 22
A.2. GAAO Structure . . . . . . . . . . . . . . . . . . . . . 23
A.3. DHCPv6 vs GAAO Address Configuration . . . . . . . . . . 24
A.3.1. 6LoWPAN MTU Constraint . . . . . . . . . . . . . . . 25
A.4. Energy Consumption . . . . . . . . . . . . . . . . . . . 25
A.5. Multicast Inefficiency . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
Iannone, et al. Expires 20 January 2027 [Page 2]
Internet-Draft GAAO July 2026
1. Introduction
Low Power and Lossy Networks (LLNs) require adaptations of Internet
protocols to operate efficiently under constraints such as limited
energy, low data rates, constrained memory, and duty-cycled radio
operation. In many LLN deployments, the wireless interface is the
dominant source of energy consumption. As a result, protocol design
must minimize transmissions, idle listening, and the number of nodes
involved in control-plane operations.
IPv6 Neighbor Discovery (ND) was optimized for LLNs in [RFC6775] "ND
Optimization for 6LoWPANs" and later extended by [RFC8505]
"Registration Extensions for 6LoWPAN ND", [RFC8929] "IPv6 Backbone
Router", [RFC9010] "RPL", and [RFC9685] "Multicast and Anycast
Subscription". These specifications reduce multicast usage, limit
control-plane participation, and introduce explicit address
registration mechanisms to better support energy-constrained and
duty-cycled devices.
1.1. Algorithmic and Distributed Address Assignment
Recent work has demonstrated the benefits of algorithmically
structured addressing in constrained networks (e.g., [RFC9453] "6lo
Applicability and Use Cases",
[I-D.ietf-6lo-path-aware-semantic-addressing] "PASA", [SHENOY21],
[BLESS22], [RIDOUX05]). Such approaches can simplify routing, reduce
forwarding state, and improve scalability. These schemes often
require routers to assign addresses or prefixes according to a
distributed Address Assignment Function (AAF).
Existing mechanisms do not provide a standardized way, within the
optimized ND framework defined by [RFC8505], for a 6LoWPAN Node (6LN)
to explicitly request an address or prefix from a neighboring 6LoWPAN
Router (6LR).
In general IPv6 networks, address and prefix assignment are well
supported by Stateless Address Auto-Configuration (SLAAC) [RFC4862]
and DHCPv6 [RFC9915]. However, these mechanisms do not fully align
with the architectural and operational goals of RFC8505-based 6LoWPAN
deployments, particularly in scenarios requiring:
* Strict minimization of multicast traffic,
* Avoidance of centralized infrastructure,
* Localized control-plane interactions,
Iannone, et al. Expires 20 January 2027 [Page 3]
Internet-Draft GAAO July 2026
* Algorithmically structured address assignment to support routing
optimizations.
This document does not attempt to replace SLAAC or DHCPv6 in general
IPv6 networks. Instead, it addresses specifically 6LoWPAN LLNs
operating under RFC8505-based Neighbor Discovery optimizations, where
nodes may need to request addresses or prefixes, usually
algorithmically generated, directly from neighboring routers without
introducing a centralized infrastructure (e.g. DHCPv6). In scenarios
where a global centralized coordination of addresses and prefixes
assignment is necessary, DHCPv6 remains the recommended solution.
1.2. Limitations of DHCPv6 in Constrained LLNs
DHCPv6 relies on a client-server model and typically uses multicast
(e.g., Solicit messages sent to ff02::1:2). While DHCPv6 is
efficient in traditional IPv6 networks, including support for long
lifetimes and reduced renewal frequency, its architectural model does
not align with the distributed, strictly localized control-plane
design promoted by RFC8505-based 6LoWPAN Neighbor Discovery.
In IEEE 802.15.4 [IEEE802154] and similar LLNs, IPv6 multicast is
commonly mapped to link-layer broadcast ([RASHID24], [SELIEM17]).
Such broadcasts cause all nodes on the channel to wake up and process
the frame. In duty-cycled networks, this increases:
* Radio wake-ups,
* Idle listening time,
* Channel contention,
* Overall energy consumption.
Furthermore, DHCPv6 requires a reachable server, often via relay
agents, which may introduce multi-hop control paths and centralized
state management. In lossy multi-hop LLNs, longer control paths
increase failure probability and recovery cost. Further analysis is
presented in Appendix A.
1.3. Generic Address Assignment Option (GAAO)
This document specifies a new neighbor discovery option, the Generic
Address Assignment Option (GAAO), that enables a node to request an
address or prefix directly from a neighboring router using
RFC8505-based ND messages. The mechanism:
* Operates strictly at 1-hop,
Iannone, et al. Expires 20 January 2027 [Page 4]
Internet-Draft GAAO July 2026
* Avoids introducing a centralized infrastructure,
* Aligns with RFC8505 registration procedures,
* Supports distributed algorithmic address assignment.
GAAO complements the Extended Address Registration Option (EARO)
defined in [RFC8505] and its extensions, integrating address/prefix
assignment into the existing optimized ND framework for 6LoWPAN.
2. Terminology
2.1. Requirements Notation
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.
2.2. Acronyms
This document assumes familiarity with the terminology defined in
[RFC6775] "ND Optimization for 6LoWPANs", [RFC8505] "Registration
Extensions for 6LoWPAN ND", [RFC7136] IPv6 IID, [RFC4861] "IPv6
Neighbor Discovery", and [RFC4862] SLAAC. In particular for the
following acronyms:
*6CIO*: Capability Indication Option
*6LBR*: 6LoWPAN Border Router
*6LN*: 6LoWPAN Node
*6LoWPAN*: IPv6 over Low-Power Wireless Personal Area Network
*6LR*: 6LoWPAN Router
*AAF*: Address Assignment Function
*ARO*: Address Registration Option
*EARO*: Extended Address Registration Option
*GAAO*: Generic Address Assignment Option
*IID*: Interface IDentifier
Iannone, et al. Expires 20 January 2027 [Page 5]
Internet-Draft GAAO July 2026
*LLN*: Low-Power and Lossy Network
*NA*: Neighbor Advertisement
*ND*: Neighbor Discovery
*NS*: Neighbor Solicitation
*PfxLen*: Prefix Length
*RA*: Router Advertisement
*RS*: Router Solicitation
*SLAAC*: Stateless Address Auto-Configuration
*SLLAO*: Source Link-Layer Address Option
*TLLAO*: Target Link-Layer Address Option
2.3. Definition of Terms
*Address Assignment Function (AAF):* The Address Assignment Function
(AAF) is an implementation of the algorithm used by 6LRs/6LBR to
assign an address/prefix to requesting nodes. In order to avoid
addressing issues, only one AAF is used in a deployment. An AAF
assigns either addresses or prefixes but not both. This allows in
certain cases to indicate whether a node is requesting an address
or a prefix.
*GAAO:* Generic Address Assignment Option defined in this
specification (Section 4). GAAO is the exchange format an AAF can
use for address/prefix assignments, but it is not itself an AAF.
3. Algorithmically Assigned Addresses and Prefixes
The IPv6 address assignment model within a local layer-2 domain
relies on Interface Identifiers (IIDs) generated with various
techniques. These can be assigned using two main approaches: a
centralized approach using DHCPv6 ([RFC9915]), which guarantees
collision-free addresses, or a decentralized approach using SLAAC
([RFC4862]). Additional mechanisms are then required to ensure
address uniqueness, via Duplicate Address Detection (DAD) [RFC4862],
and security, like in Cryptographically Generated Addresses (CGA)
[RFC3972], or Secure Neighbor Discovery (SEND) [RFC3971]. However,
there is a third approach for address assignment, which is
distributed and collision-free: algorithmically generated addresses
(e.g., [SHENOY21], [BLESS22], [RIDOUX05], [ERIKSSON04]).
Iannone, et al. Expires 20 January 2027 [Page 6]
Internet-Draft GAAO July 2026
The Address Assignment Function (AAF) will work in a decentralized
and distributed fashion. The AAF is used to assign addresses and
prefixes to nodes as they join a network. To ensure consistency, all
6LoWPAN Nodes (6LNs), 6LoWPAN Routers (6LRs), and 6LoWPAN Border
Routers (6LBRs) MUST use the same AAF within a given network
instance. When a node needs an address/prefix, it first selects a
neighboring 6LR/6LBR from those that responded to its initial Router
Solicitation (RS) with a Router Advertisement (RA), as specified in
[RFC6775]. The node then sends an explicit request for an address/
prefix to the chosen 6LR/6LBR (see Section 5 for details about
messages sequence and processing). The 6LR/6LBR assigns the address/
prefix based on the AAF. Depending on the specific technology and
algorithm in use, the 6LR/6LBR will either implicitly register this
assignment to the requesting 6LN, or will indicate to the 6LN that an
explicit registration of the assigned address/prefix is necessary to
confirm its use. The overall process is illustrated in Figure 1.
6LN 6LR/6LBR
| |
1. | Address/Prefix Request | \
| --------------------------> | \
| | + Request Phase
2. | Address/Prefix Offer | /
| <-------------------------- | /
| |
3. | Address/Prefix Acceptance | \
| --------------------------> | \
| | + Optional Explicit
4. | Address/Prefix Confirmation | / Registration Phase
| <-------------------------- | /
| |
Figure 1: Address/Prefix assignment sequence.
The optional registration phase (steps 3 and 4) is implemented using
the address/prefix registration procedures defined in [RFC8505],
[RFC9685], or [RFC9926] "Prefix Registration". In this phase, an
Extended Address Registration Option (EARO) and SLLAO are used to
register an address/prefix, which, in this context, is not self-
generated. However, to initiate the process—specifically steps 1 and
2, a new Generic Address Assignment Option is required and defined in
this document. Because no existing mechanism can be readily used for
this purpose. The remainder of this document first defines the
format of this option (see Section 4), followed by a revised sequence
and processing of Address/Prefix assignment messages (see Section 5).
Iannone, et al. Expires 20 January 2027 [Page 7]
Internet-Draft GAAO July 2026
4. Generic Address Assignment Option Format
In order for a 6LN to request the assignment of an address or prefix,
GAAO message is used. The format of the GAAO message is shown in
Figure 2.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Status | Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|C|Rsvd | PfxLen | AAF | Assignment Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Registration Ownership Verifier (ROVR) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address/Prefix |
| (128 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Generic Address Assignment Option (GAAO) format.
Generic Address Assignment Option Fields:
*Type:* TBD
*Length:* 8-bit unsigned integer. The length of the option in units
of 8 octets. This field is set to 1 plus the size of the ROVR
field when there is no address/prefix appended to the option. Its
value is augmented by 2 (16 octets) when an address/prefix is
appended to the option.
*Status:* As defined in [RFC8505].
*Opaque:* As defined in [RFC8505].
*R:* 1-bit flag for explicit Registration being requested. It MUST
be initialized to 0 in Neighbor Solicitation (NS) messages by the
requester and MUST be ignored by the receiver. The 6LR/6LBR
replying to the request with a Neighbor Advertisement (NA) message
MAY set this bit to indicate that it requests a confirmation that
the address/prefix is accepted and will be used. When the
6LR/6LBR sets the R-flag in a NA(GAAO) message, it indicates that
no registration state has been created and that the requester MUST
explicitly register the received address/prefix to the same
Iannone, et al. Expires 20 January 2027 [Page 8]
Internet-Draft GAAO July 2026
6LR/6LBR using the procedures defined in [RFC8505], [RFC9926], and
[RFC9685], according to the type of the assigned address/prefix.
When the 6LR/6LBR does not set this R-flag, it indicates that the
assigned address/prefix has been also registered and state created
as specified in [RFC8505], [RFC9926], and [RFC9685], according to
the type of the assigned address/prefix. In the event that the
6LN does not want to use the allocated address/prefix, it can de-
register the allocation by sending an NS(EARO) setting
registration lifetime to zero, as defined in [RFC8505].
*C:* 1-bit flag for Crypto-ID used for ROVR as defined in [RFC8928]
"Address Protection ND for LLN" and [RFC9927] "Fixing C-FLag in
RFC 8928". This flag MUST be set when the ROVR field contains a
Crypto-ID.
*Reserved:* 3-bit reserved field for future use. It MUST be
initialized to 0 by the sender and MUST be ignored by the
receiver.
*PfxLen:* 7-bit unsigned integer. It indicates the length in bits
of the address/prefix carried in the option.
*AAF:* 4-bit unsigned integer. Describes the Address Assignment
Function (AAF), i.e. the algorithm, used to assign the address/
prefix. 0 is a special value indicating that the field is not
used. In an NS(GAAO) message, this field is set to 0 to indicate
that there is no preference on how the address/prefix is assigned.
However, a 6LN MAY use a value different from 0, to indicate that
it is requesting the use of a specific AAF to assign the address/
prefix. In the case that the requested AAF is not used in the
specific deployment, an error condition is returned, see
Section 5.4 for details. Section 7.4 describes possible values of
this field.
*Assignment Lifetime:* 16-bit unsigned integer, expressed in
minutes. In an NS(GAAO) message, the field expresses a desired
lifetime. It MAY be set to zero, indicating no particular desired
lifetime. In an NA(GAAO) message it expresses the granted
lifetime. A node MUST NOT use the address/prefix after expiration
of the lifetime. Address/prefix lifetime MUST be configurable
according to the AAF in use and as mitigation of certain attacks
(see Section 8).
*ROVR:* As defined in [RFC8505] and extended in [RFC8928] and
[RFC9927].
*Address/Prefix:* 128-bit IPv6 address/prefix. This field MAY be
Iannone, et al. Expires 20 January 2027 [Page 9]
Internet-Draft GAAO July 2026
present in NS(GAAO) request messages to indicate the prefix from
which the address or sub-prefix has to be derived. If not present
in an NS(GAAO) message, it means that the address returned in an
NA(GAAO) message is implicitly used on the interface used to send
the request. This field MUST be present in NA(GAAO) messages that
return a successful address/prefix allocation, but MUST NOT be
present in case of error. When the field is used return a prefix,
the leftmost bits are used for its encoding according to the
length field, the remaining bits are set to zero. The presence of
this field is indicated by the length field (cf. above).
5. Messages Sequence and Processing
When a node bootstraps (or in case of a neighbor unreachability
detection), it sends an RS message via multicast and receives one or
more unicast RA messages from neighbor 6LRs. The node MAY choose one
or more 6LRs from which to request address(es) or prefix(es). A node
MAY perform a request at any time, not necessarily at boot time,
using NS and NA messages.
5.1. Request Phase
When the node requests an address/prefix, the node will go through
the following steps:
1. The node will issue an NS(GAAO) message to obtain the address/
prefix. In this initial address request, GAAO Status field MUST
be set to 0. Opaque, ROVR, and C-flag are set according to the
local configuration. R-Flag MUST be set to 0. The AAF field
MUST be set to zero unless by configuration there is a preference
for the assignment algorithm. The Assignment Lifetime field MAY
be set to the desired lifetime, or zero otherwise. The Address/
Prefix field MAY be present to indicate the prefix from which the
address or sub-prefix has to be derived. In this case the PfxLen
field MUST be set accordingly. If the Address/Prefix field is
not present, the PfxLen field MUST be set to 0.
2. Assuming no errors occur, the node will receive an NA(GAAO)
message where all fields have been copied back except for:
* *Pfxlen:* Now indicating the actual length of the prefix. For
address assignments this field MUST be set to 64.
* *R:* The R-bit is set if the 6LR requests an explicit
registration.
Iannone, et al. Expires 20 January 2027 [Page 10]
Internet-Draft GAAO July 2026
* *AAF:* It is the algorithm, used to assign the address/prefix.
If the node is a 6LR it MUST use the same AAF to generate
addresses/prefixes to requesting neighbor nodes in the 6LoWPAN
network.
* *Assignment Lifetime:* The maximum lifetime of the assigned
address/prefix.
The message sequence is depicted in Figure 3.
6LN 6LR/6LBR
| |
| ===== RS-RA Transaction Completed ====== |
| |
| |
| Address/Prefix Request |
1. | ---------------------------------------> |
| NS (GAAO) |
| |
| Address/Prefix Offer |
2. | <--------------------------------------- |
| NA (GAAO) |
| |
Figure 3: Address/Prefix assignment message sequence.
5.2. Explicit Registration Phase (Optional)
Depending on the algorithm in use and the underlying technology, the
address/prefix assignment procedure terminates after these two
messages. This may be sufficient for instance in deployments where
the link-layer offers reliable packet delivery. The use of this
option is done by configuration on 6LRs. Documents defining AAFs
MUST explicitly state whether this phase remains optional or is
mandatory due to factors specific to the proposed algorithm.
If the R-flag is set in the received NA(GAAO) message, the 6LN MUST
register with the obtained address/prefix by following the procedures
in [RFC8505], [RFC9685], or [RFC9926] depending on the type of
address/prefix. When setting the R-flag, and as for [RFC4861], the
6LR is expected to receive a registration within RETRANS_TIMER
multiplied by MAX_UNICAST_SOLICIT. If no registration is received
within this amount of time the 6LR will consider that address/prefix
is not in use by the requesting 6LN.
The complete sequence of actions is depicted in Figure 4.
Iannone, et al. Expires 20 January 2027 [Page 11]
Internet-Draft GAAO July 2026
6LN 6LR/6LBR
| |
| ====== RS-RA Transaction Completed ====== |
| |
| Address/Prefix Request |
1. | -------------------------------------------> |
| NS(GAAO) |
| |
| Address/Prefix Offer |
2. | <------------------------------------------- |
| NA(GAAO) |
| |
| Address/Prefix Registration Request |
3. | -------------------------------------------> |
| NS(EARO + SLLAO) |
| |
...
Procedure According to [RFC8505], [RFC9685],
or [RFC9926] depending on the type
of address.
...
| |
| Address/Prefix Registration Response |
4. | <------------------------------------------- |
| NA(EARO with Status + SLLAO) |
| |
Figure 4: Address/Prefix assignment message sequence with explicit
registration.
[RFC8505], [RFC9685], and [RFC9926], define how nodes keep address/
prefix registration state in order to maintain addressing in case of
reboot. When needed, in order to use this feature with GAAO, after
reboot the registration phase MUST be used to perform an explicit
registration and continue using the address/prefix. However, when
using GAAO, and when performing the re-registration, if a
"Registration Refresh Request" or "Invalid Registration" Status value
is returned, the node MUST restart from the top with the initial
Request Phase.
5.3. Message Exchange Optimization
There are two ways to optimize the prefix/address Request Phase: GAAO
with Address Registration and GAAO with Router Discovery.
Iannone, et al. Expires 20 January 2027 [Page 12]
Internet-Draft GAAO July 2026
5.3.1. GAAO with Router Discovery
Another optimization for prefix/address requests can be performed
during the bootstrapping phase of a 6LN. The GAAO MAY be included in
the initial RS message, thereby implicitly indicating that the node
supports this specification. Similarly, 6LR/6LBR that support this
specification MUST include a prefix/address offer in a GAAO appended
to the corresponding RA message, as depicted in Figure 5.
6LN 6LR/6LBR
| |
| RS message |
1. | ---------------------------------------> |
| (6CIO + SLLAO + GAAO) |
| |
| RA message |
2. | <--------------------------------------- |
| (PIO + 6CIO + ABRO + SLLAO + GAAO) |
| |
Figure 5: GAAO piggybacking with Router Discovery.
A 6LR/6LBR that does not support GAAO will simply ignore this option,
and the corresponding RA message will not include a GAAO. This
behavior implicitly signals that the feature is not supported.
5.3.2. GAAO with Address Registration
Prefix/address Registration utilize NS/NA transactions for the link-
local address registration [RFC8505]. In this specification, the
prefix/address Request procedure utilizes an additional NS/NA
transaction. To minimize the number of transactions, GAAO MAY be
used together with the EARO option during address registration phase.
This piggybacking approach provides flexibility and maintains
compatibility with existing specifications [RFC8505]. In response
the NA message will contain GAAO. Figure 6 illustrates the GAAO
piggybacked within a link-layer address registration request and
response. Piggybacking can be done within the MTU limit of the
underlying technology, since ND messages cannot be fragmented.
Iannone, et al. Expires 20 January 2027 [Page 13]
Internet-Draft GAAO July 2026
6LN 6LR/6LBR
| |
| Address Registration Request |
1. | ---------------------------------------> |
| NS(EARO + SLLAO + GAAO) |
| |
| Address Registration Response |
2. | <--------------------------------------- |
| NA(EARO with Status + SLLAO + GAAO) |
| |
Figure 6: GAAO piggybacking with link-layer Address Registration.
5.4. Error Conditions
GAAO Status field uses the same Status values defined in [RFC6775]
and [RFC8505], further revised in [RFC9010], for error reporting.
This specification introduces a new Status value when the AAF in GAAO
in an NS message is not in use in the 6LoWPAN network, as follows
(see also Section 7):
*AAF Not Used:* The AAF in GAAO in the NS message is not in use in
the 6LoWPAN network.
This status MUST be used when a node requesting an address/prefix has
set an AAF value, in the corresponding field, which is not in use in
the 6LoWPAN network. When the node receives this status back it
SHOULD perform one of the following actions:
* Re-issue the same request without specifying an AAF, meaning set
the AAF field to 0. The 6LR will return the AAF in use in the
6LoWPAN network and employed to generate the returned address/
prefix. If the requesting node does not support the returned AAF
it does not participate in the AAF-based 6LoWPAN network and does
not use the proposed address/prefix.
* Re-issue the same request with a different AAF. The 6LoWPAN
network is not using the requested AAF but may be using a
different one. Note that such an approach may lead to repeated
requests that may consume bandwidth and energy.
* Do nothing and do not participate in the AAF-based 6LoWPAN
network.
The action to be used is selected by configuration. When nodes fail
to participate in the AAF-based 6LoWPAN network they MAY still use a
different mechanism (e.g., [RFC8505]) to configure addresses/
prefixes.
Iannone, et al. Expires 20 January 2027 [Page 14]
Internet-Draft GAAO July 2026
6. Signaling GAAO Support
This specification defines a new capability bit, named M-flag, for
use in the 6CIO as defined by [RFC7400] Section 3.3 ("6LoWPAN-GHC:
Generic Header Compression for IPv6 over Low-Power Wireless Personal
Area Networks"). A 6LN that supports this specification MUST set the
M-flag in RS and RA messages.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 1 | Reserved |X|A|D|L|B|P|E|G|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: New GAAO Capability Bit in the 6CIO.
*M:* 1-bit flag. The node supports managed addresses/prefixes via
the Generic Address Assignment Capability.
7. IANA Considerations
This section requests that Internet Assigned Numbers Authority (IANA)
registers values related to the GAAO specification, in accordance
with BCP 26 [RFC8126].
7.1. IPv6 Neighbor Discovery (ND) Option Types
IANA is requested to make an addition to the "IPv6 Neighbor Discovery
Option Formats" registry [NDOPTIONS], under the heading "Internet
Control Message Protocol version 6 (ICMPv6) Parameters", as indicated
in Table 1:
+======+===================================+=================+
| Type | Description | Reference |
+======+===================================+=================+
| TBD | Generic Address Assignment Option | [This Document] |
+------+-----------------------------------+-----------------+
Table 1: New Generic Address Assignment Option.
7.2. 6LoWPAN Capability Bits
IANA is requested to make an addition to the "6LoWPAN Capability
Bits" registry [CAPABILITYBITS], under the registry group "Internet
Control Message Protocol version 6 (ICMPv6) Parameters", as indicated
in Table 2:
Iannone, et al. Expires 20 January 2027 [Page 15]
Internet-Draft GAAO July 2026
+================+============================+===========+
| Bit | Description | Reference |
+================+============================+===========+
| 17 (Suggested) | M-Flag for Generic Address | [This |
| | Assignment Capability | Document] |
+----------------+----------------------------+-----------+
Table 2: New 6LoWPAN Capability Bit.
7.3. GAAO Error code
IANA is requested to make an addition to the "Address Registration
Option Status Values" registry [OPTIONSTATUS], under the registry
group "Internet Control Message Protocol version 6 (ICMPv6)
Parameters", as indicated in Table 3:
+================+==============+=================+
| Value | Description | Reference |
+================+==============+=================+
| 13 (Suggested) | AAF Not Used | [This Document] |
+----------------+--------------+-----------------+
Table 3: New Address Registration Option Status
Field Value.
7.4. Address Assignment Function Registry
IANA is asked to create a registry group named "6LoWPAN Generic
Address Assignment Option", under the registry group "Internet
Control Message Protocol version 6 (ICMPv6) Parameters".
Such registry group should be populated with an octet registry named
"Address Assignment Function" and used to identify the used AAF. The
registry is populated as shown in Table 4:
Iannone, et al. Expires 20 January 2027 [Page 16]
Internet-Draft GAAO July 2026
+=========+================================+===========+
| Value | AAF Name | Reference |
+=========+================================+===========+
| 0x0 | No AAF. This can be used only | [This |
| | in NS message to indicate that | Document] |
| | no specific AAF is demanded. | |
+---------+--------------------------------+-----------+
| 0x1-0xE | Un-assigned | |
+---------+--------------------------------+-----------+
| 0xF | Experimental Use. Used for | [This |
| | experimental purposes during | Document] |
| | implementation of new AAFs. | |
+---------+--------------------------------+-----------+
Table 4: Allocation Function Sub-registry
Values can be assigned by IANA, after this document is published,
using the "RFC Required" procedure according to [RFC8126].
8. Security Considerations
This document extends [RFC8505], which already extended [RFC6775], as
such the security considerations of both documents apply to this
specification. In particular, the link layer MUST provide sufficient
protection to prevent potential attacks. Recommendations listed in
Section 7 of [RFC8505] MUST be applied as well to this specification.
Depending on the AAF in use, the number of available addresses may
encounter limitations. A rouge node may leverage on this knowledge
to carry out address exhaustion attacks by impersonating different
nodes and performing multiple requests. To mitigate such risks the
recommendation about the lifetime and number of addresses per node
described in Section 7 of [RFC8505] remains valid.
Furthermore, depending on the AAF, the algorithmically built
addresses may reveal topological or other private information.
Documents specifying a new AAF MUST discuss such aspects.
Acknowledgements
This document received many comments and help from community people.
The authors would like to thank all of them. Thanks as well to Joel
Halpern (GENART) and Brian Haberman (INTDIR) for their reviews that
helped to spot overlooked points in the definition of the GAAO
mechanism. Thanks to Pascal Thubert for his help in making this
specification more integrated with existing 6LoWPAN specifications.
Thanks to Carles Gomez Montenegro for his very thorough shepherd
review. Thanks to Lorenzo Colitti for helping to clarify the scope
Iannone, et al. Expires 20 January 2027 [Page 17]
Internet-Draft GAAO July 2026
of GAAO with respect to DHCPv6. Thanks to Eric Vyncke for the
excellent AD review.
References
Normative References
[CAPABILITYBITS]
"6LoWPAN Capability Bits", n.d.,
<https://www.iana.org/assignments/icmpv6-parameters/
icmpv6-parameters.xhtml#sixlowpan-capability-bits>.
[NDOPTIONS]
"IPv6 Neighbor Discovery Option Formats", n.d.,
<https://www.iana.org/assignments/icmpv6-parameters/
icmpv6-parameters.xhtml#icmpv6-parameters-5>.
[OPTIONSTATUS]
"Address Registration Option Status Values", n.d.,
<https://www.iana.org/assignments/icmpv6-parameters/
icmpv6-parameters.xhtml#address-registration>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/rfc/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/rfc/rfc4862>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/rfc/rfc6775>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
February 2014, <https://www.rfc-editor.org/rfc/rfc7136>.
Iannone, et al. Expires 20 January 2027 [Page 18]
Internet-Draft GAAO July 2026
[RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November
2014, <https://www.rfc-editor.org/rfc/rfc7400>.
[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,
<https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/rfc/rfc8505>.
[RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik,
"Address-Protected Neighbor Discovery for Low-Power and
Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November
2020, <https://www.rfc-editor.org/rfc/rfc8928>.
[RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli,
"IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929,
November 2020, <https://www.rfc-editor.org/rfc/rfc8929>.
[RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL
(Routing Protocol for Low-Power and Lossy Networks)
Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021,
<https://www.rfc-editor.org/rfc/rfc9010>.
[RFC9685] Thubert, P., Ed., "Listener Subscription for IPv6 Neighbor
Discovery Multicast and Anycast Addresses", RFC 9685,
DOI 10.17487/RFC9685, November 2024,
<https://www.rfc-editor.org/rfc/rfc9685>.
[RFC9926] Thubert, P., Ed., "Prefix Registration for IPv6 Neighbor
Discovery", RFC 9926, DOI 10.17487/RFC9926, February 2026,
<https://www.rfc-editor.org/rfc/rfc9926>.
[RFC9927] Thubert, P. and A. Rashid, "Fixing the C-Flag in the
Extended Address Registration Option (EARO)", RFC 9927,
DOI 10.17487/RFC9927, February 2026,
<https://www.rfc-editor.org/rfc/rfc9927>.
Iannone, et al. Expires 20 January 2027 [Page 19]
Internet-Draft GAAO July 2026
Informative References
[BLESS22] Bless, R., Zitterbart, M., Despotovic, Z., and A. Hecker,
"KIRA: Distributed Scalable ID-based Routing with Fast
Forwarding", 2022 IFIP Networking Conference (IFIP
Networking) pp. 1-9,
DOI 10.23919/ifipnetworking55013.2022.9829816, June 2022,
<https://doi.org/10.23919/
ifipnetworking55013.2022.9829816>.
[ERIKSSON04]
Eriksson, J., Faloutsos, M., and S. Krishnamurthy,
"Scalable ad hoc routing: the case for dynamic
addressing", IEEE INFOCOM 2004 vol. 2, pp. 1108-1119,
DOI 10.1109/infcom.2004.1356997, February 2005,
<https://doi.org/10.1109/infcom.2004.1356997>.
[FOURTY12] Fourty, N., van den Bossche, A., and T. Val, "An advanced
study of energy consumption in an IEEE 802.15.4 based
network: Everything but the truth on 802.15.4 node
lifetime", Computer Communications vol. 35, no. 14, pp.
1759-1767, DOI 10.1016/j.comcom.2012.05.008, August 2012,
<https://doi.org/10.1016/j.comcom.2012.05.008>.
[I-D.ietf-6lo-path-aware-semantic-addressing]
Iannone, L., Li, G., Lou, D., Liu, P., and P. Thubert,
"Path-Aware Semantic Addressing (PASA) for Low power and
Lossy Networks", Work in Progress, Internet-Draft, draft-
ietf-6lo-path-aware-semantic-addressing-15, 19 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-6lo-
path-aware-semantic-addressing-15>.
[IEEE802154]
"IEEE Standard for Low-Rate Wireless Networks",
IEEE standard, DOI 10.1109/ieeestd.2016.7460875, April
2016, <https://doi.org/10.1109/ieeestd.2016.7460875>.
[OZTOPRAK24]
Oztoprak, A., Hassanpour, R., Ozkan, A., and K. Oztoprak,
"Security Challenges, Mitigation Strategies, and Future
Trends in Wireless Sensor Networks: A Review", ACM
Computing Surveys vol. 57, no. 4, pp. 1-29,
DOI 10.1145/3706583, December 2024,
<https://doi.org/10.1145/3706583>.
Iannone, et al. Expires 20 January 2027 [Page 20]
Internet-Draft GAAO July 2026
[RASHID24] Rashid, A. and T. Pecorella, "Is 6LoWPAN-ND necessary?
(Spoiler alert: Yes)", Computer Networks vol. 250, pp.
110535, DOI 10.1016/j.comnet.2024.110535, August 2024,
<https://doi.org/10.1016/j.comnet.2024.110535>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005,
<https://www.rfc-editor.org/rfc/rfc3971>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/rfc/rfc3972>.
[RFC9119] Perkins, C., McBride, M., Stanley, D., Kumari, W., and JC.
Zúñiga, "Multicast Considerations over IEEE 802 Wireless
Media", RFC 9119, DOI 10.17487/RFC9119, October 2021,
<https://www.rfc-editor.org/rfc/rfc9119>.
[RFC9453] Hong, Y., Gomez, C., Choi, Y., Sangi, A., and S.
Chakrabarti, "Applicability and Use Cases for IPv6 over
Networks of Resource-constrained Nodes (6lo)", RFC 9453,
DOI 10.17487/RFC9453, September 2023,
<https://www.rfc-editor.org/rfc/rfc9453>.
[RFC9915] Mrugalski, T., Volz, B., Richardson, M., Jiang, S., and T.
Winters, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", STD 102, RFC 9915, DOI 10.17487/RFC9915,
January 2026, <https://www.rfc-editor.org/rfc/rfc9915>.
[RIDOUX05] Ridoux, J., Fladenmuller, A., Viniotis, Y., and K.
Salamatian, "Trellis-Based Virtual Regular Addressing
Structures in Self-organized Networks", Lecture Notes in
Computer Science pp. 511-522, DOI 10.1007/11422778_41,
2005, <https://doi.org/10.1007/11422778_41>.
[SELIEM17] Seliem, M., Elsayed, K., and A. Khattab, "Optimized
neighbor discovery for 6LoWPANs: Implementation and
performance evaluation", Computer Communications vol. 112,
pp. 73-92, DOI 10.1016/j.comcom.2017.08.013, November
2017, <https://doi.org/10.1016/j.comcom.2017.08.013>.
[SHENOY21] Shenoy, N., Chandraiah, S., and P. Willis, "A Structured
Approach to Routing in the Internet", 2021 IEEE 22nd
International Conference on High Performance Switching and
Routing (HPSR) pp. 1-6,
DOI 10.1109/hpsr52026.2021.9481818, June 2021,
<https://doi.org/10.1109/hpsr52026.2021.9481818>.
Iannone, et al. Expires 20 January 2027 [Page 21]
Internet-Draft GAAO July 2026
Appendix A. Analytical comparison of GAAO and DHCPv6
DHCPv6 is typically used in traditional Ethernet or Wi-Fi networks,
it is rarely used in 6LoWPAN (IPv6 over Low-Power Wireless Personal
Area Networks) deployments for several critical reasons rooted in
efficiency and resource constraints. [RFC9119] considers that the
use of multicast transmissions over IEEE 802 wireless technologies
may create issues related to:
* Reliability;
* Lower and variable data rate;
* Capacity and impact on interference;
* Power-save effects on multicast;
Hence, the intensive use of multicast may not be optimal. [RFC9119]
lists DHCPv6 [RFC9915] among the protocols that make an extensive use
of multicast. Neighbor Discovery is also listed, as multicast
optimization in this protocol is one of the reasons that lead to the
6LoWPAN protocol stack development (cf. [RFC6775] and [RFC8505]). An
extensive study comparing [RFC4861] and [RFC6775], showing the
inefficiency of the former in 6LoWPAN deployments, can be found in
[SELIEM17].
In rare cases, Stateless DHCPv6 is used in 6LoWPAN just to pass
"Other" information (like DNS server addresses or NTP servers) if the
Router Advertisements don't provide them. However, for actual
address assignment, it is almost non-existent in the context of
6LoWPAN. In 6LoWPAN deployments, the use of DHCPv6 entails running
an additional service on the 6LRs, beside the 6LoWPAN ND. Running an
additional service will have impact on memory usage and battery
lifetime. GAAO requires only that the implementation supports the
GAAO option, as it is part of the 6LoWPAN ND already present and
running, hence, preserving the efficiency of [RFC6775] as shown in
[SELIEM17].
A.1. DHCPv6 Message Structure
A typical DHCPv6 exchange involves four messages:
1. Solicit (from 6LN to server - multicast)
2. Advertise (from server to 6LN - unicast)
3. Request (from 6LN to server - multicast)
Iannone, et al. Expires 20 January 2027 [Page 22]
Internet-Draft GAAO July 2026
4. Reply (from server to 6LN - unicast)
Message payload (not including link/IPv6/UDP headers):
* Solicit: 30 octets (minimal size - typical 80 to 150 octets)
* Advertise: 32 octets (minimal size - typical 100 to 180 octets)
* Request: 38 octets (minimal size - typical 80 to 150 octets)
* Reply: 32 octets (minimal size - typical 100 to 200 octets)
Size of a minimal exchange: 132 octets (or 70 octets when using Rapid
Commit option).
DHCPv6 needs dedicated messages which are multicast (depending on the
message type) and may span several layer-2 links depending on where
the server is placed. As such, channel access and headers' overhead
cannot be shared with other messages. In a simple deployment with
the server directly accessible on the same layer-2 link, four
different messages are necessary with the first and the third being
multicast. DHCPv6 includes a "Rapid Commit" option that reduces the
exchange to only two messages, namely a Solicit and a Reply, with the
first being multicast.
A.2. GAAO Structure
A typical GAAO exchange involves two messages, each one carrying one
GAAO option:
1. GAAO in NS (from 6LN to 6LR - unicast)
2. GAAO in NA (from 6LR to 6LN - unicast)
Option size: - *GAAO option* (24 octets in NS messages and 40 octets
on NA messages)
Size of a typical exchange: 62 octets.
GAAO does not need to be transmitted on dedicated messages. It can
be piggybacked on ND messages carrying other options, hence sharing
the channel access and headers' overhead with these other options.
If not piggybacked, the exchange requires two unicast messages. In
both cases the exchange takes place on one single layer-2 link.
Iannone, et al. Expires 20 January 2027 [Page 23]
Internet-Draft GAAO July 2026
A.3. DHCPv6 vs GAAO Address Configuration
From an abstract point of view, for a 6LN to obtain an address
several messages need to be exchanged, as summarized in Table 5.
+==============+==================+===========+==========+==========+
| | Octets | Multicast | Unicast | L2 links |
| | Exchanged | Messages | Messages | |
+==============+==================+===========+==========+==========+
| DHCPv6 | 142 | 2 | 2 | multiple |
+--------------+------------------+-----------+----------+----------+
| DHCPv6 Rapid | 70 | 1 | 1 | multiple |
| Commit | | | | |
+--------------+------------------+-----------+----------+----------+
| GAAO | 62 | 0 | 2 | 1 |
+--------------+------------------+-----------+----------+----------+
Table 5: Number, type, and size of messages to configure an
address on a 6LN.
In generic and realistic 6LoWPAN deployments, the GAAO option can be
piggybacked on other ND messages, hence sharing header and channel
access overhead, and it is just transmitted 1-hop away. DHCPv6,
cannot share such overhead with other data, specific packets need to
be sent per each message. Additionally, unicast messages may span
several hops, since the DHCPv6 server is usually deployed on the
6LBR, consuming network resources (e.g., energy, network bandwidth)
and experiencing higher latency. The multicast message may even
trigger a (resource expensive) network wide broadcast, as explained
in Appendix A.5.
Address renewal bears a similar cost for both DHCPv6 and GAAO in
terms of size, with GAAO having a slightly smaller message length,
assuming DHCPv6 packets use the minimal size. The difference lays in
the fact that in DHCPv6, the Renew message is also a multicast
message, and that messages may traverse several hops, to reach the
DHCPv6 server, hence consuming more resources (e.g., energy, network
bandwidth, etc.). In case of dense and noisy environment, with
higher likelihood of packet losses, this may lead to nodes not being
able to renew the DHCPv6 address lease, and the node needing to
restart address request using the multicast-based 4-packets exchange.
Iannone, et al. Expires 20 January 2027 [Page 24]
Internet-Draft GAAO July 2026
A.3.1. 6LoWPAN MTU Constraint
6LoWPAN deployments may have very small MTU limits. For instance,
IEEE 802.15.4 frame size is only 127 octets (max PHY layer payload).
Assuming that DHCPv6 is configured to use the bare minimal options,
there should be no MTU issues neither for DHCPv6 nor GAAO. If the
minimal options condition is not respected, fragmentation may be
needed for DHCPv6 large messages, increasing delay and energy
consumption. GAAO has a fixed size, hence the only consequence is
that it can be piggybacked with other options only if the MTU limit
is respected.
A.4. Energy Consumption
Since DHCPv6 has to deliver almost twice the number of octets
compared to GAAO, in terms of pure energy/octet consumption DHCPv6
uses almost double the energy. Because the number of messages is
also doubled, there is an additional overhead due to 6LN accessing
the channel four times, with nodes staying awake longer which in turn
consumes more energy. Any communication pattern that forces many
nodes to wake up and receive packets (such as broadcast or multicast)
has a disproportionately large impact on battery lifetime [FOURTY12].
A.5. Multicast Inefficiency
It is worth noting that the unicast messages are all 1-hop, while the
multicast messages must be distributed to the whole network
[RASHID24]. Furthermore, multicast in 6LoWPAN is inefficient due to
the actual lack of multicast support at lower layers, which is
emulated either via broadcast or via unicast floods. Broadcast is
generally less energy-efficient than unicast for targeted
communication because it sends packets to all nodes, including those
not interested in the data, no ACKs are used, so retransmissions for
reliability must be handled at higher layers, potentially increasing
energy usage, and all nodes must wake up and process the broadcast
packet, even if they are not the intended recipients ([FOURTY12],
[OZTOPRAK24]). Unicast floods may increase reliability, however,
depending on the topology it may lead to higher latency and increased
energy consumption.
Authors' Addresses
Luigi Iannone
Huawei Technologies France S.A.S.U.
18, Quai du Point du Jour
92100 Boulogne-Billancourt
France
Email: ggx@gigix.net
Iannone, et al. Expires 20 January 2027 [Page 25]
Internet-Draft GAAO July 2026
David Lou
Huawei Technologies Duesseldorf GmbH
Riesstrasse 25
80992 Munich
Germany
Email: zhe.lou@huawei.com
Adnan Rashid
Email: adnanrashidpk@gmail.com
Iannone, et al. Expires 20 January 2027 [Page 26]