understanding IPv6

Sun Jun 7 20:55:06 UTC 2020

" Multi links subnets are not a figment of my mind.  ".

Precisely.

Two years ago, while lecturing a related study-unit for the first time, I
encountered this document: http://www.ti.com/lit/pdf/swry013

and it was by then already 4 years old.

Figure 1 is inexplicable without the concept of the multi-link subnet.

Cheers,

Etienne

On Sun, Jun 7, 2020 at 9:05 PM Pascal Thubert (pthubert) <pthubert at cisco.com>
wrote:

> Hello Joel:
>
> The draft is supposed to be factual not divagations; if I went too far
> somewhere I need to fix the draft. As you said it is early personal
> submission.
>
> Multi links subnets are not a figment of my mind. We have millions of
> routers deployed that way, using RPL as the subnet routing protocol.
> Admittedly this is IoT but this is true nevertheless.
>
> Keep safe,
>
> Pascal
>
> > Le 7 juin 2020 à 21:00, Joel Halpern <jmh at joelhalpern.com> a écrit :
> >
> > 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.nanog at monmotha.net
> <mailto:lists.nanog at 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
> >
>

-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200607/4f5e6d7d/attachment.html>