



6lo Working Group                                             L. Iannone
Internet-Draft                                                    D. Lou
Intended status: Standards Track                                  Huawei
Expires: 22 January 2026                                       A. Rashid
                                                     Politecnico di Bari
                                                            21 July 2025


    Generic Address Assignment Option for 6LoWPAN Neighbor Discovery
                       draft-ietf-6lo-nd-gaao-06

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 22 January 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.











Iannone, et al.          Expires 22 January 2026                [Page 1]

Internet-Draft                    GAAO                         July 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.  Optional Ratification Phase . . . . . . . . . . . . . . .  10
     5.3.  Message Exchange Optimization . . . . . . . . . . . . . .  11
     5.4.  Error Conditions  . . . . . . . . . . . . . . . . . . . .  12
   6.  Signaling GAAO Support  . . . . . . . . . . . . . . . . . . .  13
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  IPv6 ND Option Types  . . . . . . . . . . . . . . . . . .  14
     7.2.  6LoWPAN Capability Bits . . . . . . . . . . . . . . . . .  14
     7.3.  GAAO Error code . . . . . . . . . . . . . . . . . . . . .  14
     7.4.  Address Assignment Function Registry  . . . . . . . . . .  15
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  16
   References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  16
     Normative References  . . . . . . . . . . . . . . . . . . . . .  16
     Informative References  . . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

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 22 January 2026                [Page 2]

Internet-Draft                    GAAO                         July 2025


   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,
   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
   [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-
   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.

   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.  GAAO



Iannone, et al.          Expires 22 January 2026                [Page 3]

Internet-Draft                    GAAO                         July 2025


   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

   NS: Neighbor Solicitation

   Pfxlen: Prefix Length



Iannone, et al.          Expires 22 January 2026                [Page 4]

Internet-Draft                    GAAO                         July 2025


   RA: Router Advertisement

   RS: Router Solicitation

   SLAAC: State-Less 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 to assign
      an address/prefix to requesting nodes.  In order to avoid
      addressing issues, only one single AAF is used in a deployment.

   GAAO: Generic Address Assignment Option defined in the present
   document (Section 4).

3.  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 (e.g., [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 ratify its
   usage.  The high-level sequence of actions is depicted in Figure 1.









Iannone, et al.          Expires 22 January 2026                [Page 5]

Internet-Draft                    GAAO                         July 2025


   STEP
         6LN                      6LR
          |                       |
    1.    |  Address Request      | \
          | --------------------> |  \
          |                       |   + Request Phase
    2.    |  Address Offer        |  /
          | <-------------------- | /
          |                       |
    3.    |  Address Acceptation  | \
          | --------------------> |  \
          |                       |   + Optional Ratification Phase
    4.    |  Address Confirmation |  /
          | <-------------------- | /
          |                       |

               Figure 1: Address/Prefix assignment sequence.

   The optional ratification phase (namely step 3 and 4), is implemented
   by using the address registration procedure defined in [RFC8505],
   [RFC9685], 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, namely 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 of this option is firstly defined
   (Section 4), followed by a revised Address/Prefix assignment messages
   sequence and processing (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
   format of the GAAO message is shown in Figure 2.
















Iannone, et al.          Expires 22 January 2026                [Page 6]

Internet-Draft                    GAAO                         July 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/PfxLen |    Opaque     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |R|C|    Reserved       |  AAF  |     Assignment   Lifetime     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~            Registration Ownership Verifier (ROVR)             ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                        Address/Prefix                         |
    |                          (128 bits)                           |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 2: Generic Address Assignment Option 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 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 or an error code otherwise.

      *  On success, the returned GAAO message MUST have 16 bytes of the
         assigned address/prefix appended to it, which means 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 5.4 for error codes).  In this case, the returned GAAO
         message will not have any address/prefix appended to it and the
         Length field has not been increased.  A returning GAAO with the
         same length as the one sent indicates error condition, whose
         code MUST be is indicated in this field.

      This field MUST be set to 0 on transmission and ignored on
      reception in NS messages.




Iannone, et al.          Expires 22 January 2026                [Page 7]

Internet-Draft                    GAAO                         July 2025


   Opaque:  As defined in [RFC8505].

   R:  1-bit flag for Ratification requested.  It MUST be initialized to
      0 in NS(GAAO) messages by the requester and MUST be ignored by the
      receiver.  The 6LR/6LBR replying to the request with an NA(GAAO)
      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(GAAO) 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 [RFC9685], according to
      the type of the assigned address/prefix.

   C:  1-bit flag for Crypto-ID used for ROVR as defined [RFC8928] and
      [I-D.ietf-6lo-updating-rfc-8928].  This flag MUST be set when the
      ROVR field contains a Crypto-ID.

   Reserved:  10-bit reserved field for future use.  It MUST be
      initialized to 0 by the sender and MUST be ignored by the
      receiver.

   Address Assignment Function(AAF):  4-bit 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, it is
      RECOMMENDED to set this field to 0 to indicate there is no
      preference on how the address 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 message, the field expresses a desired lifetime.  It MAY
      be set to zero in the NS(GAAO) message, indicating no particular
      desired lifetime.  In NA(GAAO) messages it expresses the granted
      maximum 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 address or prefix returned in a NA(GAAO)






Iannone, et al.          Expires 22 January 2026                [Page 8]

Internet-Draft                    GAAO                         July 2025


      message.  This field MUST NOT be present in NS(GAAO) request
      messages and in NA(GAAO) messages when an error occurs.  This
      field MUST be present in NA(GAAO) messages that return a
      successful address/prefix allocation.

5.  Messages Sequence and Processing

   When a node bootstraps, it typically does multicast a RS 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 an address request at any time, not
   necessarily at boot time using NS and NA messages.

5.1.  Request Phase

   When the node requests an address, the node will go through the
   following steps:

   1.  The node will issue an NS(GAAO) request for an address
       assignment.  In this initial request, GAAO MUST have a length
       equal to ROVR's length as a multiple of 8 bytes plus one (no
       16-bytes address appended), Status/PfxLen field set to 0.
       Opaque, ROVR, and C-flag is set according to local the
       configuration.  The R-flag is set to zero.  The AAF field SHOULD
       be set to zero unless by configuration there is a preference for
       the assignment algorithm.  The address Assignment Lifetime field
       MAY be set to the desired lifetime, or zero otherwise.

   2.  Assuming no errors occur, the node will receive an NA(GAAO)
       message with a length increased by two, compared to the
       corresponding NS(GAAO) 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.

       *  R: The R-bit is set if the 6LR requests a ratification via a
          registration procedure.

       *  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 22 January 2026                [Page 9]

Internet-Draft                    GAAO                         July 2025


   STEP
         6LN                                        6LR
          |                                          |
    1.    | ---- NS with Address/Prefix Request ---> |
          |                (GAAO)                    |
          |                                          |
    2.    | <--- NA with Proposed Address/Prefix --- |
          |                (GAAO)                    |
          |                                          |

   Figure 3: Address/Prefix assignment with GAAO message sequence and no
                           confirmation request.

5.2.  Optional Ratification 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 R-flag is set, to ratify the acceptance and usage of the
   proposed address/prefix received in the NA(GAAO) message, the 6LN
   MUST register with the obtained address by following the procedures
   in [RFC8505], [RFC9685], or [I-D.ietf-6lo-prefix-registration]
   depending on the type of address.  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 22 January 2026               [Page 10]

Internet-Draft                    GAAO                         July 2025


   STEP
         6LN                                            6LR
          |                                              |
    1.    | ------ NS with Address/Prefix Request -----> |
          |                  (GAAO)                      |
          |                                              |
    2.    | <------ NA with Proposed Address/Prefix ---- |
          |                  (GAAO)                      |
          |                                              |
    3.    | --- NS with Address/Prefix Registration ---> |
          |               (EARO + SLLAO)                 |
          |                                              |
                               ...
         Procedure According to [RFC8505], [RFC9685], or
                 [I-D.ietf-6lo-prefix-registration]
                 depending on the type of address.
                               ...
          |                                              |
    4.    | <--- NA with Address/Prefix Registration --- |
          |          (EARO with Status + SLLAO)          |
          |                                              |

      Figure 4: Address/Prefix Assignment with GAAO Message sequence.

   The specifications in [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
   optional ratification 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.

5.3.  Message Exchange Optimization

   Prefix/address requests utilize NS/NA transactions, similar to
   prefix/address registration.  To minimize the number of transactions,
   GAAO MAY be used at the same time like the EARO option.  In other
   words GAAO can be piggybacked on other transactions, hence it does
   not necessarily introduce additional NS/NA transactions.  For
   instance, it can be piggybacked in an link-layer address
   registration, as shown in Figure 5.  In this case the returning
   NA(GAAO+EARO) will contain an address directly appended in GAAO,
   namely the offered prefix/address.






Iannone, et al.          Expires 22 January 2026               [Page 11]

Internet-Draft                    GAAO                         July 2025


   STEP
         6LN                                        6LR
          |                                          |
    1.    | ----- NS with Address Registration ----> |
          |       (EARO + SLLAO + TLLAO + GAAO)      |
          |                                          |
    2.    | <---- NA with Address Registration  ---- |
          |     (EARO with Status + SLLAO + GAAO)    |
          |                                          |

    Figure 5: Message sequence when GAAO is piggybacked 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 MUST send back a
   prefix/address offer in a GAAO appended to the returning RA message,
   as depicted in Figure 6.

   STEP
         6LN                                        6LR
          |                                          |
    1.    | ---------- Router Solicitation --------> |
          |            (6CIO + SLLAO + GAAO)         |
          |                                          |
    2.    | <-------- Router Advertisement --------- |
          |     (PIO + 6CIO + ABRO + SLLAO + GAAO)   |
          |                                          |

        Figure 6: Message sequence when GAAO 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 a GAAO, implicitly signaling
   that the feature is not supported.

5.4.  Error Conditions

   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):

   AAF Not Used:  The AAF in GAAO in the NS message is not in use in the
      6LoWPAN network.




Iannone, et al.          Expires 22 January 2026               [Page 12]

Internet-Draft                    GAAO                         July 2025


   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
      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.

6.  Signaling GAAO Support

   This specification defines one new capability bit 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    |X|A|D|L|B|P|E|G|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |F|M|                       Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 7: New GAAO Capability Bit in the 6CIO.

   M:  The node supports managed addresses via the Generic Address
      Assignment Capability.







Iannone, et al.          Expires 22 January 2026               [Page 13]

Internet-Draft                    GAAO                         July 2025


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 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:

      +======+===================================+=================+
      | 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 | Generic Address Assignment Capability (M) Flag | [This     |
   |     |                                                | 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:










Iannone, et al.          Expires 22 January 2026               [Page 14]

Internet-Draft                    GAAO                         July 2025


            +================+==============+=================+
            | Value          | Description  | Reference       |
            +================+==============+=================+
            | 13 (Suggested) | AAF Not Used | [This Document] |
            +----------------+--------------+-----------------+

              Table 3: New address registration option 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 a one-octet registry
   named "Address Assignment Function" and used to identify the used AAF
   used.  The registry is populated as shown in Table 4:

         +=========+================================+===========+
         | 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
   addresses may encounter limitations.  A rouge node may leverage on
   this knowledge to carry out address exhaustion attacks by



Iannone, et al.          Expires 22 January 2026               [Page 15]

Internet-Draft                    GAAO                         July 2025


   impersonating different nodes and performing multiple requests.  To
   mitigate such risks the reccomendation about the lifetime and number
   of addresses per node described in Section 7 of [RFC8505] remain
   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
   helpend to spot overlooked points in the definition of the GAAO
   mechanism.

References

Normative References

   [I-D.ietf-6lo-prefix-registration]
              Thubert, P., "IPv6 Neighbor Discovery Prefix
              Registration", Work in Progress, Internet-Draft, draft-
              ietf-6lo-prefix-registration-15, 4 July 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-6lo-
              prefix-registration-15>.

   [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>.






Iannone, et al.          Expires 22 January 2026               [Page 16]

Internet-Draft                    GAAO                         July 2025


   [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>.

   [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









Iannone, et al.          Expires 22 January 2026               [Page 17]

Internet-Draft                    GAAO                         July 2025


   [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-11, 3 March 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-6lo-
              path-aware-semantic-addressing-11>.

   [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



Iannone, et al.          Expires 22 January 2026               [Page 18]

Internet-Draft                    GAAO                         July 2025


              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: 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 22 January 2026               [Page 19]
