[6lo] Re: Call for adoption of draft-ietf-6lo-updating-rfc-8928

Thu, 17 Apr 2025 08:50:56 -0700 

Hi Eric,

All done except few. My comments are inline


>    - Section 2: (perhaps extreme also) can be completely removed, i.e.,
>    there is no need to explain what EARO is
>
> *Adnan: * My suggestion is not to remove the all EARO flags field. Rest I
agree.

>
>
>
>
>    -  Section 3: add a reference where the P-field is defined
>
> *Adnan:* Already added or I might be not getting you where exactly you
are pointing.

>
>
>
>
See the changes in the attached file.

@Pascal Thubert <pascal.thub...@gmail.com> please check the changes and
upload the draft.

Tthanks and happy holidays.

> *From: *Carles Gomez Montenegro <carles.gomez=40upc....@dmarc.ietf.org>
> *Date: *Tuesday, 15 April 2025 at 09:52
> *To: *6lo@ietf.org <6lo@ietf.org>
> *Subject: *[6lo] Re: Call for adoption of draft-ietf-6lo-updating-rfc-8928
>
> Apologies, we meant that the call for adoption will end on the 22nd of
> *April*, EOB.
>
>
>
> Cheers,
>
>
>
> Shwetha and Carles
>
>
>
> On Tue, 15 Apr 2025 at 09:46, Carles Gomez Montenegro <
> carles.go...@upc.edu> wrote:
>
> Dear 6lo WG,
>
> This message starts a call for WG adoption of 
> draft-ietf-6lo-updating-rfc-8928-00.
>
> (Link: https://datatracker.ietf.org/doc/draft-ietf-6lo-updating-rfc-8928)
>
>
> This document aims to fix a mistake with the C flag in EARO in RFC 8928.
>
> As this is a short document, the call will end on the 22nd of May, EOB.
>
>
>
> Please state whether you are in favor of adopting this document.
>
>
>
> Also, comments and reviews of the document will be very much appreciated.
>
>
>
> Thanks,
>
>
>
> Shwetha and Carles
>
>
>
>
> _______________________________________________
> 6lo mailing list -- 6lo@ietf.org
> To unsubscribe send an email to 6lo-le...@ietf.org
>


-- 
Regards,

Adnan
Title: Diff: draft-ietf-6lo-updating-rfc-8928-00.txt - Updating-RFC-8928.txt
  draft-ietf-6lo-updating-rfc-8928-00.txt   Updating-RFC-8928.txt
   
   
   
   
  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 P Bari   Intended status: Standards Track P Bari
  Expires: 16 October 2025 14 April 2025   Expires: 19 October 2025 17 April 2025
   
   
  Moving the C Flag in EARO   Fixing the C-Flag in EARO
  draft-ietf-6lo-updating-rfc-8928-00   draft-ietf-6lo-updating-rfc-8928-00
   
  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 explicitly specifying   for Low-Power and Lossy Networks” (AP-ND), by updating the bit
  the bit position for the “C” flag and registering it with IANA. This   position for the C-flag and registering it with IANA.
  clarification ensures consistent implementation and interoperability  
  of the AP-ND protocol, which protects against address theft and  
  impersonation attacks in Low-Power and Lossy Networks (LLNs). This  
  update provides a precise definition of the “C” flag’s bit position,  
  enabling correct deployment and verification of AP-ND’s security  
  features.  
   
  Status of This Memo   Status of This Memo
   
  This Internet-Draft is submitted in full conformance with the   This Internet-Draft is submitted in full conformance with the
  provisions of BCP 78 and BCP 79.   provisions of BCP 78 and BCP 79.
   
  Internet-Drafts are working documents of the Internet Engineering   Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF). Note that other groups may also distribute   Task Force (IETF). Note that other groups may also distribute
  working documents as Internet-Drafts. The list of current Internet-   working documents as Internet-Drafts. The list of current Internet-
  Drafts is at https://datatracker.ietf.org/drafts/current/.   Drafts is at https://datatracker.ietf.org/drafts/current/.
   
  Internet-Drafts are draft documents valid for a maximum of six months   Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any   and may be updated, replaced, or obsoleted by other documents at any
  time. It is inappropriate to use Internet-Drafts as reference   time. It is inappropriate to use Internet-Drafts as reference
  material or to cite them other than as "work in progress."   material or to cite them other than as "work in progress."
   
  This Internet-Draft will expire on 16 October 2025.   This Internet-Draft will expire on 19 October 2025.
   
  Copyright Notice   Copyright Notice
   
  Copyright (c) 2025 IETF Trust and the persons identified as the   Copyright (c) 2025 IETF Trust and the persons identified as the
  document authors. All rights reserved.   document authors. All rights reserved.
   
  This document is subject to BCP 78 and the IETF Trust's Legal   This document is subject to BCP 78 and the IETF Trust's Legal
  Provisions Relating to IETF Documents (https://trustee.ietf.org/   Provisions Relating to IETF Documents (https://trustee.ietf.org/
  license-info) in effect on the date of publication of this document.   license-info) in effect on the date of publication of this document.
  Please review these documents carefully, as they describe your rights   Please review these documents carefully, as they describe your rights
  and restrictions with respect to this document. Code Components   and restrictions with respect to this document. Code Components
  extracted from this document must include Revised BSD License text as   extracted from this document must include Revised BSD License text as
  described in Section 4.e of the Trust Legal Provisions and are   described in Section 4.e of the Trust Legal Provisions and are
  provided without warranty as described in the Revised BSD License.   provided without warranty as described in the Revised BSD License.
   
  Table of Contents   Table of Contents
   
  1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
  2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3   2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
  2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3   2.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
  2.2. References . . . . . . . . . . . . . . . . . . . . . . . 3   2.2. References . . . . . . . . . . . . . . . . . . . . . . . 2
  2.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4   2.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
  3. Updating RFC 8928 . . . . . . . . . . . . . . . . . . . . . . 4   3. Updating RFC 8928 . . . . . . . . . . . . . . . . . . . . . . 3
    4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
  4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5   5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
  4.1. Bit Position of the "C" Flag . . . . . . . . . . . . . . 5   5.1. Bit Position of the C-flag . . . . . . . . . . . . . . . 4
  5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6  
  6. Normative References . . . . . . . . . . . . . . . . . . . . 6   6. Normative References . . . . . . . . . . . . . . . . . . . . 5
  7. Informative References . . . . . . . . . . . . . . . . . . . 7   7. Informative References . . . . . . . . . . . . . . . . . . . 6
  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
   
  1. Introduction   1. Introduction
   
  The classical Neighbor Discovery (IPv6 ND) Protocol [RFC4861]  
  [RFC4862] was defined for serial links and shared transit media such  
  as Ethernet at a time when broadcast was cheap on those media while  
  memory for neighbor cache was expensive. It was thus designed as a  
  reactive protocol that relies on caching and multicast operations for  
  the Address Resolution (AR, aka Address Discovery or Address Lookup)  
  and Duplicate Address Detection (DAD) of IPv6 unicast addresses.  
  Those multicast operations typically impact every node on-link when  
  at most one is really targeted, which is a waste of energy, and imply  
  that all nodes are awake to hear the request, which is inconsistent  
  with power saving (sleeping) modes.  
   
  Low-Power Personal Area Networks (LoWPANs) require an optimized IPv6  
  Neighbor Discovery due to resource constraints and high multicast  
  overhead. To address this, 6LoWPAN ND [RFC6775], [RFC8505],  
  [RFC8929], [RFC9685], [I-D.ietf-6lo-prefix-registration] introduces a  
  unicast, anycast, and multicast Address Registration (AR) mechanism  
  as well as a Prefix Registration (PR) mechanism. Staring with  
  [RFC8505], the registration mechanism uses the Extended Address  
  Registration Option (EARO), significantly reducing reliance on  
  multicast for Duplicate Address Detection (DAD). In these networks,  
  the 6LoWPAN Border Router (6LBR) serves as a central repository for  
  registered addresses. 6LoWPAN ND is being generalized to NBMA  
  networks as Subnet Neighbor Discovery (SND), see  
  [I-D.ietf-6man-ipv6-over-wireless].  
  For enhanced security, [RFC8505] introduces a Registration Ownership  
  Verifier (ROVR) in the EARO. Building on this, the  
  "Address-Protected Neighbor Discovery for LLNs" [RFC8928], protects  
  the ownership of unicast IPv6 addresses registered with [RFC8505].  
  In this framework, a node auto-configures a public/private key pair  
  and signs its address registrations, enabling the first-hop router  
  (6LoWPAN Router (6LR)) to validate registrations and perform source  
  address verification.  
   
  However, the “Address-Protected Neighbor Discovery for Low-Power and   The “Address-Protected Neighbor Discovery for Low-Power and Lossy
  Lossy Networks” [RFC8928] (AP-ND), initially defined the “C” flag in   Networks” (AP-ND) [RFC8928] , initially defined the C-flag in the
  EARO, later on [RFC9685] defined the P-Field in bits 2 and 3 of the   EARO in bit position 3; later [RFC9685] defined the P-field in bits 2
  EARO flags with proper IANA registration, causing an overlap with   and 3 of the EARO flags field with proper IANA registration, causing
  Figure 1 of [RFC8928] which depicts the location of the “C” flag.   an overlap with Figure 1 of [RFC8928] which depicts the location of
    the C-flag.
   
  This specification updates [RFC8928] by repositioning the “C” flag as   This specification updates [RFC8928] by repositioning the C-flag as
  bit 1 of the EARO flag avoiding conflicts.   bit 1 of the EARO flags field, thereby preventing conflicts.
   
  2. Terminology   2. Terminology
   
  2.1. Requirements Language   2.1. Requirements Language
   
  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
  "OPTIONAL" in this document are to be interpreted as described in BCP   "OPTIONAL" in this document are to be interpreted as described in BCP
       
Skipping Skipping
  This document uses terms and concepts that are discussed in:   This document uses terms and concepts that are discussed in:
   
  * Neighbor Discovery for IP version 6 [RFC4861]   * Neighbor Discovery for IP version 6 [RFC4861]
   
  * IPv6 Stateless Address Autoconfiguration [RFC4862]   * IPv6 Stateless Address Autoconfiguration [RFC4862]
   
  * Neighbor Discovery Optimization for IPv6 over Low-Power Wireless   * Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
  Personal Area Networks (6LoWPANs) [RFC6775]   Personal Area Networks (6LoWPANs) [RFC6775]
   
  * Registration Extensions for IPv6 over Low-Power Wireless Personal   * Registration Extensions for IPv6 over Low-Power Wireless Personal
  Area Network (6LoWPAN) Neighbor Discovery [RFC8505]   Area Network (6LoWPAN) Neighbor Discovery [RFC8505]
   
  * IPv6 Backbone Router [RFC8929]   * IPv6 Backbone Router [RFC8929]
   
  * Address-Protected Neighbor Discovery for Low-Power and Lossy   * Address-Protected Neighbor Discovery for Low-Power and Lossy
  Networks [RFC8928]   Networks [RFC8928]
   
  * Listener Subscription for IPv6 Neighbor Discovery Multicast and   * Listener Subscription for IPv6 Neighbor Discovery Multicast and
  Anycast Addresses [RFC9685]   Anycast Addresses [RFC9685]
   
  2.3. Acronyms   2.3. Acronyms
   
  This document uses the following abbreviations:   This document uses the following abbreviations:
   
  6LN: 6LoWPAN Node   6LN: 6LoWPAN Node
  6LBR: 6LoWPAN Border Router   6LBR: 6LoWPAN Border Router
  6LR: 6LoWPAN Router   6LR: 6LoWPAN Router
  AP-ND: Address-Protected Neighbor Discovery   AP-ND: Address-Protected Neighbor Discovery
  ARO: Address Registration Option   ARO: Address Registration Option
  DAD: Duplicate Address Detection   DAD: Duplicate Address Detection
  EARO: Extended Address Registration Option   EARO: Extended Address Registration Option
  LLN: Low-Power and Lossy Network   LLN: Low-Power and Lossy Network
  LoWPAN: Low-Rate Personal Area Network (IEEE Std. 802.15.4)   LoWPAN: Low-Rate Personal Area Network (IEEE Std. 802.15.4)
  [IEEE802154]   [IEEE802154]
  NDP: Neighbor Discovery Protocol   NDP: Neighbor Discovery Protocol
  ROVR: Registration Ownership Verifier   ROVR: Registration Ownership Verifier
  SND: Subnet Neighbor Discovery  
  TID: Transaction ID   TID: Transaction ID
   
  3. Updating RFC 8928   3. Updating RFC 8928
   
  The "Address-Protected Neighbor Discovery for Low-Power and Lossy   In [RFC8928], the C-flag is specified in the EARO flags field at bit
  Networks" [RFC8928] was defined to protect the ownership of unicast   position 3 (as depicted in the Figure 1 of [RFC8928]); however, fails
  IPv6 addresses that are registered with [RFC8505]. In [RFC8928], the   to register its position with IANA. Later, [RFC9685] defined the
  "C" flag is shown in the EARO flags field at bit position 3 (as   P-field in bits 2 and 3 of the EARO flags field and obtained proper
  depicted in Figure 1 of [RFC8928]); however, it does not explicitly   IANA registration, but this introduced an overlap with the
  specify the bit number and fails to register its position with IANA.   representation in [RFC8928]. To resolve the conflict, this
  Later, [RFC9685] defined the P-Field in bits 2 and 3 of the EARO   specification updates [RFC8928] by repositioning the C-flag to bit 1
  flags field and obtained proper IANA registration, but this   of the EARO flags field, thereby avoiding the overlapping
  introduced an overlap with the representation in [RFC8928]. To   definitions. Moreover, figure 1 of this I-D replaces the Figure 1
  resolve the conflict, this specification updates [RFC8928] by   [RFC8928].
  repositioning the "C" flag to bit 1 of the EARO flags field, thereby  
  avoiding the overlapping definitions.  
   
  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 |F|PrefixLength | Opaque |   | Type | Length |F|PrefixLength | Opaque |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |R|C| P | I |R|T| TID | Registration Lifetime |   |R|C| P | I |R|T| TID | Registration Lifetime |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | |   | |
  ... Registration Ownership Verifier ...   ... Registration Ownership Verifier ...
  | (64, 128, 192, or 256 bits) |   | (64, 128, 192, or 256 bits) |
  | |   | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
  Figure 1: Extended Address Registration Option (EARO) Format in   Figure 1: Extended Address Registration Option (EARO) Format in
  NS messages   NS messages
   
  Option Fields of interest for this specification:   Option fields of interest for this specification:
   
  *Type:* 33  
   
  *Length:* Defined in [RFC8505] and copied in the "EARO Length" field  
  in the associated Crypto-ID Parameters Option (CIPO).  
   
  *Status:* Defined in [RFC8505].  
   
  *Opaque:* Defined in [RFC8505].  
   
  *R (Reserved):* 1-bit unsigned integer. It MUST be set to zero by   *R (Reserved):* 1-bit unsigned integer. It MUST be set to zero by
  the sender and MUST be ignored by the receiver.   the 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 P-Field   *P:* Two bit field. Defined in [RFC9685]
   
  *I, R, T:* Defined in [RFC8505].   *I, R, T:* Defined in [RFC8505].
   
  *TID and Registration Lifetime:* Defined in [RFC8505].   4. Security Considerations
   
  *Registration Ownership Verifier (ROVR):* When the "C" flag is set,   This specification does not introduce any new security considerations
  this field contains a Crypto-ID.   beyond those already discussed in [RFC8928] and [RFC8505].
   
  4. IANA Considerations   5. IANA Considerations
   
  4.1. Bit Position of the "C" Flag   5.1. Bit Position of the C-flag
   
  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. IANA is   [RFC8928] to position it as bit 1 in the EARO flags field. IANA is
  requested to make an addition to the "Address Registration Option   requested to refernce this I-D in addition to [RFC8928] when updating
  Flags" [IANA.ICMP.ARO.FLG] registry under the heading "Internet   the "Address Registration Option Flags" [IANA.ICMP.ARO.FLG] registry
  Control Message Protocol version 6 (ICMPv6) Parameters" as indicated   under the heading "Internet Control Message Protocol version 6
  in Table 1:   (ICMPv6) Parameters" as specified in Table 1:
   
  +---------------+----------+-----------+   +---------------+---------+-----------+
  | ARO flag | Meaning | Reference |   | ARO flag | Meaning | Reference |
  +---------------+----------+-----------+   +---------------+---------+-----------+
  | 1 (suggested) | "C" Flag | RFC 8928 |   | 1 (suggested) | C-Flag | RFC 8928 |
  +---------------+----------+-----------+   +---------------+---------+-----------+
   
  Table 1: Bit Position of the "C" Flag   Table 1: Bit Position of the C-flag
  5. Acknowledgments  
   
  Many thanks to Dave Thaler and Dan Romascanu for their early INT-DIR  
  review.  
   
  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>.
   
       
Skipping Skipping
  Wireless Personal Area Network (6LoWPAN) Neighbor   Wireless Personal Area Network (6LoWPAN) Neighbor
  Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,   Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
  <https://www.rfc-editor.org/info/rfc8505>.   <https://www.rfc-editor.org/info/rfc8505>.
   
  [RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik,   [RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik,
  "Address-Protected Neighbor Discovery for Low-Power and   "Address-Protected Neighbor Discovery for Low-Power and
  Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November   Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November
  2020, <https://www.rfc-editor.org/info/rfc8928>.   2020, <https://www.rfc-editor.org/info/rfc8928>.
   
  [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.
   
  [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>.
   
  7. Informative References   7. Informative References
   
  [IEEE802154]   [IEEE802154]
  IEEE standard for Information Technology, "IEEE Std   IEEE standard for Information Technology, "IEEE Std
  802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)   802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
  and Physical Layer (PHY) Specifications for Low-Rate   and Physical Layer (PHY) Specifications for Low-Rate
  Wireless Personal Area Networks".   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>.
   
  [I-D.ietf-6lo-prefix-registration]  
  Thubert, P., "IPv6 Neighbor Discovery Prefix  
  Registration", Work in Progress, Internet-Draft, draft-  
  ietf-6lo-prefix-registration-07, 25 March 2025,  
  <https://datatracker.ietf.org/doc/html/draft-ietf-6lo-  
  prefix-registration-07>.  
   
  [I-D.ietf-6man-ipv6-over-wireless]  
  Thubert, P. and M. Richardson, "Architecture and Framework  
  for IPv6 over Non-Broadcast Access", Work in Progress,  
  Internet-Draft, draft-ietf-6man-ipv6-over-wireless-07, 23  
  November 2024, <https://datatracker.ietf.org/doc/html/  
  draft-ietf-6man-ipv6-over-wireless-07>.  
   
  Authors' Addresses   Authors' Addresses
   
  Pascal Thubert   Pascal Thubert
  06330 Roquefort-les-Pins   06330 Roquefort-les-Pins
  France   France
  Email: pascal.thub...@gmail.com   Email: pascal.thub...@gmail.com
    
_______________________________________________
6lo mailing list -- 6lo@ietf.org
To unsubscribe send an email to 6lo-le...@ietf.org

Reply via email to