[6lo] Re: [IPv6]Request for review of draft-ietf-6lo-nd- gaao prior to IETF Last Call

--===============3054341705269114666==
Content-Type: multipart/alternative; boundary="000000000000780bb1064ab3dce0"

--000000000000780bb1064ab3dce0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 LLN=
s


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=E2=80=AFPM Lorenzo Colitti <lorenzo=3D
40google.com-Tr9gZwTxerDR74oF6e/[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 likel=
y
> to result in lower quality implementations, lower interoperability, and
> potentially larger code size.
>
> So - do we really need these new address assignment methodologies? And ho=
w
> 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=E2=80=AFPM Shwetha <[email protected]=
om>
> 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 th=
e
>> IETF last call. Please provide your feedback by 2nd October 2025.
>>
>> Thank you for your time and consideration.
>>
>> Best regards,
>>
>> Carles, =C3=89ric 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]
>


--=20
Regards,

Adnan

--000000000000780bb1064ab3dce0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:verdana,=
sans-serif;font-size:small;color:#000000">Dear Lorenzo,<br><br>Thank you fo=
r your thoughtful and detailed review. Your question, whether a new address=
 assignment mechanism is truly needed given the existence of SLAAC and DHCP=
v6, is both valid and important.<br><br>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.<br><br>To clari=
fy, the intent of GAAO is <b>NOT=C2=A0</b>to replace SLAAC or DHCPv6 in gen=
eral IPv6 deployments. Rather, it is scoped specifically to 6LoWPAN LLNs op=
erating under RFC6775/RFC8505 Neighbor Discovery optimizations, where the a=
rchitectural goals include:<br><ul><li>Strict minimization of multicast tra=
ffic</li><li>Avoidance of centralized infrastructure</li><li>Localized (1-h=
op) control-plane interactions</li><li>Support for distributed, algorithmic=
 address assignment</li></ul>Regarding DHCPv6 efficiency, while DHCPv6 can =
indeed be efficient in traditional IPv6 networks (e.g., single-RTT exchange=
s 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 nod=
es on the channel to wake and process the frame. In duty-cycled networks, t=
his increases radio wake-ups, idle listening time, and energy consumption.<=
br><br>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.<br><br>That =
said, we agree that the draft currently states these differences rather tha=
n clearly demonstrating them. We are revising the Introduction to:<br><ul><=
li>Explicitly scope the mechanism to RFC8505-based 6LoWPAN LLNs</li><li>Cla=
rify that it is not intended for general IPv6 networks</li><li>Better expla=
in the architectural differences with DHCPv6</li><li>Strengthen the explana=
tion regarding multicast cost in constrained LLNs</li></ul><br>Thanks for t=
he comments, as they help ensure that the problem statement and applicabili=
ty are clearly justified. We hope the revised text will address your concer=
ns, and we welcome further feedback once the update is available.<br><br></=
div></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"=
ltr" class=3D"gmail_attr">On Thu, Nov 6, 2025 at 11:24=E2=80=AFPM Lorenzo C=
olitti &lt;lorenzo=3D<a href=3D"mailto:40google.com-Tr9gZwTxerDR74oF6e/[email protected]">40googl=
e.com-Tr9gZwTxerDR74oF6e/[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><div dir=3D"ltr">Hi Swetha,<div><br></div><div>Thanks f=
or sending this to 6man.</div><div><br></div><div>One concern I have with t=
his document is that it introduces a completely new and completely separate=
 way to perform address and prefix assignment, which are already well suppo=
rted in IPv6. SLAAC and DHCPv6 are extremely widely deployed and provide mo=
st or all all the functionality that is described here.</div><div><br></div=
><div>If we introduce=C2=A0new standards then we will be requiring=C2=A0imp=
lementers and standards developers to do more work, which all else being eq=
ual is likely to result in lower quality implementations, lower interoperab=
ility, and potentially larger code size.</div><div><br></div><div>So - do w=
e really need these new address assignment=C2=A0methodologies? And how many=
 hosts will need them? For example, for prefix delegation the draft says th=
at DHCPv6 &quot;remains inefficient from an energy and bandwidth consumptio=
n viewpoint&quot;, but it does not provide any evidence to support that sta=
tement. What is inefficient about DHCPv6? At best, DHCPv6 can be a single-R=
TT exchange with lifetimes as long as 2^32 seconds (136.1 years), and that =
seems quite efficient.</div><div><br></div><div>Cheers,</div><div>Lorenzo</=
div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_at=
tr">On Thu, Sep 18, 2025 at 9:17=E2=80=AFPM Shwetha &lt;<a href=3D"mailto:s=
[email protected]" target=3D"_blank">[email protected]</a>=
&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div=
 dir=3D"ltr"><div dir=3D"ltr"><p><span>Dear 6man Working Group,<br></span><=
/p><p><span>This email is a request for your opinion and comments on=C2=A0<=
/span><code><span>draft-ietf-6lo-nd-gaao</span></code><span> before it proc=
eeds to IETF Last Call. The draft&#39;s current version can be found at:</s=
pan></p><p><span><a href=3D"https://datatracker.ietf.org/doc/draft-ietf-6lo=
-nd-gaao/" target=3D"_blank">https://datatracker.ietf.org/doc/draft-ietf-6l=
o-nd-gaao/</a></span></p><p><span>This draft has already been reviewed by t=
he Internet Directorate and has also undergone a Gen Art review. Also 6lo w=
g has completed WGLC of this draft. We are reaching out to the 6man specifi=
cally because of your expertise in IPv6 ND, that has implications for this =
draft, and we would value your perspective.</span></p><p><span>We would app=
reciate any comments you may have and address it ahead of the IETF last cal=
l. Please provide your feedback by 2nd October 2025.</span></p><p><span>Tha=
nk you for your time and consideration.</span></p><p><span>Best regards,</s=
pan></p><p><span>Carles, =C3=89ric and Shwetha=C2=A0</span></p><p><span>On =
behalf of 6lo working group</span></p></div>
</div>
--------------------------------------------------------------------<br>
IETF IPv6 working group mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a><br>
List Info: <a href=3D"https://mailman3.ietf.org/mailman3/lists/[email protected]=
g/" rel=3D"noreferrer" target=3D"_blank">https://mailman3.ietf.org/mailman3=
/lists/[email protected]/</a><br>
--------------------------------------------------------------------<br>
</blockquote></div>
_______________________________________________<br>
6lo mailing list -- <a href=3D"mailto:[email protected]" target=3D"_blank">6lo@i=
etf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:[email protected]" targe=
t=3D"_blank">[email protected]</a><br>
</blockquote></div><div><br clear=3D"all"></div><div><br></div><span class=
=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s=
ignature"><div dir=3D"ltr">Regards,<div><br></div><div>Adnan</div></div></d=
iv>

--000000000000780bb1064ab3dce0--


--===============3054341705269114666==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KNmxvIG1haWxp
bmcgbGlzdCAtLSA2bG9AaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byA2
bG8tbGVhdmVAaWV0Zi5vcmcK

--===============3054341705269114666==--