<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body dir="auto">
Hello Baldur;
<div><br>
</div>
<div>There’s the hack that can be helpful and then there’s the proper solution.</div>
<div><br>
</div>
<div>As for hacks, indeed snooping can help a lot. As it goes we went for ND and DHCP snooping rather than MLD and there are many reasons for that, reliability, Desire to know the address not just the snma group, how easily is to query from a L2 device such
as an AP or a switch etc... you may look for IETF SAVI docs to see how that is done.<br>
<div><br>
</div>
<div>But then there are cases where the hack falls short. Snooping on wireless may miss packets, a silent node (e.g., wake on lan) may not show. The snooped state is mostly ok but not as good as a state that is installed And maintained by a protocol that is
meant for it, including support for mobility and lifetime.</div>
<div><br>
Not so surprising after all is it?<br>
<div dir="ltr">
<div><br>
</div>
<div>Pascal</div>
</div>
<div dir="ltr"><br>
<blockquote type="cite">Le 7 juin 2020 à 21:34, Baldur Norddahl <baldur.norddahl@gmail.com> a écrit :<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">What I do not understand about this proposal is why we do not just fix wireless multicast? For example the AP could unicast multicast frames to subscribed STA and combined with MLD snooping we are done. Would be backwards compatible too, compared
to a whole new protocol which will take decades to gain traction.
<div><br>
</div>
<div>Regards,</div>
<div><br>
</div>
<div>Baldur</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, Jun 7, 2020 at 8:59 PM Joel Halpern <<a href="mailto:jmh@joelhalpern.com">jmh@joelhalpern.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Just to clarify context, at this stage this is just Pascal's interesting <br>
idea for how to make ND work better on wireless. No IETF working group <br>
has adopted this. Various people seem to be interested, but it will be <br>
some time before we know if his approach gets traction.<br>
<br>
The biggest difference between this and earlier changes along this line <br>
is that the wireless broadcast problem provides motivation for the <br>
change, where earlier efforts were more ~wouldn't it just be simpler if...~<br>
<br>
Yours,<br>
Joel Halpern<br>
<br>
On 6/7/2020 2:28 PM, Etienne-Victor Depasquale wrote:<br>
> What I'm amazed at is the concept of multi-link subnet and the change in <br>
> IP model being proposed.<br>
> <br>
> See, for example, section 4 of <br>
> <a href="https://tools.ietf.org/html/draft-thubert-6man-ipv6-over-wireless-05" rel="noreferrer" target="_blank">
https://tools.ietf.org/html/draft-thubert-6man-ipv6-over-wireless-05</a><br>
> <br>
> Has anyone felt the same about the change being proposed? This swept <br>
> away 25 years of thinking about IP subnets and IP links for me.<br>
> <br>
> Etienne<br>
> <br>
> On Sun, Jun 7, 2020 at 6:03 PM Brandon Martin <<a href="mailto:lists.nanog@monmotha.net" target="_blank">lists.nanog@monmotha.net</a>
<br>
> <mailto:<a href="mailto:lists.nanog@monmotha.net" target="_blank">lists.nanog@monmotha.net</a>>> wrote:<br>
> <br>
> On 6/7/20 6:01 AM, Denys Fedoryshchenko wrote:<br>
> > There are very interesting and unobvious moments on IPv4 vs IPv6,<br>
> for<br>
> > example related to battery lifetime in embedded electronics. In<br>
> ipv4,<br>
> > many devices are forced to send "keepalives" so that the NAT<br>
> entry does<br>
> > not disappear, with IPv6 it is not required and bidirectional<br>
> > communications possible at any time. And in fact, it has a huge<br>
> impact<br>
> > on the cost and battery life of IoT devices.<br>
> > When I developed some IoT devices for clients, it turned out that if<br>
> > "IPv6-only" is possible, this significantly reduces the cost of the<br>
> > solution and simplify setup.<br>
> <br>
> This is difficult to understate. "People" are continually amazed<br>
> when I<br>
> show them that I can leave TCP sessions up for days at a time (with<br>
> properly configured endpoints) with absolutely zero keepalive traffic<br>
> being exchanged.<br>
> <br>
> As amusingly useful as this may be, it pales in comparison to the<br>
> ability to do the same on deeply embedded devices running off small<br>
> primary cell batteries. I've got an industrial sensor network product<br>
> where the device poll interval is upwards of 10 minutes, and even then<br>
> it only turns on its receiver. The transmitter only gets lit up about<br>
> once a day for a "yes I'm still here" notification unless it has<br>
> something else to say.<br>
> <br>
> In the end, we made it work across IPv4 by inserting an application<br>
> level gateway. We just couldn't get reliable, transparent IPv6<br>
> full-prefix connectivity from any of the cellular telematics providers<br>
> at the time. I don't know if this has changed. For our application,<br>
> this was fine, but for mixed vendor "IoT" devices, it would probably<br>
> not<br>
> work out well.<br>
> -- <br>
> Brandon Martin<br>
> <br>
> <br>
> <br>
> -- <br>
> Ing. Etienne-Victor Depasquale<br>
> Assistant Lecturer<br>
> Department of Communications & Computer Engineering<br>
> Faculty of Information & Communication Technology<br>
> University of Malta<br>
> Web. <a href="https://www.um.edu.mt/profile/etiennedepasquale" rel="noreferrer" target="_blank">
https://www.um.edu.mt/profile/etiennedepasquale</a><br>
<br>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</body>
</html>