Dear Lorenzo, Thank you for your thoughtful and detailed review. Your question, whether a new address assignment mechanism is truly needed given the existence of SLAAC and DHCPv6, is both valid and important.
After considering your comments, we agree that the current draft did not sufficiently articulate the scope and motivation of the work. In particular, it did not clearly distinguish this mechanism from general IPv6 address assignment approaches. To clarify, the intent of GAAO is *NOT *to replace SLAAC or DHCPv6 in general IPv6 deployments. Rather, it is scoped specifically to 6LoWPAN LLNs operating under RFC6775/RFC8505 Neighbor Discovery optimizations, where the architectural goals include: - Strict minimization of multicast traffic - Avoidance of centralized infrastructure - Localized (1-hop) control-plane interactions - Support for distributed, algorithmic address assignment Regarding DHCPv6 efficiency, while DHCPv6 can indeed be efficient in traditional IPv6 networks (e.g., single-RTT exchanges with long lifetimes), its model relies on multicast discovery (FF02::1:2) and a client-server architecture. In IEEE 802.15.4 and similar LLNs, IPv6 multicast is typically mapped to link-layer broadcast, which causes all nodes on the channel to wake and process the frame. In duty-cycled networks, this increases radio wake-ups, idle listening time, and energy consumption. Additionally, DHCPv6 typically requires a reachable server (possibly via relays), introducing multi-hop control paths and centralized state. In contrast, GAAO operates strictly at 1-hop within the existing ND framework and aligns with the distributed design philosophy of RFC8505. That said, we agree that the draft currently states these differences rather than clearly demonstrating them. We are revising the Introduction to: - Explicitly scope the mechanism to RFC8505-based 6LoWPAN LLNs - Clarify that it is not intended for general IPv6 networks - Better explain the architectural differences with DHCPv6 - Strengthen the explanation regarding multicast cost in constrained LLNs Thanks for the comments, as they help ensure that the problem statement and applicability are clearly justified. We hope the revised text will address your concerns, and we welcome further feedback once the update is available. On Thu, Nov 6, 2025 at 11:24 PM Lorenzo Colitti <lorenzo= [email protected]> wrote: > Hi Swetha, > > Thanks for sending this to 6man. > > One concern I have with this document is that it introduces a completely > new and completely separate way to perform address and prefix assignment, > which are already well supported in IPv6. SLAAC and DHCPv6 are extremely > widely deployed and provide most or all all the functionality that is > described here. > > If we introduce new standards then we will be requiring implementers and > standards developers to do more work, which all else being equal is likely > to result in lower quality implementations, lower interoperability, and > potentially larger code size. > > So - do we really need these new address assignment methodologies? And how > many hosts will need them? For example, for prefix delegation the draft > says that DHCPv6 "remains inefficient from an energy and bandwidth > consumption viewpoint", but it does not provide any evidence to support > that statement. What is inefficient about DHCPv6? At best, DHCPv6 can be a > single-RTT exchange with lifetimes as long as 2^32 seconds (136.1 years), > and that seems quite efficient. > > Cheers, > Lorenzo > > On Thu, Sep 18, 2025 at 9:17 PM Shwetha <[email protected]> > wrote: > >> Dear 6man Working Group, >> >> This email is a request for your opinion and comments on >> draft-ietf-6lo-nd-gaao before it proceeds to IETF Last Call. The draft's >> current version can be found at: >> >> https://datatracker.ietf.org/doc/draft-ietf-6lo-nd-gaao/ >> >> This draft has already been reviewed by the Internet Directorate and has >> also undergone a Gen Art review. Also 6lo wg has completed WGLC of this >> draft. We are reaching out to the 6man specifically because of your >> expertise in IPv6 ND, that has implications for this draft, and we would >> value your perspective. >> >> We would appreciate any comments you may have and address it ahead of the >> IETF last call. Please provide your feedback by 2nd October 2025. >> >> Thank you for your time and consideration. >> >> Best regards, >> >> Carles, Éric and Shwetha >> >> On behalf of 6lo working group >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> [email protected] >> List Info: https://mailman3.ietf.org/mailman3/lists/[email protected]/ >> -------------------------------------------------------------------- >> > _______________________________________________ > 6lo mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Regards, Adnan
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
