To solve this issue, I suggest to add text to 7.2. of
draft-ietf-6lo-prefix-registration:
"
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 |F|PrefixLength | Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |C| P | I |R|T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Registration Ownership Verifier ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: EARO Option Format in NS messages
New and updated Option Fields:
<..>
C: 1-bit flag; moved from its position in Figure 1 of [RFC8928], see
Section 9.
"
And in section 9:
"
[RFC8928] defines the "C" flag but fails to explicit the bit number
and fails to make a IANA registration for that bit position. On the
other hand, a position for the bit (bit 3) is represented in Figure 1
of [RFC8928]. [RFC9685] defines the P-Field in bits 2 and 3 of the
EARO flags field, obtains a proper IANA registration, but causes an
overlap with the representation in Figure 1 of [RFC8928]. This
specification updates [RFC8928] to position the "C" flag as bit 1 of
the EARO flag, as represented in Figure 5, to avoid the overlapping
definitions.
"
And finally in the IANA section:
"
12.2. Bit Position of the "C" Flag
This specification updates the location of the "C" flag introduced in
[RFC8928] to position it as bit 1 in the EARO flags. IANA is
requested to make an addition to the "Address Registration Option
Flags" [IANA.ICMP.ARO.FLG] registry under the heading "Internet
Control Message Protocol version 6 (ICMPv6) Parameters" as indicated
in Table 3:
+---------------+----------+-----------+
| ARO flag | Meaning | Reference |
+---------------+----------+-----------+
| 1 (suggested) | "C" Flag | RFC 8928 |
+---------------+----------+-----------+
Table 3: Bit Position of the "C" Flag
"
Does that work?
All the best
-----Message d'origine-----
De : Pascal Thubert <[email protected]>
Envoyé : jeudi 20 mars 2025 20:21
À : Errata System RFC <[email protected]>
Cc : [email protected]; [email protected]; [email protected];
[email protected]; [email protected]; [email protected];
[email protected]
Objet : Re: [6lo] [Technical Errata Reported] RFC9685 (8340)
Dear all
I’d suggest that the mistake is on RFC 8928 not this.
The reason being that we failed at the time to ask for a IANA registration
which would have allowed to detect the overlap.
This erratum would imply to change IANA but wouldn’t fix the missing entry…
A bientôt;
Pascal
> Le 20 mars 2025 à 14:52, RFC Errata System <[email protected]> a
> écrit :
>
> The following errata report has been submitted for RFC9685, "Listener
> Subscription for IPv6 Neighbor Discovery Multicast and Anycast Addresses".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid8340
>
> --------------------------------------
> Type: Technical
> Reported by: Adnan Rashid <[email protected]>
>
> Section: 7.1
>
> Original Text
> -------------
> 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 | Opaque |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |Rsv| P | I |R|T| TID | Registration Lifetime |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | |
> ... Registration Ownership Verifier (ROVR) ...
> | |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Corrected Text
> --------------
> 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 | Opaque |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |R| P |C| I |R|T| TID | Registration Lifetime |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | |
> ... Registration Ownership Verifier (ROVR) ...
> | |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Notes
> -----
> The EARO format in RFC 9685 (Figure 5) omits the C-flag, which was
> previously defined in RFC 8928. This inconsistency could lead to issues in
> implementation and interoperability. It is important to ensure that newer
> standards respect and align with existing conventions.
> small "R" is a single unused/Reserved bit.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". (If it is spam, it
> will be removed shortly by the RFC Production Center.) Please use
> "Reply All" to discuss whether it should be verified or rejected. When
> a decision is reached, the verifying party will log in to change the
> status and edit the report, if necessary.
>
> --------------------------------------
> RFC9685 (draft-ietf-6lo-multicast-registration-19)
> --------------------------------------
> Title : Listener Subscription for IPv6 Neighbor Discovery
> Multicast and Anycast Addresses
> Publication Date : November 2024
> Author(s) : P. Thubert, Ed.
> Category : PROPOSED STANDARD
> Source : IPv6 over Networks of Resource-constrained Nodes
> Stream : IETF
> Verifying Party : IESG
>
> _______________________________________________
> 6lo mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
6lo mailing list -- [email protected]
To unsubscribe send an email to [email protected]
