nanog mailing list archives
Re: understanding IPv6
From: Denys Fedoryshchenko <nuclearcat () nuclearcat com>
Date: Sun, 07 Jun 2020 19:20:29 +0300
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 gettingrandom 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.
Current thread:
- understanding IPv6 (was: Re: QUIC traffic throttled on AT&T residential) Daniel Sterling (Jun 06)
- Message not available
- Re: understanding IPv6 (was: Re: QUIC traffic throttled on AT&T residential) Daniel Sterling (Jun 07)
- Re: understanding IPv6 Denys Fedoryshchenko (Jun 07)
- Re: understanding IPv6 Brandon Martin (Jun 07)
- Re: understanding IPv6 Denys Fedoryshchenko (Jun 07)
- Re: understanding IPv6 Etienne-Victor Depasquale (Jun 07)
- Re: understanding IPv6 Joel Halpern (Jun 07)
- Re: understanding IPv6 Baldur Norddahl (Jun 07)
- Re: understanding IPv6 Etienne-Victor Depasquale (Jun 07)
- Re: understanding IPv6 Pascal Thubert (pthubert) via NANOG (Jun 08)
- Re: understanding IPv6 Pascal Thubert (pthubert) via NANOG (Jun 08)
- Re: understanding IPv6 Etienne-Victor Depasquale (Jun 07)
- Re: understanding IPv6 (was: Re: QUIC traffic throttled on AT&T residential) Daniel Sterling (Jun 07)
- Message not available
- Re: understanding IPv6 Harald Koch (Jun 07)
- Re: understanding IPv6 William Herrin (Jun 07)
- RE: understanding IPv6 Keith Medcalf (Jun 07)