RFC 9927

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

📅 published February 2026, from ietf

RFC 9927: Fixing the C-Flag in the Extended Address Registration Option (EARO) 💖

Okay bestie, here's the title block tea ☕✨

  • Number: RFC 9927 🎀
  • Stream: Internet Engineering Task Force (IETF) 🌸
  • Authors: P. Thubert and A. Rashid (A. Rashid is at Politecnico di Bari 🎓)
  • Category: Standards Track 🔥
  • Date: February 2026 🗓️
  • ISSN: 2070-1721
  • Updates: [RFC8928] 🦋

Abstract

okay so this doc updates "Address-Protected Neighbor Discovery for Low-Power and Lossy Networks" (RFC 8928) by moving the C-flag in the Extended Address Registration Option (EARO) and getting it registered with IANA 🧚

Status of This Memo

this is an Internet Standards Track document 🫶

it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. it went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 👑. if you want more info on Internet Standards, check out Section 2 of RFC 7841.

for the current status, any errata, or how to send feedback, go to https://www.rfc-editor.org/info/rfc9927 💅

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. read them carefully, bestie, because they explain your rights and restrictions for this doc 📜. any Code Components pulled out of this document must include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Revised BSD License describes 🔒

Table of Contents

1.  Introduction
2.  Terminology
  2.1.  Requirements Language
  2.2.  Related Documents
  2.3.  Acronyms
3.  Updating RFC 8928
4.  Security Considerations
5.  Operational Considerations
6.  IANA Considerations
  6.1.  Bit Position of the C-flag
7.  References
  7.1.  Normative References
  7.2.  Informative References
Authors' Addresses

1. Introduction ✨

so the Address-Protected Neighbor Discovery for Low-Power and Lossy Networks (AP-ND) [RFC8928] is where the C-flag in EARO was first defined 🌸. its job is to say that the Registration Ownership Verifier (ROVR) field holds a Crypto-ID, and that the 6LoWPAN Node (6LN) might get challenged for ownership of the registered address 🔐.

here's the drama 😭: [RFC8928] first put the C-flag in bit position 3 of the EARO. then [RFC9685] came along and defined the P-Field in bits 2 and 3 of the EARO flags field, and got it properly registered with IANA. that created an overlap with Figure 1 of [RFC8928], which shows where the C-flag lives. not it 💀

this spec fixes that by updating [RFC8928] and moving the C-flag to bit 1 of the EARO flags field 🦋. conflict solved, periodt 💅

2. Terminology ✨

2.1. Requirements Language

okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document work the way BCP 14 [RFC2119] [RFC8174] describes. but only when they show up in ALL CAPS, like they do right here 🙈 lowercase ones are just normal words, bestie.

this doc uses terms and ideas from IPv6 Neighbor Discovery (ND) [RFC4861], [RFC4862], plus the 6LoWPAN-ND crew: [RFC6775], [RFC8505], [RFC8928], [RFC8929], [RFC9685], and [RFC9926] 🧠🎀

2.3. Acronyms

this doc uses these abbreviations, so keep them in your back pocket 🍓

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

3. Updating RFC 8928 ✨

ok this is the big correction 💅. [RFC8928] keeps calling the Extended Address Registration Option (EARO) the Enhanced Address Registration Option, which is wrong 😭. this spec fixes that terminology everywhere in the doc.

in [RFC8928], the C-flag sits in the EARO flags field at bit position 3 (see Figure 1 of [RFC8928]). but [RFC8928] never registered that position with IANA 🥲. later, [RFC9685] defined the P-Field in bits 2 and 3 of the EARO flags field and got it registered, which overlapped with what [RFC8928] showed. to clear that up, this spec updates [RFC8928] and repositions the C-flag to bit 1 of the EARO flags field, so there are zero overlapping definitions 🫶

Figure 1 swaps in for Figure 1 of [RFC8928] when an EARO shows up in an NS message 👀

      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|Prefix Length|    Opaque     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |r|C| P | I |R|T|     TID       |     Registration Lifetime     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
    ...            Registration Ownership Verifier (ROVR)           ...
     |                  (64, 128, 192, or 256 bits)                  |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 1: Extended Address Registration Option (EARO) Format for
                             Use in NS Messages

Figure 2 swaps in for Figure 1 of [RFC8928] when an EARO shows up in an NA message. the only difference between the two is how bits 16 to 23 get used 🧩

      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    | r |  Status   |    Opaque     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |r|C| P | I |R|T|     TID       |     Registration Lifetime     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
    ...            Registration Ownership Verifier (ROVR)           ...
     |                  (64, 128, 192, or 256 bits)                  |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 2: Extended Address Registration Option (EARO) Format for
                             Use in NA Messages

here's the field rundown for this spec 🎀

  • Type: 33
  • Length: Defined in [RFC8505]
  • F: Defined in [RFC9926]
  • Prefix Length: Defined in [RFC9926]
  • Status: 6-bit unsigned integer. this field only gets used in NA(EARO) response messages, to show the status of a registration. it's defined in [RFC8505] and resized by [RFC9010] 📏. the values for Status are in [IANA.ICMP.ARO.STAT]. 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 [RFC8505]
  • r (reserved): 1-bit reserved field in NS(EARO) and NA(EARO), as shown in Figure 1 and Figure 2. in NA(EARO) there's also a 2-bit reserved field (the most significant bits of Status), as shown in Figure 2. all reserved fields MUST be set to zero by the sender and MUST be ignored by the receiver 🫧
  • C: 1-bit flag, moved from where it sat in Figure 1 of [RFC8928]. it gets set to show that the ROVR field contains a Crypto-ID and that the 6LN MAY be challenged for ownership 🔑
  • P: 2-bit field for the Registered Address Type Indicator (RATInd). it shows whether the registered address is unicast, multicast, anycast, or derived from the registered unicast prefix. it's how the RATInd gets carried across different protocols. the values for RATInd are in [IANA.ICMP.ARO.P-FIELD] 🌈
  • I: Defined in [RFC8505]
  • R: Defined in [RFC8505]
  • T: Defined in [RFC8505]
  • TID (Transaction ID): Defined in [RFC8505]
  • Registration Lifetime: Defined in [RFC8505]
  • Registration Ownership Verifier (ROVR): Defined in [RFC8505]. it's a variable-length field used to check who "owns" a registered IPv6 address. when the C-flag is set, this field holds a Crypto-ID [RFC8928] 🔐

4. Security Considerations ✨

🚨 this is serious, bestie. this spec doesn't introduce any new security considerations beyond the ones already covered in [RFC8928] and [RFC8505]. go read those, especially if you're working with ROVR and Crypto-IDs 🛡️

5. Operational Considerations ✨

heads up on this one 👀. the updates in this doc are not backward compatible. BUT (and this is the best part 🙌) since there are no known implementations or deployments of [RFC8928], this doc doesn't require any transition plan. zero migration drama, no cap 💖

6. IANA Considerations ✨

6.1. Bit Position of the C-flag

IANA updated the "Address Registration Option Flags" [IANA.ICMP.ARO.FLG] registry in the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry group, as Table 1 shows. so this doc now gets referenced alongside [RFC8928] for bit number 1 🦋

        +============+=============+========================+
        | Bit Number | Description | Reference              |
        +============+=============+========================+
        | 1          | C-Flag      | RFC 9927 and [RFC8928] |
        +------------+-------------+------------------------+

                 Table 1: Bit Position of the C-flag

7. References ✨

the reference lists didn't make it into the text I was given, so they'll show up in part 2 along with Authors' Addresses 🧚

7.1. Normative References 📚

okay bestie, this is the must-read list 🫶 these are the docs the spec leans on the hardest, so you need them to fully get what's going on 💅

   [IANA.ICMP.ARO.FLG]
              IANA, "Address Registration Option Flags",
              <https://www.iana.org/assignments/icmpv6-parameters>.

   [IANA.ICMP.ARO.P-FIELD]
              IANA, "P-Field Values",
              <https://www.iana.org/assignments/icmpv6-parameters>.

   [IANA.ICMP.ARO.STAT]
              IANA, "Address Registration Option Status Values",
              <https://www.iana.org/assignments/icmpv6-parameters>.

   [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/info/rfc2119>.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              <https://www.rfc-editor.org/info/rfc4861>.

   [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/info/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/info/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/info/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/info/rfc8505>.

   [RFC8928]  Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik,
              "Address-Protected Neighbor Discovery for Low-Power and
              Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November
              2020, <https://www.rfc-editor.org/info/rfc8928>.

   [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/info/rfc9010>.

   [RFC9685]  Thubert, P., Ed., "Listener Subscription for IPv6 Neighbor
              Discovery Multicast and Anycast Addresses", RFC 9685,
              DOI 10.17487/RFC9685, November 2024,
              <https://www.rfc-editor.org/info/rfc9685>.

   [RFC9926]  Thubert, P., Ed., "Prefix Registration for IPv6 Neighbor
              Discovery", RFC 9926, DOI 10.17487/RFC9926, February 2026,
              <https://www.rfc-editor.org/info/rfc9926>.

7.2. Informative References 🌸

and this one's the extra-credit reading 🧚 it's helpful background but the spec doesn't depend on it to work ✨

   [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/info/rfc8929>.

Authors' Addresses 🦋

and finally, the people who wrote this whole thing, with their contact info so you can say hi 💜

   Pascal Thubert
   06330 Roquefort-les-Pins
   France
   Email: pascal.thubert@gmail.com


   Adnan Rashid
   Politecnico di Bari
   Via Edoardo Orabona 4
   70126 Bari
   Italy
   Email: adnan.rashid@poliba.it
📦 where this page comes from