<?xml version="1.0"encoding="utf-8"?> <!--DOCTYPEencoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629-xhtml.ent"--> <?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="3"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?> <?rfc authorship="yes"?> <?rfc tocappendix="yes"?>[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902" tocInclude="true" indexInclude="true" obsoletes="" consensus="true" submissionType="IETF" xml:lang="en" version="3" updates="8928" docName="draft-ietf-6lo-updating-rfc-8928-05">number="9927" symRefs="true" sortRefs="true"> <front> <title abbrev="RFC 8928-Fix">Fixing the C-Flag inExtended Address Registration Option (EARO)</title> <!-- <title abbrev="EARO Flags Field Fix">Fixingthe Extended Address Registration Option(EARO) Flags Field</title> -->(EARO)</title> <seriesInfo name="RFC" value="9927"/> <author initials='P' surname='Thubert' fullname='Pascal Thubert' ><!-- <organization abbrev='Cisco Systems'>Cisco Systems, Inc</organization> --><address> <postal> <city>Roquefort-les-Pins</city> <code>06330</code> <country>France</country> </postal> <email>pascal.thubert@gmail.com</email> </address> </author> <author initials='A' surname='Rashid' fullname='Adnan Rashid' > <organization abbrev='Politecnico di Bari'>Politecnico di Bari</organization> <address> <postal> <street>Via Edoardo Orabona 4</street> <city>Bari</city> <code>70126</code> <country>Italy</country> </postal> <email>adnan.rashid@poliba.it</email> </address> </author><area>Internet</area><date year="2026" month="January"/> <area>INT</area> <workgroup>6lo</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <!-- [rfced] Some author comments are present in the XML. Please confirm that no updates related to these comments are outstanding. Note that the comments will be deleted prior to publication. --> <abstract> <!-- <t>This document updates RFC 8928 by changing the position for the C-flag in the Extended Address Registration Option (EARO) and registering it with IANA. It also requests IANA to add a 2-bit integer for the I-Field in the "Address Registration Option Flags" registry under ICMPv6 Parameters, as defined in RFC 8505. --><t> This<t>This document updates“Address-Protected"Address-Protected Neighbor Discovery for Low-Power and LossyNetworks”Networks" (RFC 8928) by changing the position of the C-flag in the Extended Address Registration Option (EARO) and registering it withIANA.IANA.</t> <!-- The document also registers the I-Field, initially defined in“Registration"Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) NeighborDiscovery”Discovery" (RFC 8505), in the "Address Registration Option Flags" registry under the“ICMPv6 Parameters”"ICMPv6 Parameters" registry group. --></t></abstract> </front> <middle><!-- **************************************************************** --> <!-- **************************************************************** --> <!-- **************************************************************** --> <!-- **************************************************************** --><section anchor="introduction"> <name>Introduction</name> <t>The <xref target="RFC8928"> Address-Protected Neighbor Discovery for Low-Power and Lossy Networks (AP-ND)</xref> 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.InitiallyInitially, <xref target="RFC8928"/> defined the C-flag in the EARO in bit position 3;laterlater, <xref target="RFC9685"/> 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 <xreftarget="RFC8928"/>target="RFC8928"/>, which depicts the location of the C-flag.</t> <t>This specification updates <xref target="RFC8928"/> by repositioning the C-flag as bit 1 of the EARO flags field, thereby preventing conflicts.</t> </section><!-- end section = "Introduction" --><section> <name>Terminology</name> <section anchor="bcp"><name>Requirements Language</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </section> <sectionanchor="lo"><name>References</name>anchor="lo"><name>Terminology</name> <t> This document uses terms and concepts that are discussed inIPv6-NeighborIPv6 Neighbor Discovery (ND) <xref target="RFC4861"/>, <xref target="RFC4862"/>, as well as 6LoWPAN-ND <xref target="RFC6775"/>, <xref target="RFC8505"/>, <xref target="RFC8928"/>, <xref target="RFC8929"/>, <xref target="RFC9685"/>, and <xreftarget="I-D.ietf-6lo-prefix-registration"/>.target="RFC9926"/>. </t> </section> <section anchor='acronyms' > <name>Acronyms</name> <t>This document uses the following abbreviations:</t> <dlspacing='compact'>spacing='normal' newline="false"> <dt><strong>6LN:</strong></dt><dd>6LoWPAN Node</dd> <!-- <dt><strong>AP-ND:</strong></dt><dd>Address-Protected Neighbor Discovery</dd> --> <!-- <dt><strong>ARO:</strong></dt><dd>Address Registration Option</dd> --> <!-- <dt><strong>DAD:</strong></dt><dd>Duplicate Address Detection</dd> --> <dt><strong>EARO:</strong></dt><dd>Extended Address Registration Option</dd> <!-- <dt><strong>LLN:</strong></dt><dd>Low-Power and Lossy Network</dd> --> <!-- <dt><strong>6LoWPAN:</strong></dt><dd>IPv6 over Low-power Wireless Personal Area Networks</dd> --> <!-- <dt><strong>LoWPAN:</strong></dt><dd>Low-Rate Wireless Personal Area Network</dd> --> <!-- <dt><strong>LR-WPAN:</strong></dt><dd>Low-Rate Wireless Personal Area Network (IEEE Std. 802.15.4) <xref target="IEEE802154"/></dd> --> <dt><strong>ND:</strong></dt><dd>Neighbor Discovery</dd> <dt><strong>RATInd:</strong></dt><dd>Registered Address Type Indicator</dd> <dt><strong>ROVR:</strong></dt><dd>Registration Ownership Verifier</dd> <!-- <dt><strong>TID:</strong></dt><dd>Transaction ID</dd> --> </dl> </section> </section> <section anchor="updating"><name>Updating RFC 8928</name> <t> <xref target="RFC8928"/> incorrectly refers to the Extended Address Registration Option (EARO) as the Enhanced Address Registration Option. This specification corrects this terminology throughout the document. </t> <t> In <xref target="RFC8928"/>, the C-flag is specified in the EARO flags field at bit position 3 (as depicted in Figure 1 of <xref target="RFC8928"/>); however, <xref target="RFC8928"/> fails to register its position with IANA. Later, <xref target="RFC9685"/> 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 <xref target="RFC8928"/>. To resolve the conflict, this specification updates <xref target="RFC8928"/> by repositioning the C-flag to bit 1 of the EARO flags field, ensuring there are no overlapping definitions. </t> <t> <xref target="EARO"/> replaces Figure 1 in <xref target="RFC8928"/> in the case of an EARO used in an NS message. </t> <figure anchor="EARO"> <name>Extended Address Registration Option (EARO) Format foruseUse in NSmessages</name>Messages</name> <artworkalign="center">align="center"><![CDATA[ 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) | | |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork> </figure><!-- end figure "EARO Option Format"+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> </figure> <!-- [rfced] Regarding usage of <strong> elements in this document. please review the occurrences and let us know if any updates needed for consistency. In the HTML and PDF outputs, <strong> yields bold. In the text output, <strong> yields an asterisk before and after. We suggest removing usage in this document because the asterisks seem to clutter the text output in Sections 2.3 and 3. --> <t> <xref target="EARO2"/> replaces Figure 1 in <xref target="RFC8928"/> 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. </t> <figure anchor="EARO2"> <name>Extended Address Registration Option (EARO) Format foruseUse in NAmessages</name>Messages</name> <artworkalign="center">align="center"><![CDATA[ 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) | | |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork> </figure><!-- end figure "EARO Option Format" -->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> </figure> <t>Option fields of interest for this specification:</t><dl><dl spacing="normal" newline="false"> <dt><strong>Type:</strong></dt> <dd>33</dd> <dt><strong>Length:</strong></dt> <dd>Defined in <xreftarget="RFC8505"/>.</dd>target="RFC8505"/></dd> <dt><strong>F:</strong></dt> <dd>Defined in <xref target="I-D.ietf-6lo-prefix-registration"/></dd>"RFC9926"/></dd> <!-- <dd> 1-bit flag; set to 1 to indicate that the sender expects other routers to forward packets to self when the packets are sourced within the registered prefix. For use in NS messages only <xref target= "I-D.ietf-6lo-prefix-registration"/>.</dd> --> <dt><strong>Prefix Length</strong></dt> <dd>Defined in <xref target="I-D.ietf-6lo-prefix-registration"/></dd>"RFC9926"/></dd> <!-- <dd> 7-bit integer. This field contains a prefix length expressed in bits if the P-Field is set to 3 and the EARO is placed in an NS message. In that case, the valueMUST<bcp14>MUST</bcp14> be at least 16 and at most 120. The field contains a Status if the EARO is placed in an NA message regardless of the setting of the P-flag. In all other cases, it is reserved, so itMUST<bcp14>MUST</bcp14> be set to 0 by the sender and ignored by the receiver. For use in NS messages only <xref target= "I-D.ietf-6lo-prefix-registration"/>.</dd> --> <dt><strong>Status:</strong></dt> <dd> 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 <xref target="RFC8505"/> and resized by <xref target="RFC9010"/>. The values for the Status field are available in <xref target="IANA.ICMP.ARO.STAT"/>. This fieldMUST<bcp14>MUST</bcp14> 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. </dd> <dt><strong>Opaque:</strong></dt> <dd>Defined in <xref target="RFC8505"/></dd> <!-- <dd> 8-bit field opaque to ND. ItMUST<bcp14>MUST</bcp14> be set to 0 when not used. Defined in <xref target="RFC8505"/>.</dd> --> <dt><strong>r (reserved):</strong></dt> <dd>1-bit reserved field in NS(EARO) and NA(EARO) as depicted in <xref target="EARO"/> and <xref target="EARO2"/>. 2-bit reserved field (most significant bits of Status filed) in NA(EARO) as depicted in <xref target="EARO2"/>. All reserved fieldMUST<bcp14>MUST</bcp14> be set to zero by the sender andMUST<bcp14>MUST</bcp14> be ignored by the receiver.</dd> <dt><strong>C:</strong></dt> <dd>1-bit flag, moved from its position in Figure 1 of <xref target="RFC8928"/>. It is set to indicate that the ROVR field contains a Crypto-ID and that the 6LNMAY<bcp14>MAY</bcp14> be challenged for ownership.</dd> <dt><strong>P:</strong></dt> <dd>2-bit field for Registered Address Type Indicator (RATInd). Indicates whether the registered address is unicast, multicast,oranycast, or derived from the registered unicast prefix. Used to transport the RATInd in different protocols. The values for the RATInd field are available in <xref target="IANA.ICMP.ARO.P-FIELD"/>.</dd> <dt><strong>I:</strong></dt> <dd>Defined in <xref target="RFC8505"/></dd> <!-- <dd>2-bit integer field that helps to decide how to use the 8-bit Opaque field. When 0, it means the Opaque field has info about the default routing path. Other values are reserved. Defined in <xref target="RFC8505"/>.</dd> --> <dt><strong>R:</strong></dt> <dd>Defined in <xref target="RFC8505"/></dd> <!-- <dd>1-bit flag. Registering Node sets the R-flag to request reachability services for the Registered Address from a Routing Registrar. Defined in <xref target="RFC8505"/>.</dd> --> <dt><strong>T:</strong></dt> <dd>Defined in <xref target="RFC8505"/></dd> <!-- <dd>1-bit flag. Set if the next octet is used as a TID. Defined in <xref target="RFC8505"/>.</dd> --> <dt><strong>TID (Transaction ID):</strong></dt> <dd>Defined in <xref target="RFC8505"/></dd> <!-- <dd>8-bit unsigned integer that tracks transactions for registrations. It is incremented with each new transaction and ignored unless the T-flag is set. Defined in <xref target="RFC8505"/>.</dd> --> <dt><strong>Registration Lifetime:</strong></dt> <dd>Defined in <xref target="RFC8505"/></dd> <!-- <dd>16-bit integer representing the lifetime in minutes of the Registered Address. Zero indicates the registration has ended, and the associated stateMUST<bcp14>MUST</bcp14> be removed. Defined in <xref target="RFC8505"/>.</dd> --> <dt><strong>Registration Ownership Verifier (ROVR):</strong></dt> <dd>Defined in <xref target="RFC8505"/>.Variable length field,Variable-length field used to verify who "owns" a registered IPv6 address. When the C-flag is set, this field contains a Crypto-ID <xref target="RFC8928"/>.</dd> </dl> </section><!-- end section "Updating RFC 8928" --><section><name>Security Considerations</name> <t>This specification does not introduce any new security considerations beyond those already discussed in <xref target="RFC8928"/> and <xref target="RFC8505"/>.</t> </section><!-- end section "Security Considerations" --><section><name>Operational Considerations</name> <t> The updates introduced in this document are not backward compatible. However, given that there are no known implementations or deployments of <xref target="RFC8928"/>, this documentdodoes not require any transition plan. </t> </section> <section ><name>IANA Considerations</name> <!-- <t> IANA is requested to update the "Address Registration Option Flags" <xref target="IANA.ICMP.ARO.FLG"/> registry under the heading "Internet Control Message Protocol version 6 (ICMPv6) Parameters".</t> --> <section><name>Bit Position of the C-flag</name> <t> <!-- This specification updates the location of the C-flag introduced in <xref target= "RFC8928"/> to position it as bit 1 in the EARO flags field. --> IANAis requested to reference this RFC in addition to <xref target="RFC8928"/> when updatinghas updated the "Address Registration Option Flags" <xref target="IANA.ICMP.ARO.FLG"/> registryunderin theheading"Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry group as specified in <xreftarget="AROflags"/>:target="AROflags"/> so this document is referenced in addition to <xref target="RFC8928"/> for bit number 1: </t> <table anchor="AROflags" ><name>Bit Position of the C-flag</name> <thead><tr><td>EARO flag</td><td>Description</td><td>Reference</td></tr><tr><th>Bit Number</th><th>Description</th><th>Reference</th></tr> </thead><tbody><tr><td>1 (suggested)</td><td><tr><td>1</td><td> C-Flag </td><td>RFCXXXX9927 and <xref target="RFC8928"/></td></tr> </tbody> </table><!-- end table "New ARO flag1" +--></section> <!--end section "Bit Position of the C-flag" --> <!--<section><name>Adding the I-Field</name> <t> IANA is requested to add 2-bit integer for the I-Field in the "Address Registration Option Flags" <xref target="IANA.ICMP.ARO.FLG"/> registry under the heading "Internet Control Message Protocol version 6 (ICMPv6) Parameters" as specified in <xref target="RFC8505"/>. </t> <table anchor="AROflags2" ><name>I-Field in ARO flags field</name> <thead> <tr><td>Bit Number</td><td>Description</td><td>Reference</td></tr> </thead><tbody> <tr><td>4-5</td><td> I-Field </td><td><xref target="RFC8505"/> </td></tr> </tbody> </table> <t>The values taken by the I-Field are defined in <xref target="IANA.ICMP.ARO.FLG"/>.</t> </section> --> </section><!-- end section "IANA Considerations" --> <!-- <section title="Acknowledgments"> <t> Many thanks to Dave Thaler and Dan Romascanu for their early INT-DIR review. </t> </section> title="Acknowledgments" --></middle> <back><references title="Normative References"> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/><references> <name>References</name> <references> <name>Normative References</name> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8505.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8928.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8505.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9010.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8928.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9685.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9010.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6lo-prefix-registration.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9685.xml"/> <!-- draft-ietf-6lo-prefix-registration-16 is companion doc RFC 9926 --> <referenceanchor="IANA.ICMP.ARO.FLG">anchor="RFC9926" target="https://www.rfc-editor.org/info/rfc9926"> <front><title>IANA Registry for the Address<title>IPv6 Neighbor Discovery Prefix Registration</title> <author initials="P." surname="Thubert" fullname="Pascal Thubert" role="editor"> </author> <date month="January" year="2026"/> </front> <seriesInfo name="RFC" value="9926"/> <seriesInfo name="DOI" value="10.17487/RFC9926"/> </reference> <reference anchor="IANA.ICMP.ARO.FLG" target="https://www.iana.org/assignments/icmpv6-parameters"> <front> <title>Address Registration Option Flags</title> <author> <organization> IANA </organization> </author><date year=""></date></front><seriesInfo name="IANA," value="https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-adress-registration-option-flags"></seriesInfo></reference> <referenceanchor="IANA.ICMP.ARO.STAT">anchor="IANA.ICMP.ARO.STAT" target="https://www.iana.org/assignments/icmpv6-parameters"> <front><title>IANA Registry for the Address<title>Address Registration Option StatusValue</title>Values</title> <author> <organization> IANA </organization> </author><date year=""></date></front><seriesInfo name="IANA," value= "https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#address-registration"></seriesInfo></reference><reference anchor="IANA.ICMP.ARO.P-FIELD"> <front> <title>IANA<!-- [rfced] FYI, regarding [IANA.ICMP.ARO.P-FIELD], we updated the reference's title to "P-Field Values" to match what seems to have been intended. Please let us know if this is not accurate. Original: [IANA.ICMP.ARO.P-FIELD] IANA, "IANA Registry for the Address Registration Option StatusValue</title>Value", IANA, https://www.iana.org/assignments/ icmpv6-parameters/icmpv6-parameters.xhtml#p-field-values. Current: [IANA.ICMP.ARO.P-FIELD] IANA, "P-Field Values", <https://www.iana.org/assignments/icmpv6-parameters>. --> <reference anchor="IANA.ICMP.ARO.P-FIELD" target="https://www.iana.org/assignments/icmpv6-parameters"> <front> <title>P-Field Values</title> <author> <organization> IANA </organization> </author><date year=""></date></front><seriesInfo name="IANA," value= "https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#p-field-values"></seriesInfo></reference> </references><references title="Informative References"><references> <name>Informative References</name> <!-- <reference anchor="IEEE802154"> <front> <title>IEEE Std 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks </title> <author> <organization>IEEE standard for Information Technology</organization> </author> <date/> </front> </reference> --> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8929.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8929.xml"/> <!-- <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.I-D.ietf-6lo-prefix-registration-10.xml"/> --> <!-- <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6man-ipv6-over-wireless.xml'/> --> </references> </references> <!-- <section numbered="false"><name>Acknowledgments</name> <t> Many thanks to Dave Thaler and Dan Romascanu for their early INT-DIR review. </t> --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </back> </rfc>