]> Huawei Technologies France S.A.S.U.

18, Quai du Point du Jour Boulogne-Billancourt 92100 France ggx@gigix.net

Huawei Technologies Duesseldorf GmbH

Riesstrasse 25 Munich 80992 Germany zhe.lou@huawei.com

adnanrashidpk@gmail.com

Internet 6lo Working Group Internet-Draft This document specifies an extension to the IPv6 Neighbor Discovery in Low Power and Lossy Networks (LLNs), enabling a node to request to be assigned an address or a prefix from neighbor routers, without introducing a centralized infrastructure and without relying on multicast messages. Such a mechanism makes it possible to algorithmically assign addresses and prefixes to nodes in a 6LoWPAN deployment. The proposed mechanism is more efficient in such specific scenario with respect to DHCPv6.

Introduction Low Power and Lossy Networks (LLNs) require adaptations of Internet protocols to operate efficiently under constraints such as limited energy, low data rates, constrained memory, and duty-cycled radio operation. In many LLN deployments, the wireless interface is the dominant source of energy consumption. As a result, protocol design must minimize transmissions, idle listening, and the number of nodes involved in control-plane operations. IPv6 Neighbor Discovery (ND) was optimized for LLNs in "ND Optimization for 6LoWPANs" and later extended by "Registration Extensions for 6LoWPAN ND", "IPv6 Backbone Router", "RPL", and "Multicast and Anycast Subscription". These specifications reduce multicast usage, limit control-plane participation, and introduce explicit address registration mechanisms to better support energy-constrained and duty-cycled devices.

Algorithmic and Distributed Address Assignment Recent work has demonstrated the benefits of algorithmically structured addressing in constrained networks (e.g., "6lo Applicability and Use Cases", "PASA", , , ). Such approaches can simplify routing, reduce forwarding state, and improve scalability. These schemes often require routers to assign addresses or prefixes according to a distributed Address Assignment Function (AAF). Existing mechanisms do not provide a standardized way, within the optimized ND framework defined by , for a 6LoWPAN Node (6LN) to explicitly request an address or prefix from a neighboring 6LoWPAN Router (6LR). In general IPv6 networks, address and prefix assignment are well supported by Stateless Address Auto-Configuration (SLAAC) and DHCPv6 . However, these mechanisms do not fully align with the architectural and operational goals of RFC8505-based 6LoWPAN deployments, particularly in scenarios requiring: Strict minimization of multicast traffic, Avoidance of centralized infrastructure, Localized control-plane interactions, Algorithmically structured address assignment to support routing optimizations. This document does not attempt to replace SLAAC or DHCPv6 in general IPv6 networks. Instead, it addresses specifically 6LoWPAN LLNs operating under RFC8505-based Neighbor Discovery optimizations, where nodes may need to request addresses or prefixes, usually algorithmically generated, directly from neighboring routers without introducing a centralized infrastructure (e.g. DHCPv6). In scenarios where a global centralized coordination of addresses and prefixes assignment is necessary, DHCPv6 remains the recommended solution.

Limitations of DHCPv6 in Constrained LLNs DHCPv6 relies on a client-server model and typically uses multicast (e.g., Solicit messages sent to ff02::1:2). While DHCPv6 is efficient in traditional IPv6 networks, including support for long lifetimes and reduced renewal frequency, its architectural model does not align with the distributed, strictly localized control-plane design promoted by RFC8505-based 6LoWPAN Neighbor Discovery. In IEEE 802.15.4 and similar LLNs, IPv6 multicast is commonly mapped to link-layer broadcast (, ). Such broadcasts cause all nodes on the channel to wake up and process the frame. In duty-cycled networks, this increases: Radio wake-ups, Idle listening time, Channel contention, Overall energy consumption. Furthermore, DHCPv6 requires a reachable server, often via relay agents, which may introduce multi-hop control paths and centralized state management. In lossy multi-hop LLNs, longer control paths increase failure probability and recovery cost. Further analysis is presented in .

Generic Address Assignment Option (GAAO) This document specifies a new neighbor discovery option, the Generic Address Assignment Option (GAAO), that enables a node to request an address or prefix directly from a neighboring router using RFC8505-based ND messages. The mechanism: Operates strictly at 1-hop, Avoids introducing a centralized infrastructure, Aligns with RFC8505 registration procedures, Supports distributed algorithmic address assignment. GAAO complements the Extended Address Registration Option (EARO) defined in and its extensions, integrating address/prefix assignment into the existing optimized ND framework for 6LoWPAN.

Terminology

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 when, and only when, they appear in all capitals, as shown here.

Acronyms This document assumes familiarity with the terminology defined in "ND Optimization for 6LoWPANs", "Registration Extensions for 6LoWPAN ND", IPv6 IID, "IPv6 Neighbor Discovery", and SLAAC. In particular for the following acronyms: 6CIO: Capability Indication Option 6LBR: 6LoWPAN Border Router 6LN: 6LoWPAN Node 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network 6LR: 6LoWPAN Router AAF: Address Assignment Function ARO: Address Registration Option EARO: Extended Address Registration Option GAAO: Generic Address Assignment Option IID: Interface IDentifier LLN: Low-Power and Lossy Network NA: Neighbor Advertisement ND: Neighbor Discovery NS: Neighbor Solicitation PfxLen: Prefix Length RA: Router Advertisement RS: Router Solicitation SLAAC: Stateless Address Auto-Configuration SLLAO: Source Link-Layer Address Option TLLAO: Target Link-Layer Address Option

Definition of Terms

Address Assignment Function (AAF):

The Address Assignment Function (AAF) is an implementation of the algorithm used by 6LRs/6LBR to assign an address/prefix to requesting nodes. In order to avoid addressing issues, only one AAF is used in a deployment. An AAF assigns either addresses or prefixes but not both. This allows in certain cases to indicate whether a node is requesting an address or a prefix.

GAAO: Generic Address Assignment Option defined in this specification (). GAAO is the exchange format an AAF can use for address/prefix assignments, but it is not itself an AAF.

Algorithmically Assigned Addresses and Prefixes The IPv6 address assignment model within a local layer-2 domain relies on Interface Identifiers (IIDs) generated with various techniques. These can be assigned using two main approaches: a centralized approach using DHCPv6 (), which guarantees collision-free addresses, or a decentralized approach using SLAAC (). Additional mechanisms are then required to ensure address uniqueness, via Duplicate Address Detection (DAD) , and security, like in Cryptographically Generated Addresses (CGA) , or Secure Neighbor Discovery (SEND) . However, there is a third approach for address assignment, which is distributed and collision-free: algorithmically generated addresses (e.g., , , , ). The Address Assignment Function (AAF) will work in a decentralized and distributed fashion. The AAF is used to assign addresses and prefixes to nodes as they join a network. To ensure consistency, all 6LoWPAN Nodes (6LNs), 6LoWPAN Routers (6LRs), and 6LoWPAN Border Routers (6LBRs) MUST use the same AAF within a given network instance. When a node needs an address/prefix, it first selects a neighboring 6LR/6LBR from those that responded to its initial Router Solicitation (RS) with a Router Advertisement (RA), as specified in . The node then sends an explicit request for an address/prefix to the chosen 6LR/6LBR (see for details about messages sequence and processing). The 6LR/6LBR assigns the address/prefix based on the AAF. Depending on the specific technology and algorithm in use, the 6LR/6LBR will either implicitly register this assignment to the requesting 6LN, or will indicate to the 6LN that an explicit registration of the assigned address/prefix is necessary to confirm its use. The overall process is illustrated in .

| \ | | + Request Phase 2. | Address/Prefix Offer | / | <-------------------------- | / | | 3. | Address/Prefix Acceptance | \ | --------------------------> | \ | | + Optional Explicit 4. | Address/Prefix Confirmation | / Registration Phase | <-------------------------- | / | | ]]>

The optional registration phase (steps 3 and 4) is implemented using the address/prefix registration procedures defined in , , or "Prefix Registration". In this phase, an Extended Address Registration Option (EARO) and SLLAO are used to register an address/prefix, which, in this context, is not self-generated. However, to initiate the process—specifically steps 1 and 2, a new Generic Address Assignment Option is required and defined in this document. Because no existing mechanism can be readily used for this purpose. The remainder of this document first defines the format of this option (see ), followed by a revised sequence and processing of Address/Prefix assignment messages (see ).

Generic Address Assignment Option Format In order for a 6LN to request the assignment of an address or prefix, GAAO message is used. The format of the GAAO message is shown in .

Generic Address Assignment Option Fields:

Type:

TBD

Length:

8-bit unsigned integer. The length of the option in units of 8 octets. This field is set to 1 plus the size of the ROVR field when there is no address/prefix appended to the option. Its value is augmented by 2 (16 octets) when an address/prefix is appended to the option.

Status:

As defined in .

Opaque:

As defined in .

R:

1-bit flag for explicit Registration being requested. It MUST be initialized to 0 in Neighbor Solicitation (NS) messages by the requester and MUST be ignored by the receiver. The 6LR/6LBR replying to the request with a Neighbor Advertisement (NA) message MAY set this bit to indicate that it requests a confirmation that the address/prefix is accepted and will be used. When the 6LR/6LBR sets the R-flag in a NA(GAAO) message, it indicates that no registration state has been created and that the requester MUST explicitly register the received address/prefix to the same 6LR/6LBR using the procedures defined in , , and , according to the type of the assigned address/prefix. When the 6LR/6LBR does not set this R-flag, it indicates that the assigned address/prefix has been also registered and state created as specified in , , and , according to the type of the assigned address/prefix. In the event that the 6LN does not want to use the allocated address/prefix, it can de-register the allocation by sending an NS(EARO) setting registration lifetime to zero, as defined in .

C:

1-bit flag for Crypto-ID used for ROVR as defined in "Address Protection ND for LLN" and "Fixing C-FLag in RFC 8928". This flag MUST be set when the ROVR field contains a Crypto-ID.

Reserved:

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

PfxLen:

7-bit unsigned integer. It indicates the length in bits of the address/prefix carried in the option.

AAF:

4-bit unsigned integer. Describes the Address Assignment Function (AAF), i.e. the algorithm, used to assign the address/prefix. 0 is a special value indicating that the field is not used. In an NS(GAAO) message, this field is set to 0 to indicate that there is no preference on how the address/prefix is assigned. However, a 6LN MAY use a value different from 0, to indicate that it is requesting the use of a specific AAF to assign the address/prefix. In the case that the requested AAF is not used in the specific deployment, an error condition is returned, see for details. describes possible values of this field.

Assignment Lifetime:

16-bit unsigned integer, expressed in minutes. In an NS(GAAO) message, the field expresses a desired lifetime. It MAY be set to zero, indicating no particular desired lifetime. In an NA(GAAO) message it expresses the granted lifetime. A node MUST NOT use the address/prefix after expiration of the lifetime. Address/prefix lifetime MUST be configurable according to the AAF in use and as mitigation of certain attacks (see ).

ROVR:

As defined in and extended in and .

Address/Prefix:

128-bit IPv6 address/prefix. This field MAY be present in NS(GAAO) request messages to indicate the prefix from which the address or sub-prefix has to be derived. If not present in an NS(GAAO) message, it means that the address returned in an NA(GAAO) message is implicitly used on the interface used to send the request. This field MUST be present in NA(GAAO) messages that return a successful address/prefix allocation, but MUST NOT be present in case of error. When the field is used return a prefix, the leftmost bits are used for its encoding according to the length field, the remaining bits are set to zero. The presence of this field is indicated by the length field (cf. above).

Messages Sequence and Processing When a node bootstraps (or in case of a neighbor unreachability detection), it sends an RS message via multicast and receives one or more unicast RA messages from neighbor 6LRs. The node MAY choose one or more 6LRs from which to request address(es) or prefix(es). A node MAY perform a request at any time, not necessarily at boot time, using NS and NA messages.

Request Phase When the node requests an address/prefix, the node will go through the following steps: The node will issue an NS(GAAO) message to obtain the address/prefix. In this initial address request, GAAO Status field MUST be set to 0. Opaque, ROVR, and C-flag are set according to the local configuration. R-Flag MUST be set to 0. The AAF field MUST be set to zero unless by configuration there is a preference for the assignment algorithm. The Assignment Lifetime field MAY be set to the desired lifetime, or zero otherwise. The Address/Prefix field MAY be present to indicate the prefix from which the address or sub-prefix has to be derived. In this case the PfxLen field MUST be set accordingly. If the Address/Prefix field is not present, the PfxLen field MUST be set to 0. Assuming no errors occur, the node will receive an NA(GAAO) message where all fields have been copied back except for: Pfxlen: Now indicating the actual length of the prefix. For address assignments this field MUST be set to 64. R: The R-bit is set if the 6LR requests an explicit registration. AAF: It is the algorithm, used to assign the address/prefix. If the node is a 6LR it MUST use the same AAF to generate addresses/prefixes to requesting neighbor nodes in the 6LoWPAN network. Assignment Lifetime: The maximum lifetime of the assigned address/prefix. The message sequence is depicted in .

| | NS (GAAO) | | | | Address/Prefix Offer | 2. | <--------------------------------------- | | NA (GAAO) | | | ]]>

Explicit Registration Phase (Optional) Depending on the algorithm in use and the underlying technology, the address/prefix assignment procedure terminates after these two messages. This may be sufficient for instance in deployments where the link-layer offers reliable packet delivery. The use of this option is done by configuration on 6LRs. Documents defining AAFs MUST explicitly state whether this phase remains optional or is mandatory due to factors specific to the proposed algorithm. If the R-flag is set in the received NA(GAAO) message, the 6LN MUST register with the obtained address/prefix by following the procedures in , , or depending on the type of address/prefix. When setting the R-flag, and as for , the 6LR is expected to receive a registration within RETRANS_TIMER multiplied by MAX_UNICAST_SOLICIT. If no registration is received within this amount of time the 6LR will consider that address/prefix is not in use by the requesting 6LN. The complete sequence of actions is depicted in .

| | NS(GAAO) | | | | Address/Prefix Offer | 2. | <------------------------------------------- | | NA(GAAO) | | | | Address/Prefix Registration Request | 3. | -------------------------------------------> | | NS(EARO + SLLAO) | | | ... Procedure According to [RFC8505], [RFC9685], or [RFC9926] depending on the type of address. ... | | | Address/Prefix Registration Response | 4. | <------------------------------------------- | | NA(EARO with Status + SLLAO) | | | ]]>

, , and , define how nodes keep address/prefix registration state in order to maintain addressing in case of reboot. When needed, in order to use this feature with GAAO, after reboot the registration phase MUST be used to perform an explicit registration and continue using the address/prefix. However, when using GAAO, and when performing the re-registration, if a "Registration Refresh Request" or "Invalid Registration" Status value is returned, the node MUST restart from the top with the initial Request Phase.

Message Exchange Optimization There are two ways to optimize the prefix/address Request Phase: GAAO with Address Registration and GAAO with Router Discovery.

GAAO with Router Discovery Another optimization for prefix/address requests can be performed during the bootstrapping phase of a 6LN. The GAAO MAY be included in the initial RS message, thereby implicitly indicating that the node supports this specification. Similarly, 6LR/6LBR that support this specification MUST include a prefix/address offer in a GAAO appended to the corresponding RA message, as depicted in .

| | (6CIO + SLLAO + GAAO) | | | | RA message | 2. | <--------------------------------------- | | (PIO + 6CIO + ABRO + SLLAO + GAAO) | | | ]]>

A 6LR/6LBR that does not support GAAO will simply ignore this option, and the corresponding RA message will not include a GAAO. This behavior implicitly signals that the feature is not supported.

GAAO with Address Registration Prefix/address Registration utilize NS/NA transactions for the link-local address registration . In this specification, the prefix/address Request procedure utilizes an additional NS/NA transaction. To minimize the number of transactions, GAAO MAY be used together with the EARO option during address registration phase. This piggybacking approach provides flexibility and maintains compatibility with existing specifications . In response the NA message will contain GAAO. illustrates the GAAO piggybacked within a link-layer address registration request and response. Piggybacking can be done within the MTU limit of the underlying technology, since ND messages cannot be fragmented.

| | NS(EARO + SLLAO + GAAO) | | | | Address Registration Response | 2. | <--------------------------------------- | | NA(EARO with Status + SLLAO + GAAO) | | | ]]>

Error Conditions GAAO Status field uses the same Status values defined in and , further revised in , for error reporting. This specification introduces a new Status value when the AAF in GAAO in an NS message is not in use in the 6LoWPAN network, as follows (see also ):

AAF Not Used:

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

This status MUST be used when a node requesting an address/prefix has set an AAF value, in the corresponding field, which is not in use in the 6LoWPAN network. When the node receives this status back it SHOULD perform one of the following actions: Re-issue the same request without specifying an AAF, meaning set the AAF field to 0. The 6LR will return the AAF in use in the 6LoWPAN network and employed to generate the returned address/prefix. If the requesting node does not support the returned AAF it does not participate in the AAF-based 6LoWPAN network and does not use the proposed address/prefix. Re-issue the same request with a different AAF. The 6LoWPAN network is not using the requested AAF but may be using a different one. Note that such an approach may lead to repeated requests that may consume bandwidth and energy. Do nothing and do not participate in the AAF-based 6LoWPAN network. The action to be used is selected by configuration. When nodes fail to participate in the AAF-based 6LoWPAN network they MAY still use a different mechanism (e.g., ) to configure addresses/prefixes.

Signaling GAAO Support This specification defines a new capability bit, named M-flag, for use in the 6CIO as defined by Section 3.3 ("6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks"). A 6LN that supports this specification MUST set the M-flag in RS and RA messages.

M:

1-bit flag. The node supports managed addresses/prefixes via the Generic Address Assignment Capability.

IANA Considerations This section requests that Internet Assigned Numbers Authority (IANA) registers values related to the GAAO specification, in accordance with BCP 26 .

IPv6 Neighbor Discovery (ND) Option Types IANA is requested to make an addition to the "IPv6 Neighbor Discovery Option Formats" registry , under the heading "Internet Control Message Protocol version 6 (ICMPv6) Parameters", as indicated in : Type Description Reference TBD Generic Address Assignment Option [This Document]

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 : Bit Description Reference 17 (Suggested) M-Flag for Generic Address Assignment Capability [This Document]

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 : Value Description Reference 13 (Suggested) AAF Not Used [This Document]

Address Assignment Function Registry IANA is asked to create a registry group named "6LoWPAN Generic Address Assignment Option", under the registry group "Internet Control Message Protocol version 6 (ICMPv6) Parameters". Such registry group should be populated with an octet registry named "Address Assignment Function" and used to identify the used AAF. The registry is populated as shown in : Value AAF Name Reference 0x0 No AAF. This can be used only in NS message to indicate that no specific AAF is demanded. [This Document] 0x1-0xE Un-assigned   0xF Experimental Use. Used for experimental purposes during implementation of new AAFs. [This Document] Values can be assigned by IANA, after this document is published, using the "RFC Required" procedure according to .

Security Considerations This document extends , which already extended , as such the security considerations of both documents apply to this specification. In particular, the link layer MUST provide sufficient protection to prevent potential attacks. Recommendations listed in Section 7 of MUST be applied as well to this specification. Depending on the AAF in use, the number of available addresses may encounter limitations. A rouge node may leverage on this knowledge to carry out address exhaustion attacks by impersonating different nodes and performing multiple requests. To mitigate such risks the recommendation about the lifetime and number of addresses per node described in Section 7 of remains valid. Furthermore, depending on the AAF, the algorithmically built addresses may reveal topological or other private information. Documents specifying a new AAF MUST discuss such aspects.

Acknowledgements This document received many comments and help from community people. The authors would like to thank all of them. Thanks as well to Joel Halpern (GENART) and Brian Haberman (INTDIR) for their reviews that helped to spot overlooked points in the definition of the GAAO mechanism. Thanks to Pascal Thubert for his help in making this specification more integrated with existing 6LoWPAN specifications. Thanks to Carles Gomez Montenegro for his very thorough shepherd review. Thanks to Lorenzo Colitti for helping to clarify the scope of GAAO with respect to DHCPv6. Thanks to Eric Vyncke for the excellent AD review.

The IETF work in IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks. The document thus updates RFC 4944 to specify the use of the optimizations defined here. [STANDARDS-TRACK] This specification updates RFC 6775 -- the Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery specification -- to clarify the role of the protocol as a registration technique and simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies, including the Routing Registrars performing routing for host routes and/or proxy Neighbor Discovery in a low-power network. This document updates RFCs 6775 and 8505 in order to enable proxy services for IPv6 Neighbor Discovery by Routing Registrars called "Backbone Routers". Backbone Routers are placed along the wireless edge of a backbone and federate multiple wireless links to form a single Multi-Link Subnet (MLSN). This specification provides a mechanism for a host that implements a routing-agnostic interface based on IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery to obtain reachability services across a network that leverages RFC 6550 for its routing operations. It updates RFCs 6550, 6775, and 8505. This document updates the 6LoWPAN extensions to IPv6 Neighbor Discovery (specified in RFCs 4861 and 8505) to enable a listener to subscribe to an IPv6 anycast or multicast address. This document also updates the Routing Protocol for Low-Power and Lossy Networks (RPL) (specified in RFCs 6550 and 6553) to add a new Non-Storing multicast mode and new support for anycast addresses in Storing and Non-Storing modes. This document extends RFC 9010 to enable a 6LoWPAN Router (6LR) to inject the anycast and multicast addresses in RPL. This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The IPv6 addressing architecture includes a unicast interface identifier that is used in the creation of many IPv6 addresses. Interface identifiers are formed by a variety of methods. This document clarifies that the bits in an interface identifier have no meaning and that the entire identifier should be treated as an opaque value. In particular, RFC 4291 defines a method by which the Universal and Group bits of an IEEE link-layer address are mapped into an IPv6 unicast interface identifier. This document clarifies that those two bits are significant only in the process of deriving interface identifiers from an IEEE link-layer address, and it updates RFC 4291 accordingly. This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK] This document updates IPv6 Neighbor Discovery (RFC 4861) and IPv6 Subnet Neighbor Discovery (RFC 8505, RFC 8928) to enable a node that owns or is directly connected to a prefix to register that prefix to neighbor routers. The registration indicates that the registered prefix can be reached via the advertising node without a loop. The unicast prefix registration allows the node to request one or more neighbor routers to redistribute the prefix in another routing domain regardless of the routing protocol used in that domain. This document updates the Routing Protocol for Low-Power and Lossy Networks (RPL), as specified in RFCs 6550 and 9010, to enable a 6LoWPAN Router (6LR) to inject the registered prefix in RPL. This document updates the IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery (ND) protocol defined in RFCs 6775 and 8505. The new extension is called Address-Protected Neighbor Discovery (AP-ND), and it protects the owner of an address against address theft and impersonation attacks in a Low-Power and Lossy Network (LLN). Nodes supporting this extension compute a cryptographic identifier (Crypto-ID), and use it with one or more of their Registered Addresses. The Crypto-ID identifies the owner of the Registered Address and can be used to provide proof of ownership of the Registered Addresses. Once an address is registered with the Crypto-ID and a proof of ownership is provided, only the owner of that address can modify the registration information, thereby enforcing Source Address Validation. This document updates "Address-Protected Neighbor Discovery for Low-Power and Lossy Networks" (RFC 8928) by changing the position of the C-flag in the Extended Address Registration Option (EARO) and registering it with IANA. RFC 6282 defines header compression in 6LoWPAN packets (where "6LoWPAN" refers to "IPv6 over Low-Power Wireless Personal Area Network"). The present document specifies a simple addition that enables the compression of generic headers and header-like payloads, without a need to define a new header compression scheme for each such new header or header-like payload. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Institute of Telematics, Karlsruhe Institute of Technology (KIT) Institute of Telematics, Karlsruhe Institute of Technology (KIT) Huawei Research Center,Munich,Germany Huawei Research Center,Munich,Germany Computer Engineering, Konya Food and Agriculture University, Meram, Turkey Computer Science, Groningen University Faculty of Science and Engineering, Groningen, Netherlands Computer Engineering, Konya Food and Agriculture University, Meram, Turkey Computer Engineering, Konya Food and Agriculture University, Meram, Turkey This document describes the applicability of IPv6 over constrained-node networks (6lo) and provides practical deployment examples. In addition to IEEE Std 802.15.4, various link-layer technologies are used as examples, such as ITU-T G.9959 (Z-Wave), Bluetooth Low Energy (Bluetooth LE), Digital Enhanced Cordless Telecommunications - Ultra Low Energy (DECT-ULE), Master-Slave/Token Passing (MS/TP), Near Field Communication (NFC), and Power Line Communication (PLC). This document targets an audience who would like to understand and evaluate running end-to-end IPv6 over the constrained-node networks for local or Internet connectivity. Huawei Technologies France S.A.S.U. Huawei Technologies Huawei Technologies Duesseldorf GmbH China Mobile This document specifies a topological addressing scheme, Path-Aware Semantic Addressing (PASA), that enables stateless IP packet forwarding. The forwarding decision is based solely on the destination address structure. This document focuses on carrying IP packets across an LLN (Low power and Lossy Network), in which the topology is quite static, the location of the nodes is fixed for long period of time, and the connection between the nodes is also rather stable. This document specifies the PASA architecture, along with the PASA address allocation, forwarding mechanism, routing header format, and IPv6 interconnection support. This document specifies the Dynamic Host Configuration Protocol for IPv6 (DHCPv6), an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document obsoletes RFC 8415. It incorporates verified errata and obsoletes the assignment of temporary addresses (the IA_TA option) and the server unicast capability (the Server Unicast option and UseMulticast status code). This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. Cryptographically Generated Addresses (CGA) are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. The protection works without a certification authority or any security infrastructure. [STANDARDS-TRACK] IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms for NDP. Unlike those in the original NDP specifications, these mechanisms do not use IPsec. [STANDARDS-TRACK] Well-known issues with multicast have prevented the deployment of multicast in 802.11 (Wi-Fi) and other local-area wireless environments. This document describes the known limitations of wireless (primarily 802.11) Layer 2 multicast. Also described are certain multicast enhancement features that have been specified by the IETF and by IEEE 802 for wireless media, as well as some operational choices that can be made to improve the performance of the network. Finally, some recommendations are provided about the usage and combination of these features and operational choices.

Analytical comparison of GAAO and DHCPv6 DHCPv6 is typically used in traditional Ethernet or Wi-Fi networks, it is rarely used in 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks) deployments for several critical reasons rooted in efficiency and resource constraints. considers that the use of multicast transmissions over IEEE 802 wireless technologies may create issues related to: Reliability; Lower and variable data rate; Capacity and impact on interference; Power-save effects on multicast; Hence, the intensive use of multicast may not be optimal. lists DHCPv6 among the protocols that make an extensive use of multicast. Neighbor Discovery is also listed, as multicast optimization in this protocol is one of the reasons that lead to the 6LoWPAN protocol stack development (cf. and ). An extensive study comparing and , showing the inefficiency of the former in 6LoWPAN deployments, can be found in . In rare cases, Stateless DHCPv6 is used in 6LoWPAN just to pass "Other" information (like DNS server addresses or NTP servers) if the Router Advertisements don't provide them. However, for actual address assignment, it is almost non-existent in the context of 6LoWPAN. In 6LoWPAN deployments, the use of DHCPv6 entails running an additional service on the 6LRs, beside the 6LoWPAN ND. Running an additional service will have impact on memory usage and battery lifetime. GAAO requires only that the implementation supports the GAAO option, as it is part of the 6LoWPAN ND already present and running, hence, preserving the efficiency of as shown in .

DHCPv6 Message Structure A typical DHCPv6 exchange involves four messages: Solicit (from 6LN to server - multicast) Advertise (from server to 6LN - unicast) Request (from 6LN to server - multicast) Reply (from server to 6LN - unicast) Message payload (not including link/IPv6/UDP headers): Solicit: 30 octets (minimal size - typical 80 to 150 octets) Advertise: 32 octets (minimal size - typical 100 to 180 octets) Request: 38 octets (minimal size - typical 80 to 150 octets) Reply: 32 octets (minimal size - typical 100 to 200 octets) Size of a minimal exchange: 132 octets (or 70 octets when using Rapid Commit option). DHCPv6 needs dedicated messages which are multicast (depending on the message type) and may span several layer-2 links depending on where the server is placed. As such, channel access and headers' overhead cannot be shared with other messages. In a simple deployment with the server directly accessible on the same layer-2 link, four different messages are necessary with the first and the third being multicast. DHCPv6 includes a "Rapid Commit" option that reduces the exchange to only two messages, namely a Solicit and a Reply, with the first being multicast.

GAAO Structure A typical GAAO exchange involves two messages, each one carrying one GAAO option: GAAO in NS (from 6LN to 6LR - unicast) GAAO in NA (from 6LR to 6LN - unicast) Option size: - GAAO option (24 octets in NS messages and 40 octets on NA messages) Size of a typical exchange: 62 octets. GAAO does not need to be transmitted on dedicated messages. It can be piggybacked on ND messages carrying other options, hence sharing the channel access and headers' overhead with these other options. If not piggybacked, the exchange requires two unicast messages. In both cases the exchange takes place on one single layer-2 link.

DHCPv6 vs GAAO Address Configuration From an abstract point of view, for a 6LN to obtain an address several messages need to be exchanged, as summarized in .   Octets Exchanged Multicast Messages Unicast Messages L2 links DHCPv6 142 2 2 multiple DHCPv6 Rapid Commit 70 1 1 multiple GAAO 62 0 2 1 In generic and realistic 6LoWPAN deployments, the GAAO option can be piggybacked on other ND messages, hence sharing header and channel access overhead, and it is just transmitted 1-hop away. DHCPv6, cannot share such overhead with other data, specific packets need to be sent per each message. Additionally, unicast messages may span several hops, since the DHCPv6 server is usually deployed on the 6LBR, consuming network resources (e.g., energy, network bandwidth) and experiencing higher latency. The multicast message may even trigger a (resource expensive) network wide broadcast, as explained in . Address renewal bears a similar cost for both DHCPv6 and GAAO in terms of size, with GAAO having a slightly smaller message length, assuming DHCPv6 packets use the minimal size. The difference lays in the fact that in DHCPv6, the Renew message is also a multicast message, and that messages may traverse several hops, to reach the DHCPv6 server, hence consuming more resources (e.g., energy, network bandwidth, etc.). In case of dense and noisy environment, with higher likelihood of packet losses, this may lead to nodes not being able to renew the DHCPv6 address lease, and the node needing to restart address request using the multicast-based 4-packets exchange.

6LoWPAN MTU Constraint 6LoWPAN deployments may have very small MTU limits. For instance, IEEE 802.15.4 frame size is only 127 octets (max PHY layer payload). Assuming that DHCPv6 is configured to use the bare minimal options, there should be no MTU issues neither for DHCPv6 nor GAAO. If the minimal options condition is not respected, fragmentation may be needed for DHCPv6 large messages, increasing delay and energy consumption. GAAO has a fixed size, hence the only consequence is that it can be piggybacked with other options only if the MTU limit is respected.

Energy Consumption Since DHCPv6 has to deliver almost twice the number of octets compared to GAAO, in terms of pure energy/octet consumption DHCPv6 uses almost double the energy. Because the number of messages is also doubled, there is an additional overhead due to 6LN accessing the channel four times, with nodes staying awake longer which in turn consumes more energy. Any communication pattern that forces many nodes to wake up and receive packets (such as broadcast or multicast) has a disproportionately large impact on battery lifetime .

Multicast Inefficiency It is worth noting that the unicast messages are all 1-hop, while the multicast messages must be distributed to the whole network . Furthermore, multicast in 6LoWPAN is inefficient due to the actual lack of multicast support at lower layers, which is emulated either via broadcast or via unicast floods. Broadcast is generally less energy-efficient than unicast for targeted communication because it sends packets to all nodes, including those not interested in the data, no ACKs are used, so retransmissions for reliability must be handled at higher layers, potentially increasing energy usage, and all nodes must wake up and process the broadcast packet, even if they are not the intended recipients (, ). Unicast floods may increase reliability, however, depending on the topology it may lead to higher latency and increased energy consumption.