Fixing the C-Flag in the Extended Address Registration Option (EARO)

Introduction The Address-Protected Neighbor Discovery for Low-Power and Lossy Networks (AP-ND) defined the C-flag in EARO. It is used to indicate that the Registration Ownership Verifier (ROVR) field contains a Crypto-ID and that the 6LoWPAN Node (6LN) may be challenged for ownership of the registered address. Initially, defined the C-flag in the EARO in bit position 3; later, defined the P-Field in bits 2 and 3 of the EARO flags field with proper IANA registration, causing an overlap with Figure 1 of , which depicts the location of the C-flag. This specification updates by repositioning the C-flag as bit 1 of the EARO flags field, thereby preventing conflicts.

Terminology

Requirements Language 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.

Related Documents This document uses terms and concepts that are discussed in IPv6 Neighbor Discovery (ND) , , as well as 6LoWPAN-ND , , , , , and .

Acronyms This document uses the following abbreviations:

6LN:: 6LoWPAN Node
EARO:: Extended Address Registration Option
ND:: Neighbor Discovery
RATInd:: Registered Address Type Indicator
ROVR:: Registration Ownership Verifier

Updating RFC 8928 incorrectly refers to the Extended Address Registration Option (EARO) as the Enhanced Address Registration Option. This specification corrects this terminology throughout the document. In , the C-flag is specified in the EARO flags field at bit position 3 (as depicted in Figure 1 of ); however, fails to register its position with IANA. Later, defined the P-Field in bits 2 and 3 of the EARO flags field and obtained proper IANA registration, but this introduced an overlap with the representation in . To resolve the conflict, this specification updates by repositioning the C-flag to bit 1 of the EARO flags field, ensuring there are no overlapping definitions. replaces Figure 1 in in the case of an EARO used in an NS message.

Extended Address Registration Option (EARO) Format for Use in NS Messages replaces Figure 1 in in the case of an EARO used in an NA message. The difference between the two formats is in the usage of bits 16 to 23.

Extended Address Registration Option (EARO) Format for Use in NA Messages Option fields of interest for this specification:

Type:: 33
Length:: Defined in
F:: Defined in
Prefix Length: Defined in
Status:: 6-bit unsigned integer. This field is used in NA(EARO) response messages only to indicate the status of a registration. This field is defined in and resized by . The values for the Status field are available in . This field MUST be set to 0 in NS(EARO) messages unless the registration is for a prefix, in which case the F-flag is set and the prefix length is provided.
Opaque:: Defined in
r (reserved):: 1-bit reserved field in NS(EARO) and NA(EARO) as depicted in and . 2-bit reserved field (most significant bits of Status filed) in NA(EARO) as depicted in . All reserved field MUST be set to zero by the sender and MUST be ignored by the receiver.
C:: 1-bit flag, moved from its position in Figure 1 of . It is set to indicate that the ROVR field contains a Crypto-ID and that the 6LN MAY be challenged for ownership.
P:: 2-bit field for Registered Address Type Indicator (RATInd). Indicates whether the registered address is unicast, multicast, anycast, or derived from the registered unicast prefix. Used to transport the RATInd in different protocols. The values for the RATInd field are available in .
I:: Defined in
R:: Defined in
T:: Defined in
TID (Transaction ID):: Defined in
Registration Lifetime:: Defined in
Registration Ownership Verifier (ROVR):: Defined in . Variable-length field used to verify who "owns" a registered IPv6 address. When the C-flag is set, this field contains a Crypto-ID .

Security Considerations This specification does not introduce any new security considerations beyond those already discussed in and .

Operational Considerations The updates introduced in this document are not backward compatible. However, given that there are no known implementations or deployments of , this document does not require any transition plan.

IANA Considerations

Bit Position of the C-flag IANA has updated the "Address Registration Option Flags" registry in the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry group as specified in so this document is referenced in addition to for bit number 1: Bit Position of the C-flag

Bit Number	Description	Reference
1	C-Flag	RFC 9927 and