Just to clarify context, at this stage this is just Pascal's interesting
idea for how to make ND work better on wireless. No IETF working group
has adopted this. Various people seem to be interested, but it will be
some time before we know if his approach gets traction.
The biggest difference between this and earlier changes along this line
is that the wireless broadcast problem provides motivation for the
change, where earlier efforts were more ~wouldn't it just be simpler if...~
Yours,
Joel Halpern
On 6/7/2020 2:28 PM, Etienne-Victor Depasquale wrote:
What I'm amazed at is the concept of multi-link subnet and the change in
IP model being proposed.
See, for example, section 4 of
https://tools.ietf.org/html/draft-thubert-6man-ipv6-over-wireless-05
Has anyone felt the same about the change being proposed? This swept
away 25 years of thinking about IP subnets and IP links for me.
Etienne
On Sun, Jun 7, 2020 at 6:03 PM Brandon Martin <lists.na...@monmotha.net
<mailto:lists.na...@monmotha.net>> wrote:
On 6/7/20 6:01 AM, Denys Fedoryshchenko wrote:
> There are very interesting and unobvious moments on IPv4 vs IPv6,
for
> example related to battery lifetime in embedded electronics. In
ipv4,
> many devices are forced to send "keepalives" so that the NAT
entry does
> not disappear, with IPv6 it is not required and bidirectional
> communications possible at any time. And in fact, it has a huge
impact
> on the cost and battery life of IoT devices.
> When I developed some IoT devices for clients, it turned out that if
> "IPv6-only" is possible, this significantly reduces the cost of the
> solution and simplify setup.
This is difficult to understate. "People" are continually amazed
when I
show them that I can leave TCP sessions up for days at a time (with
properly configured endpoints) with absolutely zero keepalive traffic
being exchanged.
As amusingly useful as this may be, it pales in comparison to the
ability to do the same on deeply embedded devices running off small
primary cell batteries. I've got an industrial sensor network product
where the device poll interval is upwards of 10 minutes, and even then
it only turns on its receiver. The transmitter only gets lit up about
once a day for a "yes I'm still here" notification unless it has
something else to say.
In the end, we made it work across IPv4 by inserting an application
level gateway. We just couldn't get reliable, transparent IPv6
full-prefix connectivity from any of the cellular telematics providers
at the time. I don't know if this has changed. For our application,
this was fine, but for mixed vendor "IoT" devices, it would probably
not
work out well.
--
Brandon Martin
--
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale
