[6lo] Re: AD review of draft-ietf-6lo-updating-rfc-8928-03

Mon, 19 May 2025 09:48:21 -0700 

Dear Chairs and WG,

I made some changes as suggested by Eric in the attached file. Please have
a look.

I made changes to Table 1 from ARO to EARO, because ARO was suggested to
remove from the Acronyms (sec.2.3). and it was only used in Table 1 in the
document. Moreover, on the IANA website, it is also ARO (
https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml).
*Should I use ARO or EARO?*


[image: image.png]

>
> Thank you for the prompt reaction. This is good except that I wonder why
> there is now a IEEE 802.15.4 reference as it is never used (I think) in
> this I-D.
>

 I removed the Acronym with its IEEE 802.15.4 reference, which was not used
actually in the text.
I later noticed that the terms used in this document and other ongoing WG
documents need to be corrected accordingly.

   *6LoWPAN:  *IPv6 over Low-power Wireless Personal Area Networks
[RFC4919]
   *LoWPAN*:  Low-power Wireless Personal Area Network [RFC4944]
   *LR-WPAN:*  Low-Rate Wireless Personal Area Network (IEEE Std.  802.15.4)



> Also, may I strongly suggest to reply on the 6LO mailing list as this is
> also a WG document ;-)
>

  Oops, I did not notice that my previous email was sent only to Eric. My
bad.



>
>
> Please upload ASAP so that the IETF Last Call proceeds on the latest
> revision
>

We will do it soon

>
>
>
>
>
>
> *From: *Adnan Rashid <[email protected]>
> *Date: *Monday, 19 May 2025 at 17:24
> *To: *Eric Vyncke (evyncke) <[email protected]>
> *Subject: *Re: AD review of draft-ietf-6lo-updating-rfc-8928-03
>
> Hi Eric,
>
>
>
>
>
> My comments are inline
>
>
>
> Thanks for this impromptu work, but really required. Let’s make it one of
> the fastest to be approved IETF draft !
>
>
>
> This is the usual AD review of the draft. Therefore, I request either a
> revised I-D addressing one point or a reply on the points ;-) Then, I am
> requesting the 2-week IETF Last Call before putting it on one IESG telechat.
>
>
>
> Carles, about the shepherd, you may want to modify the text about the
> downward reference as the prefix-delegation will be published as proposed
> standard, so , it is rather a nits-tool bug than a real downward reference.
>
>
>
> I am repeating my WGLC comment about section 2.3: please prune all unused
> acronyms, e.g., AP-ND (defined in 3 places but never used), DAD, ARO, ...
>
> Done
>
>
>
> Section 3, I am not a big fan of duplicating the definition of F & Prefix
> Length from the prefix-registration, I would prefer a reference to the
> other I-D (like the reference to RFC 8505).
>
> I had a detailed talk with Pascal to make things easy for the readers and
> implementers. This is the first time we are defining EARO for NS and NA and
> I insisted on explaining all fields of EARO at least the EARO flags.
> Honestly, I was not aware of the 2-bit reserved bits in the Status. Thanks
> to Pascal he explained me.
>
>
>
> Section 3, why writing ‘reser*V*ed’ for a r-flag? Also, this field is
> either 1-bit or 2-bit depending on the figure 1 or figure 2. Please update.
>
>
>
> .Done.
>
>
>
>
>
> I attached the file for your review. Please check.
>
>
>
>
> --
>
> Regards,
>
>
>
> Adnan
>


-- 
Regards,

Adnan
Title: Diff: Updating-RFC-8928.txt - draft-ietf-6lo-updating-rfc-8928-03.txt
  Updating-RFC-8928.txt   draft-ietf-6lo-updating-rfc-8928-03.txt
       
Skipping Skipping
  6lo P. Thubert   6lo P. Thubert
  Internet-Draft   Internet-Draft
  Updates: 8928 (if approved) A. Rashid   Updates: 8928 (if approved) A. Rashid
  Intended status: Standards Track Politecnico di Bari   Intended status: Standards Track Politecnico di Bari
  Expires: 20 November 2025 19 May 2025   Expires: 20 November 2025 19 May 2025
   
   
  Fixing the C-Flag in EARO   Fixing the C-Flag in EARO
  draft-ietf-6lo-updating-rfc-8928-04   draft-ietf-6lo-updating-rfc-8928-03
   
  Abstract   Abstract
   
  This document updates RFC 8928, “Address-Protected Neighbor Discovery   This document updates RFC 8928, “Address-Protected Neighbor Discovery
  for Low-Power and Lossy Networks” (AP-ND), by updating the bit   for Low-Power and Lossy Networks” (AP-ND), by updating the bit
  position for the C-flag in the Extended Address Registration Option   position for the C-flag in the Extended Address Registration Option
  (EARO) and registering it with IANA.   (EARO) and registering it with IANA.
   
       
Skipping Skipping
  Table of Contents   Table of Contents
   
  1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
  2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2   2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
  2.1. Requirements Language . . . . . . . . . . . . . . . . . . 2   2.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
  2.2. References . . . . . . . . . . . . . . . . . . . . . . . 2   2.2. References . . . . . . . . . . . . . . . . . . . . . . . 2
  2.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3   2.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
  3. Updating RFC 8928 . . . . . . . . . . . . . . . . . . . . . . 3   3. Updating RFC 8928 . . . . . . . . . . . . . . . . . . . . . . 3
  4. Security Considerations . . . . . . . . . . . . . . . . . . . 5   4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
  5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5   5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
  5.1. Bit Position of the C-flag . . . . . . . . . . . . . . . 5   5.1. Bit Position of the C-flag . . . . . . . . . . . . . . . 6
  6. Normative References . . . . . . . . . . . . . . . . . . . . 5   6. Normative References . . . . . . . . . . . . . . . . . . . . 6
  7. Informative References . . . . . . . . . . . . . . . . . . . 7   7. Informative References . . . . . . . . . . . . . . . . . . . 8
  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
   
  1. Introduction   1. Introduction
   
  The Address-Protected Neighbor Discovery for Low-Power and Lossy   The Address-Protected Neighbor Discovery for Low-Power and Lossy
  Networks (AP-ND) [RFC8928] defined the C-flag in EARO. It is used to   Networks (AP-ND) [RFC8928] defined the C-flag in EARO. It is used to
  indicate that the Registration Ownership Verifier (ROVR) field   indicate that the Registration Ownership Verifier (ROVR) field
  contains a Crypto-ID and that the 6LoWPAN Node (6LN) may be   contains a Crypto-ID and that the 6LoWPAN Node (6LN) may be
  challenged for ownership of the registered address. Initially   challenged for ownership of the registered address. Initially
       
Skipping Skipping
  Discovery (ND) for IPv6 [RFC4861], [RFC4862] and Subnet ND [RFC6775],   Discovery (ND) for IPv6 [RFC4861], [RFC4862] and Subnet ND [RFC6775],
  [RFC8505] [RFC8928], [RFC8929] [RFC9685], and   [RFC8505] [RFC8928], [RFC8929] [RFC9685], and
  [I-D.ietf-6lo-prefix-registration].   [I-D.ietf-6lo-prefix-registration].
  2.3. Acronyms   2.3. Acronyms
   
  This document uses the following abbreviations:   This document uses the following abbreviations:
   
  *6LN:* 6LoWPAN Node   *6LN:* 6LoWPAN Node
    *AP-ND:* Address-Protected Neighbor Discovery
    *ARO:* Address Registration Option
    *DAD:* Duplicate Address Detection
  *EARO:* Extended Address Registration Option   *EARO:* Extended Address Registration Option
    *LLN:* Low-Power and Lossy Network
    *LoWPAN:* Low-Rate Wireless Personal Area Network (IEEE Std.
    802.15.4) [IEEE802154]
  *ND:* Neighbor Discovery   *ND:* Neighbor Discovery
  *RATInd:* Registered Address Type Indicator   *RATInd:* Registered Address Type Indicator
  *ROVR:* Registration Ownership Verifier   *ROVR:* Registration Ownership Verifier
    *TID:* Transaction ID
   
  3. Updating RFC 8928   3. Updating RFC 8928
   
  [RFC8928] incorrectly refers to the Extended Address Registration   [RFC8928] incorrectly refers to the Extended Address Registration
  Option (EARO) as the Enhanced Address Registration Option. This   Option (EARO) as the Enhanced Address Registration Option. This
  specification corrects this terminology throughout the document.   specification corrects this terminology throughout the document.
   
  In [RFC8928], the C-flag is specified in the EARO flags field at bit   In [RFC8928], the C-flag is specified in the EARO flags field at bit
       
Skipping Skipping
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |r|C| P | I |R|T| TID | Registration Lifetime |   |r|C| P | I |R|T| TID | Registration Lifetime |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | |   | |
  ... Registration Ownership Verifier (ROVR) ...   ... Registration Ownership Verifier (ROVR) ...
  | (64, 128, 192, or 256 bits) |   | (64, 128, 192, or 256 bits) |
  | |   | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
  Figure 1: Extended Address Registration Option (EARO) Format for   Figure 1: Extended Address Registration Option (EARO) Format for
  use in NS messages   use in NS messages
   
  Figure 2 below replaces Figure 1 in [RFC8928] in the case of an EARO   Figure 2 below replaces Figure 1 in [RFC8928] in the case of an EARO
  used in an NA message. The difference between the two formats is in   used in an NA message. The difference between the two formats is in
  the usage of bits 16 to 23.   the usage of bits 16 to 23.
   
  0 1 2 3   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   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 |   | Type | Length | r | Status | Opaque |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |r|C| P | I |R|T| TID | Registration Lifetime |   |r|C| P | I |R|T| TID | Registration Lifetime |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | |   | |
       
Skipping Skipping
  use in NA messages   use in NA messages
   
  Option fields of interest for this specification:   Option fields of interest for this specification:
   
  *Type:* 33   *Type:* 33
   
  *Length:* Defined in [RFC8505].   *Length:* Defined in [RFC8505].
   
    *F:* 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
  *F:* Defined in [I-D.ietf-6lo-prefix-registration]   [I-D.ietf-6lo-prefix-registration].
   
  *Prefix Length* Defined in [I-D.ietf-6lo-prefix-registration]   *Prefix Length* 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 value MUST 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 it MUST be set to 0 by the
    sender and ignored by the receiver. For use in NS messages only
    [I-D.ietf-6lo-prefix-registration].
   
  *Status:* 6-bit unsigned integer. This field is used in NA(EARO)   *Status:* 6-bit unsigned integer. This field is used in NA(EARO)
  response messages only to indicate the status of a registration.   response messages only to indicate the status of a registration.
  This field is defined in [RFC8505] and resized by [RFC9010]. The   This field is defined in [RFC8505] and resized by [RFC9010]. The
  values for the Status field are available in [IANA.ICMP.ARO.STAT].   values for the Status field are available in [IANA.ICMP.ARO.STAT].
  This field MUST be set to 0 in NS(EARO) messages unless the   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   registration is for a prefix, in which case the F-flag is set and
  the prefix length is provided.   the prefix length is provided.
   
    *Opaque:* 8-bit field opaque to ND. It MUST be set to 0 when not
  *Opaque:* Defined in [RFC8505]   used. Defined in [RFC8505].
   
  *r (reserved):* 1-bit reserved field in NS(EARO) and NA(EARO) as   *r (reserVed):* 1-bit reserved field. It MUST be set to zero by the
  depicted in Figure 1 and Figure 2. 2-bit reserved field (most  
  significant bits of Status filed) in NA(EARO) as depicted in  
  Figure 2. All reserved field MUST be set to zero by the sender  
  and MUST be ignored by the receiver.   sender and MUST be ignored by the receiver.
   
  *C:* 1-bit flag, moved from its position in Figure 1 of [RFC8928].   *C:* 1-bit flag, moved from its position in Figure 1 of [RFC8928].
  It is set to indicate that the ROVR field contains a Crypto-ID and   It is set to indicate that the ROVR field contains a Crypto-ID and
  that the 6LN MAY be challenged for ownership.   that the 6LN MAY be challenged for ownership.
   
  *P:* 2-bit field for Registered Address Type Indicator (RATInd).   *P:* 2-bit field for Registered Address Type Indicator (RATInd).
  Indicates whether the registered address is unicast, multicast, or   Indicates whether the registered address is unicast, multicast, or
  anycast, or derived from the unicast prefix that is being   anycast, or derived from the unicast prefix that is being
  registered. Used to transport the RATInd in different protocols.   registered. Used to transport the RATInd in different protocols.
  The values for the RATInd field are available in   The values for the RATInd field are available in
  [IANA.ICMP.ARO.P-FIELD].   [IANA.ICMP.ARO.P-FIELD].
   
    *I:* 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
    [RFC8505].
   
    *R:* 1-bit flag. Registering Node sets the R-flag to request
    reachability services for the Registered Address from a Routing
    Registrar. Defined in [RFC8505].
   
    *T:* 1-bit flag. Set if the next octet is used as a TID. Defined
    in [RFC8505].
   
    *TID (Transaction ID):* 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
    [RFC8505].
   
    *Registration Lifetime:* 16-bit integer representing the lifetime in
    minutes of the Registered Address. Zero indicates the
    registration has ended, and the associated state MUST be removed.
  *I:* Defined in [RFC8505]   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].   *Registration Ownership Verifier (ROVR):* Variable length field,
  Variable length field, used to verify who "owns" a registered IPv6   used to verify who "owns" a registered IPv6 address [RFC8505].
  address. When the C-flag is set, this field contains a Crypto-ID   When the C-flag is set, this field contains a Crypto-ID [RFC8928].
  [RFC8928].  
   
  4. Security Considerations   4. Security Considerations
   
  This specification does not introduce any new security considerations   This specification does not introduce any new security considerations
  beyond those already discussed in [RFC8928] and [RFC8505].   beyond those already discussed in [RFC8928] and [RFC8505].
   
  5. IANA Considerations   5. IANA Considerations
   
       
Skipping Skipping
  This specification updates the location of the C-flag introduced in   This specification updates the location of the C-flag introduced in
  [RFC8928] to position it as bit 1 in the EARO flags field. IANA is   [RFC8928] to position it as bit 1 in the EARO flags field. IANA is
  requested to reference this RFC in addition to [RFC8928] when   requested to reference this RFC in addition to [RFC8928] when
  updating the "Address Registration Option Flags" [IANA.ICMP.ARO.FLG]   updating the "Address Registration Option Flags" [IANA.ICMP.ARO.FLG]
  registry under the heading "Internet Control Message Protocol version   registry under the heading "Internet Control Message Protocol version
  6 (ICMPv6) Parameters" as specified in Table 1:   6 (ICMPv6) Parameters" as specified in Table 1:
   
  +---------------+---------+-----------------------+   +---------------+---------+-----------------------+
  | EARO flag | Meaning | Reference |   | ARO flag | Meaning | Reference |
  +---------------+---------+-----------------------+   +---------------+---------+-----------------------+
  | 1 (suggested) | C-Flag | RFC This and RFC 8928 |   | 1 (suggested) | C-Flag | RFC This and RFC 8928 |
  +---------------+---------+-----------------------+   +---------------+---------+-----------------------+
   
  Table 1: Bit Position of the C-flag   Table 1: Bit Position of the C-flag
   
  6. Normative References   6. Normative References
   
  [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
  Requirement Levels", BCP 14, RFC 2119,   Requirement Levels", BCP 14, RFC 2119,
  DOI 10.17487/RFC2119, March 1997,   DOI 10.17487/RFC2119, March 1997,
  <https://www.rfc-editor.org/info/rfc2119>.   <https://www.rfc-editor.org/info/rfc2119>.
   
  [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,   [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
  "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,   "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
  DOI 10.17487/RFC4861, September 2007,   DOI 10.17487/RFC4861, September 2007,
  <https://www.rfc-editor.org/info/rfc4861>.   <https://www.rfc-editor.org/info/rfc4861>.
   
  [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless   [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
  Address Autoconfiguration", RFC 4862,   Address Autoconfiguration", RFC 4862,
  DOI 10.17487/RFC4862, September 2007,   DOI 10.17487/RFC4862, September 2007,
  <https://www.rfc-editor.org/info/rfc4862>.   <https://www.rfc-editor.org/info/rfc4862>.
   
  [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.   [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
  Bormann, "Neighbor Discovery Optimization for IPv6 over   Bormann, "Neighbor Discovery Optimization for IPv6 over
  Low-Power Wireless Personal Area Networks (6LoWPANs)",   Low-Power Wireless Personal Area Networks (6LoWPANs)",
  RFC 6775, DOI 10.17487/RFC6775, November 2012,   RFC 6775, DOI 10.17487/RFC6775, November 2012,
  <https://www.rfc-editor.org/info/rfc6775>.   <https://www.rfc-editor.org/info/rfc6775>.
   
  [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC   [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
  2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,   2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
       
Skipping Skipping
  (Routing Protocol for Low-Power and Lossy Networks)   (Routing Protocol for Low-Power and Lossy Networks)
  Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021,   Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021,
  <https://www.rfc-editor.org/info/rfc9010>.   <https://www.rfc-editor.org/info/rfc9010>.
   
  [RFC9685] Thubert, P., Ed., "Listener Subscription for IPv6 Neighbor   [RFC9685] Thubert, P., Ed., "Listener Subscription for IPv6 Neighbor
  Discovery Multicast and Anycast Addresses", RFC 9685,   Discovery Multicast and Anycast Addresses", RFC 9685,
  DOI 10.17487/RFC9685, November 2024,   DOI 10.17487/RFC9685, November 2024,
  <https://www.rfc-editor.org/info/rfc9685>.   <https://www.rfc-editor.org/info/rfc9685>.
   
  [I-D.ietf-6lo-prefix-registration]   [I-D.ietf-6lo-prefix-registration]
  Thubert, P., "IPv6 Neighbor Discovery Prefix   Thubert, P., "IPv6 Neighbor Discovery Prefix
  Registration", Work in Progress, Internet-Draft, draft-   Registration", Work in Progress, Internet-Draft, draft-
  ietf-6lo-prefix-registration-10, 17 April 2025,   ietf-6lo-prefix-registration-10, 17 April 2025,
  <https://datatracker.ietf.org/doc/html/draft-ietf-6lo-   <https://datatracker.ietf.org/doc/html/draft-ietf-6lo-
  prefix-registration-10>.   prefix-registration-10>.
   
  [IANA.ICMP.ARO.FLG]   [IANA.ICMP.ARO.FLG]
  IANA, "IANA Registry for the Address Registration Option   IANA, "IANA Registry for the Address Registration Option
  Flags", IANA, https://www.iana.org/assignments/icmpv6-   Flags", IANA, https://www.iana.org/assignments/icmpv6-
  parameters/icmpv6-parameters.xhtml#icmpv6-adress-   parameters/icmpv6-parameters.xhtml#icmpv6-adress-
  registration-option-flags.   registration-option-flags.
   
  [IANA.ICMP.ARO.STAT]   [IANA.ICMP.ARO.STAT]
  IANA, "IANA Registry for the Address Registration Option   IANA, "IANA Registry for the Address Registration Option
  Status Value", IANA, https://www.iana.org/assignments/   Status Value", IANA, https://www.iana.org/assignments/
  icmpv6-parameters/icmpv6-parameters.xhtml#address-   icmpv6-parameters/icmpv6-parameters.xhtml#address-
  registration.   registration.
   
  [IANA.ICMP.ARO.P-FIELD]   [IANA.ICMP.ARO.P-FIELD]
  IANA, "IANA Registry for the Address Registration Option   IANA, "IANA Registry for the Address Registration Option
  Status Value", IANA, https://www.iana.org/assignments/   Status Value", IANA, https://www.iana.org/assignments/
  icmpv6-parameters/icmpv6-parameters.xhtml#p-field-values.   icmpv6-parameters/icmpv6-parameters.xhtml#p-field-values.
   
  7. Informative References   7. Informative References
   
    [IEEE802154]
    IEEE standard for Information Technology, "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".
   
  [RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli,   [RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli,
  "IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929,   "IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929,
  November 2020, <https://www.rfc-editor.org/info/rfc8929>.   November 2020, <https://www.rfc-editor.org/info/rfc8929>.
   
  Authors' Addresses   Authors' Addresses
   
  Pascal Thubert   Pascal Thubert 
_______________________________________________
6lo mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to