Dear GAAO authors, all,
In my role of shepherd for draft-ietf-6lo-nd-gaao, and while 6man may still
provide further feedback in the next ~10 days, I have reviewed the document
(version -07).
In my opinion, the document is generally well written, clear, and complete.
Thanks for the work!
Most of my comments are editorial (there are a few minor technical ones).
Please find below my review (my comments are labeled '[CG]' and/or signaled
with '^^^').
Cheers,
Carles
----------------------------------------------------------------------------------------
6lo Working Group L. Iannone
Internet-Draft D. Lou
Intended status: Standards Track Huawei
Expires: 6 March 2026 A. Rashid
Politecnico di Bari
2 September 2025
Generic Address Assignment Option for 6LoWPAN Neighbor Discovery
draft-ietf-6lo-nd-gaao-07
Abstract
This document specifies a new 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.
Such mechanism allows to algorithmically assign addresses and
prefixes to nodes in a 6LoWPAN deployment.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 6 March 2026.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Iannone, et al. Expires 6 March 2026 [Page
1]Internet-Draft GAAO September
2025
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Definition of Terms . . . . . . . . . . . . . . . . . . . 5
3. Algorithmically Assigned Addresses and Prefixes . . . . . . . 5
4. Generic Address Assignment Option . . . . . . . . . . . . . . 6
5. Messages Sequence and Processing . . . . . . . . . . . . . . 9
5.1. Request Phase . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Explicit Registration Phase (Optional) . . . . . . . . . 10
5.3. Message Exchange Optimization . . . . . . . . . . . . . . 11
5.3.1. GAAO with Address Registration . . . . . . . . . . . 12
5.3.2. GAAO with Router Discovery . . . . . . . . . . . . . 12
5.4. Error Conditions . . . . . . . . . . . . . . . . . . . . 13
6. Signaling GAAO Support . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. IPv6 Neighbor Discovery (ND) Option Types . . . . . . . . 14
7.2. 6LoWPAN Capability Bits . . . . . . . . . . . . . . . . . 15
7.3. GAAO Error code . . . . . . . . . . . . . . . . . . . . . 15
7.4. Address Assignment Function Registry . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Normative References . . . . . . . . . . . . . . . . . . . . . 16
Informative References . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
Low Power and Lossy Networks (LLNs) have adapted the design of
^^^^^^^
[CG] s/adapted/required adapting
Internet protocols to more constrained environments, by taking into
consideration of energy saving, limited memory capacity, and duty
^^
[CG] please remove "of"
cycling of the LLN devices, as well as low-power lossy transmissions.
^^^^^^^^^^^^^^^
[CG] s/low-power lossy/low-power and lossy
Since the wireless interface is a major energy drain, protocols
aiming at being deployed over LLN must be designed in such a way to
^^^
[CG] s/LLN/LLNs
reduce as much as possible transmissions, allowing to turn off the
^^^^^^^^^^^^^
[CG] perhaps "and idle listening" may be added after "transmissions"
radio interface or put the interface or the whole node in the
Iannone, et al. Expires 6 March 2026 [Page
2]Internet-Draft GAAO September
2025
sleeping mode.
IPv6 Neighbor Discovery has been also adapted to the LLN environment
in [RFC6775], later updated by [RFC8505], [RFC8929], and [RFC9010].
The target being to design protocols that reduce energy consumption,
^^^^^
[CG] s/being/has been
especially in LLNs, though in general their design could be applied
in any context targeting lowering carbon emissions. In particular,
interface address assignment relies on address auto-configuration
(such as Stateless Address Autoconfiguration (SLAAC)[RFC4862]), since
the use of Dynamic Host Configuration Protocol (DHCP [RFC8415]) is
not adapted, from an energy and bandwidth perspective, to LLN
deployments. Indeed, LLN environments aim at avoiding as much as
possible asynchronous multicast operations, because that would keep
nodes awake and listening. Furthermore, it is also preferable to
reduce as much as possible the number of nodes involved in control
plane operations, because of energy and bandwidth constraints typical
of LLN. DHCP can still be used in Internet-of-Things (IoT)
deployments where energy and bandwidth are not an issue.
To avoid multicast operations and to limit the number of nodes
involved in address assignment in LLN, mechanisms to register self-
^^^
[CG] s/LLN/LLNs
generated addresses have been designed ([RFC6775],
[I-D.ietf-6lo-prefix-registration], [RFC8505], [RFC9685]).
Recent use cases show, however, that there are some advantages in
assigning addresses in an algorithmically managed way. In
particular, in some scenarios, routing and forwarding can be
simplified ([RFC9453], [I-D.ietf-6lo-path-aware-semantic-addressing],
[SHENOY21], [BLESS22], [RIDOUX05]), hence reducing the power
consumption and memory footprint. Algorithmic address assignment has
its own pros and cons, as well as deployment requirements. However,
they have the common benefit of being easily distributed. In other
words, it is not necessary to have a centralized approach, like DHCP,
rather address assignment is distributed by construction and a node
can obtain an address from one of its neighbors who simply runs a
distributed algorithm.
This situation highlights an existing gap that this document tries to
fill: 6LoWPAN nodes have no means to directly request an address (or
address prefix) from routers that are their direct neighbors.
Currently, either auto-configuration is used, or DHCP has to be
deployed. The former is energy efficient, but makes it hard to
implement solutions like
[I-D.ietf-6lo-path-aware-semantic-addressing], [SHENOY21], [BLESS22],
and [RIDOUX05]. The latter, on the opposite, allows the use of
sophisticated assignment algorithms, but remains inefficient from an
energy and bandwidth consumption viewpoint.
Iannone, et al. Expires 6 March 2026 [Page
3]Internet-Draft GAAO September
2025
This document proposes a new Neighbor Discovery Option, namely the
Generic Address Assignment Option (GAAO), in order for a node to
issue an address/prefix request to neighboring routers. GAAO
complements the Extended Address Registration Option (EARO), defined
in [RFC8505], further extended in [I-D.ietf-6lo-prefix-registration]
and [RFC9685].
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] and [RFC8505]. 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
*LLN*: Low-Power and Lossy Network
*NA*: Neighbor Advertisement
*ND*: Neighbor Discovery
Iannone, et al. Expires 6 March 2026 [Page
4]Internet-Draft GAAO September
2025
*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 single AAF is used in a deployment.
^^^^^^^^^^^^^^
[CG] s/one single AAF/a single AAF
[CG] or perhaps s/one single AAF/one AAF
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).
3. Algorithmically Assigned Addresses and Prefixes
The IPv6 address assignment model within a local domain relies on
randomly generated Interface Identifiers (IIDs). These can be
assigned in two ways: a centralized approach using DHCPv6
([RFC8415]), which guarantees collision-free addresses, or a
decentralized approach using SLAAC ([RFC4862]). In the latter case,
additional mechanisms are required to ensure address uniqueness and
security, including Duplicate Address Detection (DAD) [RFC4862],
Cryptographically Generated Addresses (CGA) [RFC3972], and 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]).
The Address Assignment Function (AAF) will work as 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 Boarder
^^^^^^^
[CG] s/Boarder/Border
Routers (6LBRs) MUST use the same AAF within a given network
instance. When a node needs an address/prefix, it first selects a
Iannone, et al. Expires 6 March 2026 [Page
5]Internet-Draft GAAO September
2025
neighboring 6LR from those that responded to its initial Router
^^^
[CG] I understand that it could also be a neighboring 6LBR
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. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^
[CG] Perhaps a forward reference to the relevant
section(s)/subsection(s) where this is
better detailed (e.g., use of NS(GAAO) or NA(GAAO)) may be useful.
The 6LR assigns the address/prefix based
on the AAF and automatically registers this assignment with the
requesting 6LN. Depending on the specific technology and algorithm
in use. The node may also need to explicitly register the assigned
^^^^^^^^^
[CG] s/use. The/use, the
address/prefix to confirm its use. The overall process is
illustrated in Figure 1.
STEP
6LN 6LR/6LBR
| |
1. | Address/Prefix Request | \
| --------------------------> | \
| | + Request Phase
2. | Address/Prefix Offer | /
| <-------------------------- | /
| |
3. | Address/Prefix Acceptation | \
^^^^^^^^^^^
[CG] s/Acceptation/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 [I-D.ietf-6lo-prefix-registration]. In this phase, an
Extended Address Registration Option (EARO) and Source Link-Layer
Address Option (SLLAO) are used to register an address/prefix, which,
^^^^^^^^^^^^^^^^^^^^^^
[CG] The SLLAO acronym has been defined earlier in the document.
in this context, is not self-generated. However, to initiate the
process--specifically steps 1 and 2, a new Generic Address Assignment
Option (GAAO) is required and proposed in this document. Because no
^^^^^^^^^^^^^
[CG] The GAAO acronym has been defined earlier in the document.
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)).
4. Generic Address Assignment Option
In order for a 6LN to request the assignment of an address or prefix,
the Generic Address Assignment Option (GAAO) message is used. The
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[CG] The GAAO acronym has been defined earlier in the document.
format of the GAAO message is shown in Figure 2.
Iannone, et al. Expires 6 March 2026 [Page
6]Internet-Draft GAAO September
2025
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 bytes. This field is set to 1 plus the size of the ROVR
field when there is no address/prefix appended to the option. It
^^
[CG] perhaps s/It/Its value
is augmented by 2 (16 bytes) 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) message by the
^^^^^^^
[CG] s/message/messages
requester and MUST be ignored by the receiver. The 6LR/6LBR
replying to the request with an 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 6LR using the procedures defined in [RFC8505],
^^^
[CG] Please add "/6LBR" after "6LR"
[I-D.ietf-6lo-prefix-registration], and [RFC9685], according to
the type of the assigned address/prefix. When the 6LR/6LBR does
not set this R-flag, it implicitly indicates that the assigned
address/prefix has been also registered and state created as
specified in [RFC8505], [I-D.ietf-6lo-prefix-registration], and
Iannone, et al. Expires 6 March 2026 [Page
7]Internet-Draft GAAO September
2025
[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 [RFC8928] and
^^^^^^^^^^^^^^^^^
[CG] s/defined [RFC8928]/defined in [RFC8928]
[I-D.ietf-6lo-updating-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 of the
prefix in bits.
^^^^^^
[CG] If "prefix" refers to the one carried in the GAAO format, please state so.
Also, when the Address/Prefix field carries an address, does
PfxLen also indicate
the size of only the prefix of the address?
*AAF:* 4-bit unsigned integer. Describe the Address Assignment
^^^^^^^^
[CG] s/Describe/Describes
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, it is RECOMMENDED to set this field
to 0 to indicate there is no preference on how the address/prefix
is assigned. However, a 6LN MAY use a value different from 0,
meaning that it is requested to use a specific known AAF to assign
the address/prefix (see also Section 5.4). 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 NA(GAAO) message it expresses the granted lifetime.
A node MUST NOT use the address/prefix after expiration of the
lifetime. Address/prefix lifetime SHOULD 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
[I-D.ietf-6lo-updating-rfc-8928].
*Address/Prefix:* 128-bit IPv6 address/prefix. This field MAY be
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 NS(GAAO) message, it means that the returned address is
^^^^^^^^^^^^^^^^^^^^
[CG] If the following is what is intended, perhaps
[CG] s/the returned address/the address returned in an NA(GAAO) message
implicitly used on the interface used to send the request. This
field MUST be present in NA(GAAO) message that return a successful
address/prefix allocation, but MUST NOT be present in case of
error.
[CG] When what is carried in this field is a prefix, which are the bits of
the field used to encode the prefix? E.g., the leftmost bits, the righmost
bits...?
Iannone, et al. Expires 6 March 2026 [Page
8]Internet-Draft GAAO September
2025
5. Messages Sequence and Processing
When a node bootstraps, it typically does multicast a RS message 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.
^^^^^
[CG] I understand this should be s/time using/time, using
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 is set according to the
^^
[CG] s/is/are
local configuration. R-Flag MUST be set to 0. The AAF field
SHOULD 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 prefix the address or sub-prefix has to be derived. In
^^^^^^
[CG] please remove "prefix"
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.
* *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.
* *Assignment Lifetime:* The maximum lifetime of the assigned
address/prefix.
The message sequence is depicted in Figure 3.
Iannone, et al. Expires 6 March 2026 [Page
9]Internet-Draft GAAO September
2025
STEP
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. Documents defining AAF MUST
^^^
[CG] s/AAF/AAFs
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 [I-D.ietf-6lo-prefix-registration]
depending on the type of address/prefix. When setting the R-flag,
and as for [RFC4861], the 6LR is expect 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 6 March 2026 [Page
10]Internet-Draft GAAO September
2025
STEP
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 [I-D.ietf-6lo-prefix-registration]
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 [I-D.ietf-6lo-prefix-registration], define
how nodes keep address/prefix registering state so 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 use the address/
^^^
[CG] s/use/using
prefix. However, when using GAAO, and when preforming the re-
registering, 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
[CG] Perhaps add at the end of the previous sentence: ": GAAO with
Address Registration and GAAO with Router Discovery."
Iannone, et al. Expires 6 March 2026 [Page
11]Internet-Draft GAAO September
2025
5.3.1. GAAO with Address Registration
Prefix/address Registration utilize NS/NA transactions for the link-
local address registration [RFC8505]. In this specification, for
prefix/address Request procedure utilize an additional NS/NA
^^^^^^^
[CG] s/utilize/utilizes
transactions. To minimize the number of transactions, GAAO MAY be
^^^^^^^^^^^^
[CG] s/transaction/transactions
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 5 illustrates the GAAO
piggybacked within a link-layer address registration request and
response.
STEP
6LN 6LR/6LBR
| |
| Address Registration Request |
1. | ---------------------------------------> |
| NS(EARO + SLLAO + GAAO) |
| |
| Address Registration Response |
2. | <--------------------------------------- |
| NA(EARO with Status + SLLAO + GAAO) |
| |
Figure 5: GAAO piggybacking with link-layer Address Registration.
5.3.2. 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 specifications. Similarly, 6LR/6LBR that support this
^^^^^^^^^^^^^^
[CG] s/specifications/specification
specification MUST include a prefix/address offer in a GAAO appended
to the corresponding RA message, as depicted in Figure 6.
Iannone, et al. Expires 6 March 2026 [Page
12]Internet-Draft GAAO September
2025
STEP
6LN 6LR/6LBR
| |
| RS message |
1. | ---------------------------------------> |
| (6CIO + SLLAO + GAAO) |
| |
| RA message |
2. | <--------------------------------------- |
| (PIO + 6CIO + ABRO + SLLAO + GAAO) |
| |
Figure 6: GAAO piggybacking with Router Discovery.
A 6LR that does not support GAAO will simply ignore this option, and
^^^
[CG] Also a 6LBR ?
the corresponding RA message will not include a GAAO. This behavior
implicitly signals that the feature is not supported.
5.4. Error Conditions
GAAO Status field uses 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):
GAAO uses error codes defined in [RFC6775] and [RFC8505], revised in
[RFC9010]. This specification introduces a new status code when the
AAF in GAAO in an NS message is not in use in the 6LoWPAN network, as
follows (see also Section 7):
[CG] The two last paragraphs are almost identical...
*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 did
put 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
^^^^^^^^^^^^^
[CG] s/AAF. Meaning/AAF, meaning
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.
Iannone, et al. Expires 6 March 2026 [Page
13]Internet-Draft GAAO September
2025
* 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.
6. Signaling GAAO Support
This specification defines a new capability bit, named M-flag, for
use in the 6CIO as defined by [RFC7400] ("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 provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of 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 under the heading "Internet Control Message
Protocol version 6 (ICMPv6) Parameters" as indicated in Table 1:
Iannone, et al. Expires 6 March 2026 [Page
14]Internet-Draft GAAO September
2025
+======+===================================+=================+
| 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 under the registry group "Internet Control Message
Protocol version 6 (ICMPv6) Parameters" as indicated in Table 2:
+=====+============================+===========+
| Bit | Description | Reference |
+=====+============================+===========+
| TBD | 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 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 "Generic Address
Assignment Option".
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 6 March 2026 [Page
15]Internet-Draft GAAO September
2025
+=========+================================+===========+
| 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 on a "First Come, First Served" basis
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 SHOULD provide
sufficient protection to prevent potential attacks. Recommendations
listed in Section 7 of [RFC8505] SHOULD be applied as well to this
specification.
Depending on the Assignment Function in use, the number of available
^^^^^^^^^^^^^^^^^^^
[CG] s/Assignment Function/AAF
addresses may encounter limitations. A rouge node may leverage on
^^^^^
[CG] s/rouge/rogue
this knowledge to carry out address exhaustion attacks by
impersonating different nodes and performing multiple requests. To
mitigate such risks the reccomendation about the lifetime and number
^^^^^^^^^^^^^^^
[CG] s/reccomendation/recommendation
of addresses per node described in Section 7 of [RFC8505] remain
^^^^^^
[CG] s/remain/remains
valid.
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.
References
Normative References
Iannone, et al. Expires 6 March 2026 [Page
16]Internet-Draft GAAO September
2025
[I-D.ietf-6lo-prefix-registration]
Thubert, P., "IPv6 Neighbor Discovery Prefix
Registration", Work in Progress, Internet-Draft, draft-
ietf-6lo-prefix-registration-18, 20 August 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-6lo-
prefix-registration-18>.
[I-D.ietf-6lo-updating-rfc-8928]
Thubert, P. and A. Rashid, "Fixing the C-Flag in Extended
Address Registration Option (EARO)", Work in Progress,
Internet-Draft, draft-ietf-6lo-updating-rfc-8928-05, 26
June 2025, <https://datatracker.ietf.org/doc/html/draft-
ietf-6lo-updating-rfc-8928-05>.
[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>.
[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>.
Iannone, et al. Expires 6 March 2026 [Page
17]Internet-Draft GAAO September
2025
[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>.
[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>.
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>.
[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-12, 25 August
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
6lo-path-aware-semantic-addressing-12>.
Iannone, et al. Expires 6 March 2026 [Page
18]Internet-Draft GAAO September
2025
[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>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/rfc/rfc8415>.
[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>.
[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>.
[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>.
[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>.
Authors' Addresses
Luigi Iannone
Huawei Technologies France S.A.S.U.
18, Quai du Point du Jour
92100 Boulogne-Billancourt
France
Email: [email protected]
Iannone, et al. Expires 6 March 2026 [Page
19]Internet-Draft GAAO September
2025
David Lou
Huawei Technologies Duesseldorf GmbH
Riesstrasse 25
80992 Munich
Germany
Email: [email protected]
Adnan Rashid
Politecnico di Bari
Via Edoardo Orabona 4
70126 Bari
Italy
Email: [email protected]
Iannone, et al. Expires 6 March 2026 [Page 20]
_______________________________________________
6lo mailing list -- [email protected]
To unsubscribe send an email to [email protected]
