6lo Working Group L. Iannone
Internet-Draft D. Lou
Intended status: Standards Track Huawei
Expires: 9 January 2025 A. Rashid
Politecnico di Bari
8 July 2024
Generic Address Assignment Option for 6LowPAN Neighbor Discovery
draft-iannone-6lo-nd-gaao-03
Abstract
This document specifies a new extension to the IPv6 Neighbor
Discovery in Low Power and Lossy Networks, 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 9 January 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Iannone, et al. Expires 9 January 2025 [Page 1]
Internet-Draft GAAO July 2024
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. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
5. Algorithmically Assigned Addresses and Prefixes . . . . . . . 5
6. Generic Address Assignment Option . . . . . . . . . . . . . . 6
7. Messages Sequence and Processing . . . . . . . . . . . . . . 8
7.1. Request Phase . . . . . . . . . . . . . . . . . . . . . . 8
7.2. Optional Confirmation Phase . . . . . . . . . . . . . . . 9
7.3. Message exchange optimization . . . . . . . . . . . . . . 10
8. GAAO Error Conditions . . . . . . . . . . . . . . . . . . . . 11
9. Signaling GAAO Support . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10.1. IPv6 ND Option Types . . . . . . . . . . . . . . . . . . 12
10.2. 6LoWPAN Capability Bits . . . . . . . . . . . . . . . . 13
10.3. GAAO Error code . . . . . . . . . . . . . . . . . . . . 13
10.4. Address Assignment Function Registry . . . . . . . . . . 13
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Normative References . . . . . . . . . . . . . . . . . . . . . 14
Informative References . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
Low Power and Lossy Networks (LLNs) have adapted the design of
Internet protocols to more constrained environments, by taking into
consideration of energy saving, limited memory capacity, and duty
cycling of the LLN devices, as well as low-power lossy transmissions.
Since the wireless interface is a major energy drain, protocols
aiming at being deployed over LLN must be designed in such a way to
reduce as much as possible transmissions, allowing to turn off the
radio interface or put the interface or the whole node in the
sleeping mode.
Iannone, et al. Expires 9 January 2025 [Page 2]
Internet-Draft GAAO July 2024
IPv6 Neighbor Discovery has been also adapted to the LLN environment
in [RFC6775], later updated by [RFC8505], [RFC8929], and [RFC9010].
In particular, interface address assignment relies on address auto-
configuration [RFC4862], since the use of Dynamic Host Configuration
Protocol (DHCP [RFC8415]) is not adapted to LLN deployments. Hence,
mechanisms to register these self-generated addresses have been
designed ([RFC6775], [I-D.ietf-6lo-prefix-registration], [RFC8505],
[I-D.ietf-6lo-multicast-registration]).
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 a node can obtain an address generated by one of its neighbors
who simply runs an 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 consumption viewpoint.
This document proposes a new Neighbor Discovery Option, namely the
Generic Address Assignment Option (GAAO), in order for a node to
issue an address or prefix request to neighboring routers. This new
GAA Option complements the Extended Address Registration Option,
defined in [RFC8505] and further extended in
[I-D.ietf-6lo-prefix-registration],
[I-D.ietf-6lo-multicast-registration].
2. 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.
Iannone, et al. Expires 9 January 2025 [Page 3]
Internet-Draft GAAO July 2024
3. Terminology
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
ARO: Address Registration Option
EARO: Extended Address Registration Option
GAAO: Generic Address Assignment Option
LLN: Low-Power and Lossy Network
NA: Neighbor Advertisement
ND: Neighbor Discovery
NS: Neighbor Solicitation
RA: Router Advertisement
RS: Router Solicitation
SLLAO: Source Link-Layer Address Option
TLLAO: Target Link-Layer Address Option
4. Definition of Terms
Address Assignment Function (AAF): The Address Assignment Function
(AAF) is an implementation of the algorithm used by 6LRs to assign
an address/prefix to requesting nodes. In order to avoid
addressing issues, only one single AAF is used in a deployment.
Iannone, et al. Expires 9 January 2025 [Page 4]
Internet-Draft GAAO July 2024
5. Algorithmically Assigned Addresses and Prefixes
The IPv6 address assignment model inside a local domain is based on
randomly assigned Interface IDentifier (IID), either done in a
centralized way using DHCP, which can guarantee no address collision,
or by decentralized State-Less Address Auto-Configuration (SLAAC
[RFC4862]), which needs additional mechanisms to ensure the
uniqueness of addresses. However, there is a third approach for
address assignment, which is distributed and collision-free:
algorithmically generated addresses ([SHENOY21], [BLESS22],
[RIDOUX05], [ERIKSSON04]).
The main idea is to use an Address Assignment Function (AAF) to
assign addresses and prefixes to nodes joining a network. All nodes,
6LNs, 6LRs, and 6LBRs, MUST use the same AAF in the same network
instance. Each node acquiring an address firstly needs to select a
neighbor 6LR by choosing among the nodes that replied with a Router
Advertisement (RA) after an initial Router Solicitation (RS), as
defined in [RFC6775]. Then, the node explicitly requests an address
(or prefix) to the selected 6LR. Depending on the underlying
technology and algorithm used the node may optionally confirm its
usage. The high-level sequence of actions is depicted in Figure 1.
6LN 6LR
| |
| 1. Address Request | \
|------------------------>| |
| | > Request Phase
| 2. Address Offer | |
|<------------------------| /
| |
| 3. Address Acceptation | \
|------------------------>| |
| | > Optional Confirmation Phase
| 4. Address Confirmation | |
|<------------------------| /
Figure 1: Address/Prefix assignment sequence.
The optional confirmation phase (namely step 3 and 4), is implemented
by using the address registration procedure defined in [RFC8505],
{!I-D.ietf-6lo-multicast-registration}, or {I-D.ietf-6lo-prefix-
registration}. Basically, it uses an EARO and SLLAO messages to
register an address, which in this case is not a self-generated
address. However, in order to issue the initial request, meaning
steps 1 and 2, a new Generic Address Assignment Option (GAAO) is
required and proposed, since no existing mechanism can be readily
used for this purpose. In the remaining of this document, the format
Iannone, et al. Expires 9 January 2025 [Page 5]
Internet-Draft GAAO July 2024
of this option is firstly defined (Section 6), followed by a revised
Address/Prefix assignment messages sequence and processing
(Section 7).
6. Generic Address Assignment Option
In order for a node to request the assignment of an address or
prefix, the Generic Address Assignment Option (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/PfxLen | Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|F| P | I |Rsd| AAF | Assignment Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Registration Ownership Verifier (ROVR) ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address/Prefix |
| (128 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Generic Address Assignment Option format.
Generic Address Assignment Option Fields:
Type: 42 (Suggested)
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 the option is used in NS messages. It is augmented by
2 (16 bytes) when this option is used in NA messages because the
assigned address/prefix is appended to the option.
Status/PfxLen: 8-bits unsigned integer. This field has two
purposes. It indicates the Prefix Length of the assigned
address if the assignment is successful. On success, the
returned GAAO message will have 16 bytes of the assigned
address/prefix appended to it, which that the Length field will
increased by 2 (cf. Length field). In case of failure, when
no address/prefix is returned, this field indicates an error
code (See table 1 in [RFC8505] and Section 8 for error codes).
In this case, the returned GAAO message will not have any
Iannone, et al. Expires 9 January 2025 [Page 6]
Internet-Draft GAAO July 2024
address/prefix appended to it and the Length field has not been
increased. A returning GAA Option with the same length as the
one sent indicates error condition, whose code is indicated in
this field. This field MUST be set to 0 on transmission and
ignored on reception in NS messages.
Opaque: As defined in [RFC8505].
C: Confirmation requested. It MUST be initialized to 0 by in NS
messages by the requester and MUST be ignored by the receiver.
The 6LR replying to the request with an 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 requester receives
an NA message with this bit set, it MUST explicitly register the
received address/prefix to the same 6LR using the procedures
defined in [RFC8505], [I-D.ietf-6lo-prefix-registration], and
[I-D.ietf-6lo-multicast-registration], according to the type of
the assigned address/prefix.
F: F-Field as defined in [I-D.ietf-6lo-prefix-registration].
P: P-Field as defined in [I-D.ietf-6lo-prefix-registration]
indicating the type of address requested.
I: As defined in [RFC8505].
Rsd (Reserved): This field is unused. It MUST be initialized to 0
by the sender and MUST be ignored by the receiver.
Address Assignment Function(AAF): 1-byte unsigned integer. Describe
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. On request in an NS message, this field
MAY be set to 0 to indicate there is no preference on how the
address is assigned. If different from 0 it means that it is
requested to use a specific known AAF to assign the address/prefix
(see Section 8). Moreover, Section 10.4 describes possible values
of this field.
Assignment Lifetime: 16-bit unsigned integer, expressed in minutes.
In an NS message, the field expresses the minimum desired
lifetime. It MAY be set to zero in the NS message, indicating no
particular desired lifetime. In NA messages it expresses the
granted maximum lifetime.
ROVR: As defined in [RFC8505].
Address/Prefix: 128 bits address or prefix returned in a GAA Option
Iannone, et al. Expires 9 January 2025 [Page 7]
Internet-Draft GAAO July 2024
in an NA message. This field is not present in GAAO requests in
NS messages and in NA messages when an error occurs.
7. Messages Sequence and Processing
When a node bootstraps, it typically does multicast a Routing
Solicitation (RS) and receives one or more unicast Routing
Advertisements (RA) messages from neighbor 6LRs. The node can choose
one or more 6LRs from which to request address(es) or prefix(es). A
node can perform an address request at any time, not necessarily at
boot time using Neighbor Solicitation (NS) and Neighbor Advertisement
(NA) messages.
7.1. Request Phase
When the node requests an address, the node will go through the
following steps:
1. The node will issue an NS message with the GAA Option to request
an address assignment. This initial GAA Option has a length
equal to ROVR's length as a multiple of 8 bytes plus one (no
address appended), Status/PfxLen set to 0. Opaque, as well as
the F-bit and I-bits will be set according to local
configuration. The C-bit is set to zero. The P-bits are set
according to the type of address it is requesting. The AAF is
set to zero if the node has no preference for the assignment
algorithm, otherwise it is set to the selected AAF code. The
lifetime field is set to the minimum desired lifetime, or zero
otherwise.
2. Assuming no errors occur, the node will receive an NA message
with a GAA Option with a length increased by two, compared to the
corresponding NS message, because of the presence of the address/
prefix field. All fields have been copied back except for:
* Pfxlen: now indicating the length of the prefix.
* C: The C bit is set if the 6LR requests a confirmation via a
registration procedure.
* AAF: It is the algorithm, used to assign the address/prefix.
If the node is a 6LR it will 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 9 January 2025 [Page 8]
Internet-Draft GAAO July 2024
6LN 6LR
| |
| NS(GAAO) |
|---------------------->|
| |
| NA(GAAO) |
|<----------------------|
| |
Figure 3: Address/Prefix assignment with GAAO message sequence and no
confirmation request.
7.2. Optional Confirmation Phase
Depending on the algorithm in use and the underlying technology the
address 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 Address Allocation
Function MUST explicitly state whether this phase remains optional or
is mandatory due to factors specific to the proposed algorithm.
If the C bit is set, to confirm the acceptance and usage of the
proposed address/prefix received in the NA message, the 6LN MUST
register with the obtained address by following the procedures in
[RFC8505], [I-D.ietf-6lo-multicast-registration], or
[I-D.ietf-6lo-prefix-registration] depending on the type of address.
In this case, the complete sequence of actions is depicted in
Figure 4.
Iannone, et al. Expires 9 January 2025 [Page 9]
Internet-Draft GAAO July 2024
6LN 6LR
| |
| NS(GAAO) |
|---------------------->|
| |
| NA(GAAO) |
|<----------------------|
| |
| NS(EARO+TLLAO) |
|---------------------->|
| |
...
Procedure According to [RFC8505],
[I-D.ietf-6lo-multicast-registration], or
[I-D.ietf-6lo-prefix-registration]
depending on the type of address.
...
| |
| NA(EARO+TLLAO) |
|<----------------------|
Figure 4: Address/Prefix assignment with GAAO message sequence.
The specifications in [RFC8505],
[I-D.ietf-6lo-multicast-registration], and
[I-D.ietf-6lo-prefix-registration], define how nodes can 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 optional confirmation phase MUST be used to perform an
explicit registration. 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.
7.3. Message exchange optimization
The request of a prefix/address uses a NS/NA transaction likewise
prefix/address registration. In order to reduce the number fo
transactions the GAA Option MAY be used at the same time like the
EARO+SLLAO options. In other words the GAA Option can be picky-
bagged on other transactions. For instance, it can be picky-bagged
in an link-layer address registration, as shown in Figure 5. In this
case the returning NA will contain two addresses, one in the TLLA
Option, namely the registered link-layer-address, and one directly
appended in the GAA Option, namely the offered prefix/address.
Iannone, et al. Expires 9 January 2025 [Page 10]
Internet-Draft GAAO July 2024
6LN 6LR
| |
| NS(EARO+TLLAO+GAAO) |
|---------------------->|
| |
| NA(EARO+TLLAO+GAAO) |
|<----------------------|
| |
Figure 5: Message sequence when GAA Option is picky-bagged on a
link-layer registration transaction.
When prefix/address request is performed at boot time, the GAAO
request MAY be appended as an option of the first RS message,
implicitly signaling that the node sending the RS message supports
the specifications in the present document. In the same way, the
responding routers that support this document send back a prefix/
address offer in a GAA Option appended to the returning RA message,
as depicted in Figure 6.
6LN 6LR
| |
| RS(SLLAO+GAAO) |
|---------------------->|
| |
| RA(SLLAO+GAAO) |
|<----------------------|
| |
Figure 6: Message sequence when GAA Option is used with the RS/RA
transaction.
6LRs that do not support GAAO will simply ignore the option, and the
corresponding RA, which will not include the GAA Option, implicitly
signaling that the feature is not supported.
8. GAAO Error Conditions
The GAA Option uses error codes defined in [RFC6775] and [RFC8505],
and revised in [RFC9010]. This specification introduces a new status
code when the AAF in the GAA Option in an NS message is not supported
by 6LR, as follows (see also Section 10):
AAF Not Supported: The AAF in the GAA Option in the NS message is
not supported by 6LR that received the message.
Iannone, et al. Expires 9 January 2025 [Page 11]
Internet-Draft GAAO July 2024
This status MUST be used when a node requesting an address/prefix did
put an AAF value, in the corresponding field, which is not supported
by the 6LR receiving the request. When the node receives this status
back it can perform one of the following actions:
* Re-issue the same request without specifying an AAF. Meaning set
the AAF Field to 0.
* Re-issue the same request with a different AAF.
* Do nothing.
The action to be used is selected by configuration.
9. Signaling GAAO Support
This specification defines five new capability bits for use in the
6CIO as defined by [RFC7400] ("6LoWPAN-GHC: Generic Header
Compression for IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPANs)"), for use in IPv6 ND messages. A 6LowPAN node that
supports this specification MUST set the M flag.
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 |M|F|X|A|D|L|B|P|E|G|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: New GAAO Capability Bit in the 6CIO.
M: The node supports managed addresses via the Generic Address
Assignment Capability.
10. 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].
10.1. IPv6 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 9 January 2025 [Page 12]
Internet-Draft GAAO July 2024
+================+===================================+===========+
| Type | Description | Reference |
+================+===================================+===========+
| 42 (Suggested) | Generic Address Assignment Option | [This |
| | | Document] |
+----------------+-----------------------------------+-----------+
Table 1: New Generic Address Assignment Option.
10.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 |
+===============+============================+===========+
| 6 (Suggested) | Generic Address Assignment | [This |
| | Capability (M) Flag | Document] |
+---------------+----------------------------+-----------+
Table 2: New 6LoWPAN Capability Bit.
10.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 Supported | [This Document] |
+----------------+-------------------+-----------------+
Table 3: New address registration option value.
10.4. Address Assignment Function Registry
IANA is asked to create a registry named "Generic Address Assignment
Option Parameters".
Such registry should be populated with a one octet sub registry named
"Address Assignment Function" and used to identify the used AAF used.
The sub registry is populated as shown in Table 4:
Iannone, et al. Expires 9 January 2025 [Page 13]
Internet-Draft GAAO July 2024
+===========+================================+===========+
| Value | AAF Name | Reference |
+===========+================================+===========+
| 0x00 | No AAF. This can be used only | [This |
| | in NS message to indicate that | Document] |
| | no specific AAF is demanded. | |
+-----------+--------------------------------+-----------+
| 0x01-0xFE | Un-assigned | |
+-----------+--------------------------------+-----------+
| 0xFF | Experimental. 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].
11. 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
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.
Acknowledgements
This document received many comments and help from community people.
The authors would like to thank all of them.
References
Normative References
[I-D.ietf-6lo-multicast-registration]
Thubert, P., "IPv6 Neighbor Discovery Multicast and
Anycast Address Listener Subscription", Work in Progress,
Internet-Draft, draft-ietf-6lo-multicast-registration-19,
16 May 2024, <https://datatracker.ietf.org/doc/html/draft-
ietf-6lo-multicast-registration-19>.
Iannone, et al. Expires 9 January 2025 [Page 14]
Internet-Draft GAAO July 2024
[I-D.ietf-6lo-prefix-registration]
Thubert, P., "IPv6 Neighbor Discovery Prefix
Registration", Work in Progress, Internet-Draft, draft-
ietf-6lo-prefix-registration-02, 13 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-6lo-
prefix-registration-02>.
[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>.
[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>.
[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>.
[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>.
Iannone, et al. Expires 9 January 2025 [Page 15]
Internet-Draft GAAO July 2024
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),
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,
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, Z., Liu, P., Long, R.,
Makhijani, K., 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-06, 24 May 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-6lo-
path-aware-semantic-addressing-06>.
[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>.
Iannone, et al. Expires 9 January 2025 [Page 16]
Internet-Draft GAAO July 2024
[RIDOUX05] Ridoux, J., Fladenmuller, A., Viniotis, Y., and K.
Salamatian, "Trellis-Based Virtual Regular Addressing
Structures in Self-organized Networks", NETWORKING 2005.
Networking Technologies, Services, and Protocols;
Performance of Computer and Communication Networks; Mobile
and Wireless Communications Systems 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), 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: luigi.iannone@huawei.com
David Lou
Huawei Technologies Duesseldorf GmbH
Riesstrasse 25
80992 Munich
Germany
Email: zhe.lou@huawei.com
Adnan Rashid
Politecnico di Bari
Via Edoardo Orabona 4
70126 Bari
Italy
Email: adnan.rashid@poliba.it
Iannone, et al. Expires 9 January 2025 [Page 17]