Re: understanding IPv6

[Pascal Thubert (pthubert) via NANOG]

Hello Baldur;

There’s the hack that can be helpful and then there’s the proper solution.

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.

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.

Not so surprising after all is it?

Pascal

Le 7 juin 2020 à 21:34, Baldur Norddahl  a écrit :


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.

Regards,

Baldur


On Sun, Jun 7, 2020 at 8:59 PM Joel Halpern 
mailto:j...@joelhalpern.com>> wrote:
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 
> 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

Re: understanding IPv6

[Pascal Thubert (pthubert) via NANOG]

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  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 > > 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
> 

RE: understanding IPv6

[Keith Medcalf]

On Sunday, 7 June, 2020 21:49, William Herrin  wropte:

> ...
> Keepalive requirements are a property of whether or not you employ stateful 
> firewalls.
> ...

Keepalive's are not designed for stateful firewalls, they are designed to 
permit the endpoints to know whether the communication channel is still intact.

They may also be useful to "keepalive" connection table entries in stateful 
firewalls and NAT/NATP devices, however this is merely a side effect and not 
their purpose.

--
Both optimists and pessimists contribute to society.  The optimist invents the 
aeroplane, the pessimist the parachute.

Re: understanding IPv6

[William Herrin]

On Sun, Jun 7, 2020 at 3: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.

Hi Denys,

Not exactly. Keepalive requirements are a property of whether or not
you employ stateful firewalls. IPv4's address-overloaded NAT
inherently requires a stateful firewall while that's optional when
you're not using NAT. However, there are great reasons from a security
posture perspective to employ a stateful firewall regardless.

Having an external host be unable to send packets to an internal host
where the internal host didn't initiate the communication is a
relatively solid foundation on which to build a network security
process. It's not always the best answer but if you build your
software with the assumption it won't be there, you're making a
mistake.

Also bear in mind that address-overloaded NAT has a security benefit
over stateful firewalls: it "fails closed" in the sense that mistakes
configuring the firewall tend to leave it incorrectly unable to
deliver a packet rather than incorrectly able to deliver a packet.
Since network products do implement this form of IPv6 NAT (e.g. the
Linux masquerade target exists for ip6tables too) you can expect some
organizations to use it. This is especially true early in their
adoption of IPv6 when they don't understand it as well as IPv4. Many
will want to keep their security posture as closely aligned with IPv4
as possible.

Regards,
Bill Herrin



--
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: understanding IPv6

[Harald Koch]

On Sun, Jun 7, 2020, at 12:02, Brandon Martin wrote:
> 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.

On the other hand, I'm constantly having to remind developers at $job that 
while this may be normal, it's not guaranteed, and they need to deal with TCP 
sessions that go down without requiring operator intervention.

Reliable networks do not teach developers about fault tolerance ;)

-- 
Harald

Re: understanding IPv6

[Etienne-Victor Depasquale]

The proposal seems to be aimed at more than that.

One major problem which this proposal addresses

is assignment of IPv6 subnets to links as transient and unreliable as links
between IoT nodes.

My ***guess*** is that binding an IPv6 subnet to a link that elusive would
be bad for routing.


Etienne



On Sun, Jun 7, 2020 at 9:33 PM Baldur Norddahl 
wrote:

> 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.
>
> Regards,
>
> Baldur
>
>
> On Sun, Jun 7, 2020 at 8:59 PM Joel Halpern  wrote:
>
>> 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 > > > 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

Re: understanding IPv6

[Etienne-Victor Depasquale]

" 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) 
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  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  > 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

Re: understanding IPv6

[Baldur Norddahl]

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.

Regards,

Baldur


On Sun, Jun 7, 2020 at 8:59 PM Joel Halpern  wrote:

> 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  > > 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
>
>

Re: understanding IPv6

[Joel Halpern]

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 > 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

Re: understanding IPv6

[Etienne-Victor Depasquale]

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 
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

Re: understanding IPv6

[Denys Fedoryshchenko]

On 2020-06-07 19:02, Brandon Martin 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.

"Cellular telematics" are bad in general.
I had problem during development of OTA,because operator decided that he 
should
put TCP session data limit about 1MB, so people dont abuse unlimited 
data plan.

As their DPI was not very precise, i was getting
random hangs during data transfer. Did workaround by splitting OTA to 
several 256Kb chunks.
With IPv6 major problems that most of operators open only some ports, 
block inbound connections,

often run stateful firewall.
Usually customers prefer to pay extra to get custom firmware that is 
working properly on

particular cellular operator. Still IPv6 works better than IPv4.

Re: understanding IPv6

[Brandon Martin]

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

Re: understanding IPv6

[Daniel Sterling]

On Sun, Jun 7, 2020 at 7:17 AM Bjørn Mork  wrote:
> Sorry, but I have some problems understanding this. AFAICT, you can't
> read anything about configuring IPv6 access without seeing DHCPv6-PD
> mentioned.

The point isn't that I couldn't read about DHCP PD; the point is that
I didn't know that I needed to understand DHCP PD to also understand
how IPv6 is widely deployed, until someone who did know very kindly
pointed me in the right direction.

>   * Automatic bootstrap from SLAAC, stateless DHCPv6, stateful DHCPv6,
> DHCPv6-PD and any combination

I was overwhelmed with this information. Remember, I'm trying to learn
about IPv6 because I *want* to know more; I don't want to be ignorant.
I really, really am honestly trying, and I'm telling you it was hard.
If I'm *looking* to learn and still can't figure it out, what does
that say about all the people who don't care as much?

-- Dan

Re: understanding IPv6

[Bjørn Mork]

On Sun, Jun 7, 2020 at 2:00 AM Fred Baker  wrote:

>  I'm sorry you have chosen to ignore documents like RFC 3315, which is
>  where DHCP PD was first described (in 2003). It's not like anyone's
>  hiding it.

Erhm, you probably meant RFC 3633 (also 2003).  There was no PD in the
original DHCPv6 spec


Bjørn

Re: understanding IPv6

[Bjørn Mork]

Daniel Sterling  writes:

> In all seriousness, I have been trying to understand IPv6 for a long
> time, and the documentation that I read (again, admittedly not often
> RFCs, but certainly Wikipedia, linux distro docs, etc) never mentioned
> DHCP PD, or at least never mentioned it as something important for how
> end-users would use IPv6.

Sorry, but I have some problems understanding this. AFAICT, you can't
read anything about configuring IPv6 access without seeing DHCPv6-PD
mentioned.

You referred to how OpenWrt "does it out of the box" for example.  So
just for fun, I tried to follow the most natural route from
https://openwrt.org to their IPv6 documentation for end users, which is
3 clicks from the front page to
https://openwrt.org/docs/guide-user/network/ipv6/start
where the first bullet point you see under "Native IPv6 connection" is
  * Automatic bootstrap from SLAAC, stateless DHCPv6, stateful DHCPv6,
DHCPv6-PD and any combination



Bjørn

Re: understanding IPv6

[Denys Fedoryshchenko]

On 2020-06-07 12:35, Daniel Sterling wrote:
On Sun, Jun 7, 2020 at 2:00 AM Fred Baker  
wrote:
I'm sorry you have chosen to ignore documents like RFC 3315, which is 
where DHCP PD was first described (in 2003). It's not like anyone's 
hiding it.

So while it may be true that no one is hiding this information, in my
experience no one is shining a spot light on it either, and until I
was told about it, I was simply unable to understand IPv6.

I can give you that easily reasons to understand it:

1 - we can avoid using virtual hosts, when you can identify things on 
L3, things become much more clear in software. Making virtual hosts in 
some protocols are living hell.

2 - P2P communications are possible again.
2.1 As soon as you need to access ANYTHING at your home, your choice 
only begging ISP for one real IP(most often dynamic), then you struggle 
with port forwarding stuff. With IPv6 it gets really simple.
2.2 Direct P2P file transfers from friend to a friend, you don't need 
cloud services anymore and/or headache with NAT pinning and etc

2.3 Gaming
2.4 Some industrial equipment really love P2P VPN, with IPv4 they are 
forced to use some "middle point" in "cloud", that decrease reliability, 
increase latency and most important jack up operational costs and 
require continuous support of this "middle point".
3 - As user can be easily identified, no more "captcha" stuff or 
struggling with NAT pool IP bans (very painful with gaming services, 
twitter, google).

4 - Dealing with LEA requests is much easier and cheaper

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.


But there is one huge minus. We cannot switch to ipv6 completely and are 
forced to bear the costs of ipv4 too.
In addition, many services (like Sony playstation stuff) continue to ban 
ipv4 address, and doesn't bother themself to implement ipv6 (which is 
supreme stupidity and technical idiocy).

Re: understanding IPv6 (was: Re: QUIC traffic throttled on AT residential)

[Daniel Sterling]

On Sun, Jun 7, 2020 at 2:00 AM Fred Baker  wrote:
> I'm sorry you have chosen to ignore documents like RFC 3315, which is where 
> DHCP PD was first described (in 2003). It's not like anyone's hiding it.

I am sorry as well!

I openly admit I am not the smartest bear in the woods. I struggle to
read through RFCs. Researching IPv6 for me means doing a web search
for "what ipv6 halp", to which google frustratingly returns: No
results found for "what ipv6 halp".

In all seriousness, I have been trying to understand IPv6 for a long
time, and the documentation that I read (again, admittedly not often
RFCs, but certainly Wikipedia, linux distro docs, etc) never mentioned
DHCP PD, or at least never mentioned it as something important for how
end-users would use IPv6.

So while it may be true that no one is hiding this information, in my
experience no one is shining a spot light on it either, and until I
was told about it, I was simply unable to understand IPv6.

Once we know something we can forget that everyone else doesn't know
that same information, and figuring out what inexperienced people need
to know to understand a topic can be difficult. So I am offering to
the community that "DHCP PD" is such a thing: it's something that
everyone who already knows how things works takes for granted.

So when someone points me in the right direction by mentioning such an
important piece of the puzzle, I am genuinely grateful!

-- Dan