Internet DRAFT - draft-iannone-6lo-nd-gaao

draft-iannone-6lo-nd-gaao







6lo Working Group                                             L. Iannone
Internet-Draft                                                    D. Lou
Intended status: Standards Track                                  Huawei
Expires: 2 September 2024                                   1 March 2024


    Generic Address Assignment Option for 6LowPAN Neighbor Discovery
                      draft-iannone-6lo-nd-gaao-02

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 recursively 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 2 September 2024.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   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.




Iannone & Lou           Expires 2 September 2024                [Page 1]

Internet-Draft                    GAAO                        March 2024


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   4
   5.  Algorithmically Assigned Addresses and Prefixes . . . . . . .   4
   6.  Generic Address Assignment Option . . . . . . . . . . . . . .   5
   7.  Messages Sequence . . . . . . . . . . . . . . . . . . . . . .   7
   8.  GAAO Error Conditions . . . . . . . . . . . . . . . . . . . .   9
   9.  Signaling GAAO Support  . . . . . . . . . . . . . . . . . . .  10
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     10.1.  IPv6 ND Option Types . . . . . . . . . . . . . . . . . .  10
     10.2.  6LoWPAN Capability Bits  . . . . . . . . . . . . . . . .  11
     10.3.  GAAO Error code  . . . . . . . . . . . . . . . . . . . .  11
     10.4.  Address Assignment Function Registry . . . . . . . . . .  11
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  12
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  12
   References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  12
     Normative References  . . . . . . . . . . . . . . . . . . . . .  12
     Informative References  . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

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 node in sleeping mode.

   IPv6 Neighbor Discovery has been also adapted to the LLN environment
   in [RFC6775], later updated by [RFC8505], [RFC8929], and [RFC9010].
   In particular, address assignment is relying 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.thubert-6lo-prefix-registration],
   [RFC8505], [I-D.ietf-6lo-multicast-registration]).

   Recent use cases show however, that there is some advantages in
   assigning addresses in an algorithmically managed way, which may
   simplify packet forwarding in some scenarios ([RFC9453],
   [I-D.ietf-6lo-path-aware-semantic-addressing], [SHENOY21], [BLESS22],
   [RIDOUX05]), hence reducing the power consumption and memory



Iannone & Lou           Expires 2 September 2024                [Page 2]

Internet-Draft                    GAAO                        March 2024


   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 from one of the neighbors by simply
   running the 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 hard to
   implement solutions like
   [I-D.ietf-6lo-path-aware-semantic-addressing], [SHENOY21], [BLESS22],
   and [RIDOUX05].  The latter, on the opposite, allows to use
   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 neighbors routers.  This new
   GAAO option complements the Extended Address Registration Option,
   defined in [RFC8505] and further extended in
   [I-D.thubert-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.

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



Iannone & Lou           Expires 2 September 2024                [Page 3]

Internet-Draft                    GAAO                        March 2024


   ARO: Address Registration Option

   EARO: Extended Address Registration Option

   LLN: Low-Power and Lossy Network

   NA: Neighbor Advertisement

   ND: Neighbor Discovery

   NS: Neighbor Solicitation

   RA: Router Advertisement

   RS: Router Solicitation

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 SHOULD be used in a
      deployment.

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 a well-known Address Assignment Function
   (AAF) to assign addresses and prefixes to nodes joining a network.
   All nodes 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 asks for an address (or prefix)
   to the selected 6LR.  Depending on the underlying technology and
   algorithm used the node may confirm its usage.  Note that the address
   request may be triggered at any time, not necessarily when the node
   bootstraps.  The sequence of actions is depicted in {Fig:AAFSeq}




Iannone & Lou           Expires 2 September 2024                [Page 4]

Internet-Draft                    GAAO                        March 2024


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

               Figure 1: Address/Prefix assignment sequence.

   When used, steps 3 and 4 of the sequence of actions MUST be
   implemented by using the address registration procedure defined in
   [RFC8505].  Basically it uses an EARO message 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 of this option is firstly
   defined (Section 6), followed by a revised Address/Prefix assignment
   sequence (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.



















Iannone & Lou           Expires 2 September 2024                [Page 5]

Internet-Draft                    GAAO                        March 2024


     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.

   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.

   ROVR: As defined in [RFC8505].

   >

   Status/PfxLen:  8-bits unsigned integer.  It indicates the Prefix
      Length of the assigned address if the assignment is successful.
      On success, the returned GAAO will have appended to it the
      assigned address/prefix and in this case the Length field will
      increased by 2.  This field can indicate an error code (See table
      1 in [RFC8505] and Section 8 for error codes) if the assignment
      failed.  On failure, the returned GAAO message will not have any
      address/prefix appended to it.  Hence the Length field has not
      been increased, indicating a failure, whose code is indicated in
      this field.  This field MUST be set to 0 in NS messages.

   Opaque:  As defined in [RFC8505].

   C:  Confirmation requested.  It MUST be initialized to 0 by in NS




Iannone & Lou           Expires 2 September 2024                [Page 6]

Internet-Draft                    GAAO                        March 2024


      messages by 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 the procedures
      defined in [RFC8505], [I-D.thubert-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.thubert-6lo-prefix-registration].

   P:  P-Field as defined in [I-D.thubert-6lo-prefix-registration]
      indicating the type of address requested.

   I:  As defined in [RFC8505].

   R (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 Assignment Function (AF), 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 CAN 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).  See Section 10.4 for 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 NS message indicating no particular
      desired lifetime.  In NA messages it expresses the granted maximum
      lifetime.

   Address/Prefix:  128-bits address or prefix returned in a GAAO option
      in an NA message.  This field is not present in GAAO requests in
      NS messages or in the NA message when an error occurs.

7.  Messages Sequence

   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.  If done at boot time, the request MAY be appended as an
   option of the first RS message, while responding routers can offer an



Iannone & Lou           Expires 2 September 2024                [Page 7]

Internet-Draft                    GAAO                        March 2024


   address in the RA message.  The mechanism is completely optional.  If
   the node requests an address, the node will go through the following
   steps:

   1.  The node will issue a NS message with the GAAO option to request
       an address assignment.  This initial GAAO option has length equal
       to ROVR's length as multiple of 8 bytes plus one (no address
       appended), Status/PfxLength 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 no
       preference for the assignment algorithm.  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 GAAO option with a length increased by two compare 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: Indicating the Address Assignment Function, i.e., 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 neighbors nodes.

       *  Assigned lifetime: the maximum lifetime of the assigned
          address/prefix.

   The message sequence is depicted in Figure 3.

    6LN          6LR
    |            |
    |  NS(GAAO)  |
    |----------->|
    |            |
    |  NA(GAAO)  |
    |<-----------|
    |            |

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






Iannone & Lou           Expires 2 September 2024                [Page 8]

Internet-Draft                    GAAO                        March 2024


   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.

   If the C bit is set, to confirm the acceptance and usage of the
   proposed address/prefix received in the NA message, the 6LN has to
   register to the obtained address following the procedures in
   [RFC8505], [I-D.ietf-6lo-multicast-registration], or
   [I-D.thubert-6lo-prefix-registration] depending on the type of
   address.

   In the case the complete sequence of actions is depicted in Figure 4.

    6LN          6LR
    |            |
    |  NS(GAAO)  |
    |----------->|
    |            |
    |  NA(GAAO)  |
    |<-----------|
    |            |
    |  NS(EARO)  |
    |----------->|
    |            |
         ...
   Procedure According to [RFC8505],
   [I-D.ietf-6lo-multicast-registration], or
   [I-D.thubert-6lo-prefix-registration]
   depending on the type of address.
         ...
    |            |
    |  NA(EARO)  |
    |<-----------|

      Figure 4: Address/Prefix assignment with GAAO message sequence.

8.  GAAO Error Conditions

   The GAAO option uses error codes defined in [RFC6775] and [RFC8505],
   revised in [RFC9010].  This specification introduces a new status
   code when the AAF in the GAAO option in an NS message is not
   supported by 6LR, as follows (see also Section 10):

   AAF Not Supported:  The AAF in the GAAO option in the NS message is
      not supported by 6LR that received the message.





Iannone & Lou           Expires 2 September 2024                [Page 9]

Internet-Draft                    GAAO                        March 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 5: 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 & Lou           Expires 2 September 2024               [Page 10]

Internet-Draft                    GAAO                        March 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 heading "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" sub-registry under the heading "Internet
   Control Message Protocol version 6 (ICMPv6) Parameters" as indicated
   in Table 3:

          +===============+===================+=================+
          | Value         | Description       | Reference       |
          +===============+===================+=================+
          | 6 (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 & Lou           Expires 2 September 2024               [Page 11]

Internet-Draft                    GAAO                        March 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-16,
              10 November 2023, <https://datatracker.ietf.org/doc/html/
              draft-ietf-6lo-multicast-registration-16>.



Iannone & Lou           Expires 2 September 2024               [Page 12]

Internet-Draft                    GAAO                        March 2024


   [I-D.thubert-6lo-prefix-registration]
              Thubert, P., "IPv6 Neighbor Discovery Prefix
              Registration", Work in Progress, Internet-Draft, draft-
              thubert-6lo-prefix-registration-03, 26 June 2023,
              <https://datatracker.ietf.org/doc/html/draft-thubert-6lo-
              prefix-registration-03>.

   [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 & Lou           Expires 2 September 2024               [Page 13]

Internet-Draft                    GAAO                        March 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-04, 1 March 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-6lo-
              path-aware-semantic-addressing-04>.

   [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 & Lou           Expires 2 September 2024               [Page 14]

Internet-Draft                    GAAO                        March 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




















Iannone & Lou           Expires 2 September 2024               [Page 15]