Re: understanding IPv6 (was: Re: QUIC traffic throttled on AT&T residential)
On Sun, Jun 7, 2020 at 2:00 AM Fred Baker <fredbakersba@gmail.com> 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
On 2020-06-07 12:35, Daniel Sterling wrote:
On Sun, Jun 7, 2020 at 2:00 AM Fred Baker <fredbakersba@gmail.com> 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).
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
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
On 2020-06-07 19:02, Brandon Martin wrote: 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.
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@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
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@monmotha.net <mailto:lists.nanog@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
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@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@monmotha.net <mailto:lists.nanog@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
" 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@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@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@monmotha.net <mailto:lists.nanog@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
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 <jmh@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
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@monmotha.net <mailto:lists.nanog@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
On 6/7/2020 2:28 PM, Etienne-Victor Depasquale wrote: 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
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 <baldur.norddahl@gmail.com> 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 <jmh@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
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@monmotha.net <mailto:lists.nanog@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
On 6/7/2020 2:28 PM, Etienne-Victor Depasquale wrote: 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
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 <baldur.norddahl@gmail.com> 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 <jmh@joelhalpern.com<mailto:jmh@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 <lists.nanog@monmotha.net<mailto:lists.nanog@monmotha.net> <mailto:lists.nanog@monmotha.net<mailto:lists.nanog@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
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
On Sun, Jun 7, 2020 at 3:01 AM Denys Fedoryshchenko <nuclearcat@nuclearcat.com> 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 bill@herrin.us https://bill.herrin.us/
On Sunday, 7 June, 2020 21:49, William Herrin <bill@herrin.us> 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.
Daniel Sterling <sterling.daniel@gmail.com> 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
On Sun, Jun 7, 2020 at 7:17 AM Bjørn Mork <bjorn@mork.no> 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
On Sun, Jun 7, 2020 at 2:00 AM Fred Baker <fredbakersba@gmail.com> 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
participants (11)
-
Baldur Norddahl -
Bjørn Mork -
Brandon Martin -
Daniel Sterling -
Denys Fedoryshchenko -
Etienne-Victor Depasquale -
Harald Koch -
Joel Halpern -
Keith Medcalf -
Pascal Thubert (pthubert) -
William Herrin