Generic Address Assignment Option for 6LowPAN Neighbor Discovery
draft-iannone-6lo-nd-gaao-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Luigi Iannone , Zhe Lou | ||
| Last updated | 2023-07-10 | ||
| Replaced by | draft-ietf-6lo-nd-gaao | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-iannone-6lo-nd-gaao-00
6lo Working Group L. Iannone
Internet-Draft D. Lou
Intended status: Standards Track Huawei
Expires: 11 January 2024 10 July 2023
Generic Address Assignment Option for 6LowPAN Neighbor Discovery
draft-iannone-6lo-nd-gaao-00
Abstract
This document specifies a mechanism enabling a node to request the
allocation of 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 11 January 2024.
Copyright Notice
Copyright (c) 2023 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 11 January 2024 [Page 1]
Internet-Draft GAAO July 2023
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Generic Address Assignment Option . . . . . . . . . . . . . . 5
5. Messages Sequence . . . . . . . . . . . . . . . . . . . . . . 7
6. Signaling GAAO Support . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7.1. IPv6 ND Option Types . . . . . . . . . . . . . . . . . . 8
7.2. 6LoWPAN Capability Bits . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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 basically 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], [RFC8505], [I-D.thubert-6lo-prefix-registration],
[I-D.ietf-6lo-multicast-registration]).
Recent use cases show however, that there is some advantages in
assigning addresses algorithmically, which may simplify packet
forwarding in some scenarios
([I-D.ietf-6lo-path-aware-semantic-addressing], [SHENOY21],
[BLESS22], [RIDOUX05]), hence reducing the power consumption and
memory footprint. Each 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.
Iannone & Lou Expires 11 January 2024 [Page 2]
Internet-Draft GAAO July 2023
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 their direct neighbors. Currently, either auto-
configuration is used, or DHCP has to be deployed.
This document proposes a new Neighbor Discovery Option, namely the
Generic Address Assignment Option (GAAO), in order for a node to
issue an address request to their neighbors. In oder to work
properly, as explained later, the GAAO option must be coupled with
the Extended Address Registration Option, as 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] and [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
ARO: Address Registration Option
EARO: Extended Address Registration Option
LLN: Low-Power and Lossy Network
NA: Neighbor Advertisement
ND: Neighbor Discovery
NS: Neighbor Solicitation
Iannone & Lou Expires 11 January 2024 [Page 3]
Internet-Draft GAAO July 2023
RA: Router Advertisement
RS: Router Solicitation
# Algorithmically Assigned Addresses
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 Allocation Function
(AAF) to assign addresses to nodes joining a network. 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), and then ask for an
address and confirm its usage. The sequence of actions is depicted
in {Fig:AAFSeq}
6LN 6LR
| |
| 1. Address Request |
|------------------------>|
| |
| 2. Address Offer |
|<------------------------|
| |
| 3. Address Acceptation |
|------------------------>|
| |
| 4. Address Confirmation |
|<------------------------|
Figure 1: Address/Prefix assignment sequence.
Iannone & Lou Expires 11 January 2024 [Page 4]
Internet-Draft GAAO July 2023
Steps 3 and 4 of the sequence of actions can 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 4),
followed by a revised Address/Prefix assignment sequence (Section 5).
4. Generic Address Assignment Option
In order for a node to request the assignment of an address or
prefix, the Generic Address Assignment Option (GAAO) message is used.
The format of the GAAO message is shown in Figure 2.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Status/PfxLen | Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|F| P | I |Rsd| AAF | Assignment Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 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 when the option is used in NS
messages. It is set to 3 when this option is used in NA messages
because the assigned address/prefix is appended to the option.
Status/PfxLen: 8-bits unsigned integer. It indicates the Prefix
Iannone & Lou Expires 11 January 2024 [Page 5]
Internet-Draft GAAO July 2023
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 be
set to 3. This field can indicate an error code (See table 1 in
[RFC8505] for error codes) if the assignment failed. On failure,
the returned GAAO message will not have any address/prefix
appended to it. Hence it will have the Length field set to 1,
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].
R (Reserved): This field is unused. It MUST be initialized to 0 by
the sender and MUST be ignored by the receiver.
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 Allocation Function(AAF): 1-byte unsigned integer. Describe
the allocation 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 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
AAF to assign the address/prefix.
Assignment Lifetime: 16-bit integer, expressed in minutes. In NS
message the field expresses the minimum requested lifetime. In NA
messages it expresses the 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.
Iannone & Lou Expires 11 January 2024 [Page 6]
Internet-Draft GAAO July 2023
5. 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
option of the first RS message, while responding routers can offer an
address in the RA message. The mechanism is completely optional. If
the node requests an address, the node will go through the following
steps (it is assume that the node already registered a link-local
address to the same 6LR):
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 1 (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 P-bits is 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 requested lifetime, or zero otherwise.
2. Assuming no errors occur, the node will receive an NA with a GAAO
option of length 3, 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.
* AAF: Indicating the Address Allocation 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.
3. In order to confirm the acceptance and usage of the proposed
address 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.
This sequence of actions is also depicted in Figure 3, which update
the sequence prposed in Figure 1.
Iannone & Lou Expires 11 January 2024 [Page 7]
Internet-Draft GAAO July 2023
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 3: Address/Prefix assignment with GAAO message sequence.
6. Signaling GAAO Support
A 6LowPAN node that supports this specification MUST set the A 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 |A|D|L|B|P|E|G|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: New GAAO Capability Bit in the 6CIO.
A: The node supports the Generic Address Assignment Capability.
7. IANA Considerations
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:
Iannone & Lou Expires 11 January 2024 [Page 8]
Internet-Draft GAAO July 2023
+================+===================================+===========+
| Type | Description | Reference |
+================+===================================+===========+
| 42 (Suggested) | 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 heading "Internet Control Message Protocol
version 6 (ICMPv6) Parameters" as indicated in Table 2:
+================+============================+===========+
| Bit | Description | Reference |
+================+============================+===========+
| 16 (Suggested) | Generic Address Assignment | [This |
| | Capability (A) Flag | Document] |
+----------------+----------------------------+-----------+
Table 2: New 6LoWPAN Capability Bit.
8. Security Considerations
A security analysis of the proposed mechanism will be provided in
future revisions of the document.
9. References
9.1. 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-15,
30 May 2023, <https://datatracker.ietf.org/doc/html/draft-
ietf-6lo-multicast-registration-15>.
[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>.
Iannone & Lou Expires 11 January 2024 [Page 9]
Internet-Draft GAAO July 2023
[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>.
[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>.
9.2. 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-
Iannone & Lou Expires 11 January 2024 [Page 10]
Internet-Draft GAAO July 2023
semantic-addressing-02, 10 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-6lo-
path-aware-semantic-addressing-02>.
[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>.
[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>.
[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
Iannone & Lou Expires 11 January 2024 [Page 11]
Internet-Draft GAAO July 2023
David Lou
Huawei Technologies Duesseldorf GmbH
Riesstrasse 25
80992 Munich
Germany
Email: zhe.lou@huawei.com
Iannone & Lou Expires 11 January 2024 [Page 12]