Hello 6lo WG,
In order to move the GAAO idea forward, we would like to have some help and
gather more feedback about it, in particular on the proposed format.
(The full document can be found at:
https://datatracker.ietf.org/doc/draft-iannone-6lo-nd-gaao/)
The proposed format of the option is:
~~~
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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~~~
(for convenience the definitions as for the current document is provided at the
bottom of this mail)
Points we would like to have feedback/opinions/help are:
1) Type; Length; Status/Pfxlen; AAF; Assignment Lifetime, F (defined in
draft-thubert-6lo-prefix-registration); P (defined in
draft-6lo-multicast-registration)
They are the minima to make the mechanism work we do not see particular changes
to be done on these. Anyone having a different opinion?
2) About flags I and Opaque:
RFC8505 defines them to be used: “I=0 indicates that the Opaque field carries
an abstract index that is used to decide in which routing topology the address
is expected to be injected.”
This was also pointed out by Pascal during last meeting, imply that strict
coherence with EARO format is not necessary.
Our thoughts were to use I+Opaque in GAAO to request a prefix/address in a
specific routing topology, so that the same fields can be set in the
registration following GAAO. Does it make sense?
Can be the default option I=0 + Opaque =0? Or is it not so useful?
3) Another question not discussed so far is about ROVR. Does it make sense to
use it as an ID in prefix requests? To be used as a token for the transaction?
Any opinion?
Thank you in advance for any feedback.
Ciao
Luigi & David
~~~~~~
Fields definition
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
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.
luigi.iann...@huawei.com<mailto:luigi.iann...@huawei.com>
Paris Research Center
Huawei Technologies France S.A.S.U.
________________________________
This e-mail and its attachments contain confidential information from HUAWEI,
which is intended only for the person to whom it is addressed. If you are not
the intended recipient of this email, please notify immediately the sender by
phone or email and delete it. Any use of the information contained herein in
any way, including, but not limited to, total or partial disclosure,
reproduction, or dissemination, by persons other than the intended recipient(s)
is prohibited, unless expressly authorized by HUAWEI.
HUAWEI Technologies France SASU (“HUAWEI”) respects your privacy and is
committed to the protection of your personal data. Your personal data included
in this email and/or its attachments may be processed by HUAWEI. In compliance
with Regulation (EU) 2016/679 (GDPR) and French data protection law of 6
January 1978 as amended, you can exercise at any time your rights of access,
rectification or erasure of your personal data, as well as your rights to
restriction, portability or object to the processing by sending us your request
via the form available at https://www.huawei.com/fr/personal-data-request or a
letter to the following address: HUAWEI Technologies France, Privacy Officer,
18 quai point du jour, 92100 Boulogne-Billancourt, France. To know more about
how HUAWEI processes your personal data, please contact
us<https://www.huawei.com/fr/personal-data-request/>.
_______________________________________________
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
