Hi Folks, (Sorry for the long post. Please delete now if you're not interested in IPv6 adoption.) In a recent Security Now! podcast host Steve Gibson reported on a blog post by APNIC Labs about the state of IPv6 adoption. I hope this isn't considered off-topic here, after all, it affects all of us. While my work environment is dual-stack, my home network is still IPv4 only, and it may stay that way for as long as I'm around. APNIC Labs is a research division of the Asia Pacific Network Information Centre (APNIC), focused on internet infrastructure and operational research, so they should know what they're talking about. They have developed a method to measure IPv6 compatibility from the user's perspective. Their measurements show that after more than 25 years of IPv6 only 41% of users are IPv6 enabled, on a global basis. They show a trend line where if the adoption rate is linear 100% will be reached about the year 2045. Yet they show that the adoption rate for the US hit about 51% in 2019 but has remain flat since then! (this is being written in Nov 2024) They note that the main driver for IPv6 was address starvation on v4. While v4 offers about 3,000,000,000 net address, there are currently about 20,000,000,000 devices on the Internet. Two technologies have enabled this Internet growth: NAT and SNI. NAT (Network Address Translation) allows IPv4 client address space to expand from 32-bits to 48-bits. SNI (Server Name Indication) is an extension to the TLS (Transport Layer Security) protocol that allows multiple SSL/TLS certificates to be associated with one IP address. So these two technologies have basically infinitely increased the effective address space of IPv4. So what is to be gained from IPv6 adoption? From my perspective it increases complexity while reducing security and reliability. This all implies that IPv4 will always be with us. IPv6 will increase globally to some point, but will level off as it has in the US. This of course is anathema to IP purists who claim that the Internet was designed on the principle that every device has a globally unique address. But in reality, is this really necessary? The point is made that DNS has replaced the router for presentation of web content. Interesting. Link to Security Now! podcast show notes. IPv6 notes begin on page 13. https://www.grc.com/sn/sn-998-notes.pdf Here's a video of the podcast starting at the IPv6 part: https://youtu.be/PuqbdXGucH8 Regards, Lew
On 11/10/24 13:11, Lew Wolfgang wrote:
So what is to be gained from IPv6 adoption? From my perspective it increases complexity while reducing security and reliability.
Seems to me, the use of NAT, STUN, etc. increases complexity and problems. NAT breaks things. The first I was aware of was command line FTP, back in the dark ages, when it became necessary to use passive mode to get through NAT. In those days, most FTP clients didn't support it. These days, it breaks VoIP and games, requiring the use of STUN. It also breaks authentication headers in IPSec. There may be other things I'm not aware of. SLI requires deep packet inspection, to determine what the destination is. This is not supposed to be a function of routers. Why do you think it reduces security and reliability? Seems to me it's the opposite with hack upon hack needed to get around the address shortage.
This of course is anathema to IP purists who claim that the Internet was designed on the principle that every device has a globally unique address. But in reality, is this really necessary?
Actually, yes. Look at the cell network for just one example. IPv6 is mandatory on 4G and 5G. This is because they use VoIP (VoLTE and VoNR are VoIP adapted to the cell network) and there are not enough IPv4 addresses for every mobile device, let alone anything else. My phone is IPv6 only and uses 464XLAT to connect to IPv4 only sites. I have had IPv6 on my home network for over 14 years. One nice thing is I can make any IPv6 device directly accessible, firewall rules permitting, just as the network gods intended the Internet should work. Also, things like NAT & SLI put more of a load on routers. Incidentally, some carriers moved to IPv6 because there weren't enough IPv4 addresses to create a flat network. This creates network management problems. There are also things, such as fixed length headers, that improve router performance. Also, elimination of broadcasts, in favour of multicasts reduces LAN noise. The equivalent to a broadcast is an all nodes multicast, which is used only when necessary. By using multicasts, only the intended destinations have to receive the packet. With broadcasts, every device has to receive the packet, whether for it or not. Seems to me the real problem is inertia, ignorance and head in the sand stupidity! I have heard plenty claiming they should have extended IPv4, when the real solution is to move to IPv6. Vint Cerf, one of the creators of IP had said IPv4 was only intended to be a proof of concept and intended the release version to have a much bigger address space. Unfortunately, IPv4 "escaped". Incidentally, I first learned the details of IPv4 back in 1995, when I took some classes at a local college. One thing I recognized immediately, as I was sitting in the class, was the inadequate address range. Maybe this was because I come from a telecom background where such things are important. Imagine having to use something like NAT when you make a phone call! Why not give it a try? You may have to unlearn a few bad habits, but in the long run you'll be better off for it. It's not hard.
On 11/10/24 11:08, James Knott wrote:
On 11/10/24 13:11, Lew Wolfgang wrote:
So what is to be gained from IPv6 adoption? From my perspective it increases complexity while reducing security and reliability.
Seems to me, the use of NAT, STUN, etc. increases complexity and problems. NAT breaks things. The first I was aware of was command line FTP, back in the dark ages, when it became necessary to use passive mode to get through NAT. In those days, most FTP clients didn't support it. These days, it breaks VoIP and games, requiring the use of STUN. It also breaks authentication headers in IPSec. There may be other things I'm not aware of.
Sorry I'm late to reply. I don't know about VoIP, but Zoom, Teams, Signal, and others work quite well on NAT subnets. Regarding IPSec, I'm using an Aruba Remote Access Point (RAP) to connect to my employer's network. It's sort of like a hardware VPN. I think it uses IPSec, and it works fine on my IPv4 NAT subnet.
SLI requires deep packet inspection, to determine what the destination is. This is not supposed to be a function of routers.
I don't think that SLI requires deep packet inspection. The destination IP is right there where it should be. The server hostname parsing would be done at the destination, not at routing nodes. With SNI, DNS serves sort of like the router.
Why do you think it reduces security and reliability? Seems to me it's the opposite with hack upon hack needed to get around the address shortage.
IPv6 is certainly less reliable than v4 in my employer's dual-stacked network. Identical hosts running Leap will sometimes not discover their v6 addresses. I've had to configure our ssh servers to listen only on v4, otherwise connection attempts would freeze waiting for a v6 connection. Then there's the problem of rogue routers.
This of course is anathema to IP purists who claim that the Internet was designed on the principle that every device has a globally unique address. But in reality, is this really necessary?
Actually, yes. Look at the cell network for just one example. IPv6 is mandatory on 4G and 5G. This is because they use VoIP (VoLTE and VoNR are VoIP adapted to the cell network) and there are not enough IPv4 addresses for every mobile device, let alone anything else. My phone is IPv6 only and uses 464XLAT to connect to IPv4 only sites.
My phone has v4 and v6 addresses, the v4 is on a carrier-grade NAT.
I have had IPv6 on my home network for over 14 years. One nice thing is I can make any IPv6 device directly accessible, firewall rules permitting, just as the network gods intended the Internet should work.
I remember getting compromised twice with hosts directly connected to the Internet. One was an ssh v1.2 bug, the other a mountd bug. Now I use a router-based firewall, NAT, and host-based firewalls.
Also, things like NAT & SLI put more of a load on routers. Incidentally, some carriers moved to IPv6 because there weren't enough IPv4 addresses to create a flat network. This creates network management problems.
Carrier NAT also solves the address starvation problem for carriers.
There are also things, such as fixed length headers, that improve router performance. Also, elimination of broadcasts, in favour of multicasts reduces LAN noise. The equivalent to a broadcast is an all nodes multicast, which is used only when necessary. By using multicasts, only the intended destinations have to receive the packet. With broadcasts, every device has to receive the packet, whether for it or not.
Seems to me the real problem is inertia, ignorance and head in the sand stupidity! I have heard plenty claiming they should have extended IPv4, when the real solution is to move to IPv6. Vint Cerf, one of the creators of IP had said IPv4 was only intended to be a proof of concept and intended the release version to have a much bigger address space. Unfortunately, IPv4 "escaped".
Incidentally, I first learned the details of IPv4 back in 1995, when I took some classes at a local college. One thing I recognized immediately, as I was sitting in the class, was the inadequate address range. Maybe this was because I come from a telecom background where such things are important. Imagine having to use something like NAT when you make a phone call!
Why not give it a try? You may have to unlearn a few bad habits, but in the long run you'll be better off for it. It's not hard.
I did try. You might recall my problems with it a few years ago. I couldn't make it work with Cox and my Zyxel router/firewall. I gave up, especially since there was no clear advantage to v6, while having the disadvantage of more complex firewalling. The basic theme of the podcast was that the core mission for v6, increased address space, was achieved by CIDR, NAT and SNI on v4 while everyone was waiting for v6. Now, there may not be any practical reason to go v6. Regards, Lew
On 2024-11-12 07:24, Lew Wolfgang wrote:
On 11/10/24 11:08, James Knott wrote:
On 11/10/24 13:11, Lew Wolfgang wrote:
So what is to be gained from IPv6 adoption? From my perspective it increases complexity while reducing security and reliability.
Seems to me, the use of NAT, STUN, etc. increases complexity and problems. NAT breaks things. The first I was aware of was command line FTP, back in the dark ages, when it became necessary to use passive mode to get through NAT. In those days, most FTP clients didn't support it. These days, it breaks VoIP and games, requiring the use of STUN. It also breaks authentication headers in IPSec. There may be other things I'm not aware of.
Sorry I'm late to reply. I don't know about VoIP, but Zoom, Teams, Signal, and others work quite well on NAT subnets.
Define well. All of those systems use an intermediary. You can not do a direct connection with full privacy. ...
I have had IPv6 on my home network for over 14 years. One nice thing is I can make any IPv6 device directly accessible, firewall rules permitting, just as the network gods intended the Internet should work.
I remember getting compromised twice with hosts directly connected to the Internet. One was an ssh v1.2 bug, the other a mountd bug. Now I use a router-based firewall, NAT, and host-based firewalls.
Also, things like NAT & SLI put more of a load on routers. Incidentally, some carriers moved to IPv6 because there weren't enough IPv4 addresses to create a flat network. This creates network management problems.
Carrier NAT also solves the address starvation problem for carriers.
Define "solve". I can not ssh to locations using CGNAT. ... -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 11/12/24 04:05, Carlos E. R. wrote:
On 2024-11-12 07:24, Lew Wolfgang wrote:
On 11/10/24 11:08, James Knott wrote:
On 11/10/24 13:11, Lew Wolfgang wrote:
So what is to be gained from IPv6 adoption? From my perspective it increases complexity while reducing security and reliability.
Seems to me, the use of NAT, STUN, etc. increases complexity and problems. NAT breaks things. The first I was aware of was command line FTP, back in the dark ages, when it became necessary to use passive mode to get through NAT. In those days, most FTP clients didn't support it. These days, it breaks VoIP and games, requiring the use of STUN. It also breaks authentication headers in IPSec. There may be other things I'm not aware of.
Sorry I'm late to reply. I don't know about VoIP, but Zoom, Teams, Signal, and others work quite well on NAT subnets.
Define well.
Works for 99% of users.
All of those systems use an intermediary. You can not do a direct connection with full privacy.
That's why you use encryption. If you are sophisticated enough to require arbitrary direct connections you can set up a cloud relay point. That's what I do, although my need for point-to-point has gone away.
I have had IPv6 on my home network for over 14 years. One nice thing is I can make any IPv6 device directly accessible, firewall rules permitting, just as the network gods intended the Internet should work.
I remember getting compromised twice with hosts directly connected to the Internet. One was an ssh v1.2 bug, the other a mountd bug. Now I use a router-based firewall, NAT, and host-based firewalls.
Also, things like NAT & SLI put more of a load on routers. Incidentally, some carriers moved to IPv6 because there weren't enough IPv4 addresses to create a flat network. This creates network management problems.
Carrier NAT also solves the address starvation problem for carriers.
Define "solve".
Regular NAT gives basically 48-bits of addressing. Then, you can put NATs in series to effectively give you unlimited addresses. Indeed, right here at Wolfgang Manor I have two NATs in series. My phone can send and receive encrypted WiFi calls while sitting behind behind two NAT's on two separate routers. The WAN router interface has a straight IPv4 address. So NAT solves my requirements, which are probably more complicated than most routine use cases. Yes, it requires an external intermediary, but I don't care since all traffic is encrypted.
I can not ssh to locations using CGNAT.
Then you're in the 1% of use cases. You've certainly got the skills to set up a cloud intermediary of your own and configure your endpoints to be mutually connected using nothing but IPv4. Indeed, I did it once years ago to provide an always-on ssh connection from California to a location in the South Pacific using an AT&T cell modem which was on CGNAT. The point of the referenced article is that the adoption rate for v6 is very slow, and that it's possible that v4 and v6 will coexist on a permanent basis, forever. Regards, Lew
On 2024-11-12 16:03, Lew Wolfgang wrote:
On 11/12/24 04:05, Carlos E. R. wrote:
On 2024-11-12 07:24, Lew Wolfgang wrote:
On 11/10/24 11:08, James Knott wrote:
On 11/10/24 13:11, Lew Wolfgang wrote:
So what is to be gained from IPv6 adoption? From my perspective it increases complexity while reducing security and reliability.
Seems to me, the use of NAT, STUN, etc. increases complexity and problems. NAT breaks things. The first I was aware of was command line FTP, back in the dark ages, when it became necessary to use passive mode to get through NAT. In those days, most FTP clients didn't support it. These days, it breaks VoIP and games, requiring the use of STUN. It also breaks authentication headers in IPSec. There may be other things I'm not aware of.
Sorry I'm late to reply. I don't know about VoIP, but Zoom, Teams, Signal, and others work quite well on NAT subnets.
Define well.
Works for 99% of users.
All of those systems use an intermediary. You can not do a direct connection with full privacy.
That's why you use encryption. If you are sophisticated enough to require arbitrary direct connections you can set up a cloud relay point. That's what I do, although my need for point-to-point has gone away.
The intermediary gets to know every connection you make. Encryption doesn't solve this.
I have had IPv6 on my home network for over 14 years. One nice thing is I can make any IPv6 device directly accessible, firewall rules permitting, just as the network gods intended the Internet should work.
I remember getting compromised twice with hosts directly connected to the Internet. One was an ssh v1.2 bug, the other a mountd bug. Now I use a router-based firewall, NAT, and host-based firewalls.
Also, things like NAT & SLI put more of a load on routers. Incidentally, some carriers moved to IPv6 because there weren't enough IPv4 addresses to create a flat network. This creates network management problems.
Carrier NAT also solves the address starvation problem for carriers.
Define "solve".
Regular NAT gives basically 48-bits of addressing. Then, you can put NATs in series to effectively give you unlimited addresses. Indeed, right here at Wolfgang Manor I have two NATs in series. My phone can send and receive encrypted WiFi calls while sitting behind behind two NAT's on two separate routers. The WAN router interface has a straight IPv4 address. So NAT solves my requirements, which are probably more complicated than most routine use cases.
Yes, it requires an external intermediary, but I don't care since all traffic is encrypted.
I can not ssh to locations using CGNAT.
Then you're in the 1% of use cases. You've certainly got the skills to set up a cloud intermediary of your own and configure your endpoints to be mutually connected using nothing but IPv4. Indeed, I did it once years ago to provide an always-on ssh connection from California to a location in the South Pacific using an AT&T cell modem which was on CGNAT.
Or use IPv6 and forget all those tricks.
The point of the referenced article is that the adoption rate for v6 is very slow, and that it's possible that v4 and v6 will coexist on a permanent basis, forever.
It is very slow in the USA. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 11/12/24 10:03, Carlos E. R. wrote:
On 2024-11-12 16:03, Lew Wolfgang wrote:
On 11/12/24 04:05, Carlos E. R. wrote:
On 2024-11-12 07:24, Lew Wolfgang wrote:
On 11/10/24 11:08, James Knott wrote:
On 11/10/24 13:11, Lew Wolfgang wrote:
So what is to be gained from IPv6 adoption? From my perspective it increases complexity while reducing security and reliability.
Seems to me, the use of NAT, STUN, etc. increases complexity and problems. NAT breaks things. The first I was aware of was command line FTP, back in the dark ages, when it became necessary to use passive mode to get through NAT. In those days, most FTP clients didn't support it. These days, it breaks VoIP and games, requiring the use of STUN. It also breaks authentication headers in IPSec. There may be other things I'm not aware of.
Sorry I'm late to reply. I don't know about VoIP, but Zoom, Teams, Signal, and others work quite well on NAT subnets.
Define well.
Works for 99% of users.
All of those systems use an intermediary. You can not do a direct connection with full privacy.
That's why you use encryption. If you are sophisticated enough to require arbitrary direct connections you can set up a cloud relay point. That's what I do, although my need for point-to-point has gone away.
The intermediary gets to know every connection you make. Encryption doesn't solve this.
Yes, and intermediate routers and taps get to know every direct connection you make with IPv6. Unless you use TOR. BTW, I heard that Signal is coming out with messaging that will use their TNO encryption over a TOR network.
I have had IPv6 on my home network for over 14 years. One nice thing is I can make any IPv6 device directly accessible, firewall rules permitting, just as the network gods intended the Internet should work.
I remember getting compromised twice with hosts directly connected to the Internet. One was an ssh v1.2 bug, the other a mountd bug. Now I use a router-based firewall, NAT, and host-based firewalls.
Also, things like NAT & SLI put more of a load on routers. Incidentally, some carriers moved to IPv6 because there weren't enough IPv4 addresses to create a flat network. This creates network management problems.
Carrier NAT also solves the address starvation problem for carriers.
Define "solve".
Regular NAT gives basically 48-bits of addressing. Then, you can put NATs in series to effectively give you unlimited addresses. Indeed, right here at Wolfgang Manor I have two NATs in series. My phone can send and receive encrypted WiFi calls while sitting behind behind two NAT's on two separate routers. The WAN router interface has a straight IPv4 address. So NAT solves my requirements, which are probably more complicated than most routine use cases.
Yes, it requires an external intermediary, but I don't care since all traffic is encrypted.
I can not ssh to locations using CGNAT.
Then you're in the 1% of use cases. You've certainly got the skills to set up a cloud intermediary of your own and configure your endpoints to be mutually connected using nothing but IPv4. Indeed, I did it once years ago to provide an always-on ssh connection from California to a location in the South Pacific using an AT&T cell modem which was on CGNAT.
Or use IPv6 and forget all those tricks.
IPv6 wasn't available end-to-end at that time in this case.
The point of the referenced article is that the adoption rate for v6 is very slow, and that it's possible that v4 and v6 will coexist on a permanent basis, forever.
It is very slow in the USA.
Yes, because CIDR, NAT, and SNI work so well. US v6 adoption has been flat at 52% for more than five years. This kind of matches the data published on Internet Society’s Pulse that reports that only 47% of the top 1,000websites are reachable over IPv6. 100% are reachable over IPv4. Regards, Lew
On 2024-11-13 02:03, Lew Wolfgang wrote:
On 11/12/24 16:41, Carlos E. R. via openSUSE Users wrote:
On 2024-11-12 21:22, Lew Wolfgang wrote:
100% are reachable over IPv4.
Not true...
Are you saying that some of the top 1000 web sites aren't reachable via IPv4? That would be interesting.
Depends on what you visit. And what countries you visit. https://clintonwhitehouse1.archives.gov/ https://clintonwhitehouse2.archives.gov/ 42.be dnslabs.nl geschwindigkeitstester.de loopsofzen.uk game.flyingpenguintech.org k6usy.net www.bottlecaps.de www.slave-auctions.net www.v6.facebook.com www.frontarmy.co.uk https://memegrid.org (also .com and .net) https://www.dagon-1.net -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 11/13/24 03:51, Carlos E. R. wrote:
On 2024-11-13 02:03, Lew Wolfgang wrote:
On 11/12/24 16:41, Carlos E. R. via openSUSE Users wrote:
On 2024-11-12 21:22, Lew Wolfgang wrote:
100% are reachable over IPv4.
Not true...
Are you saying that some of the top 1000 web sites aren't reachable via IPv4? That would be interesting.
Depends on what you visit. And what countries you visit.
https://clintonwhitehouse1.archives.gov/
https://clintonwhitehouse2.archives.gov/
42.be
dnslabs.nl
geschwindigkeitstester.de
loopsofzen.uk
game.flyingpenguintech.org
k6usy.net
www.bottlecaps.de
www.slave-auctions.net
www.v6.facebook.com
www.frontarmy.co.uk
https://memegrid.org (also .com and .net)
That is interesting. But these examples are hardly in the top 1,000 global web sites. I wonder if their not supporting v4 is a conscious decision, or just incompetence? Note that the Clinton links are hosted on archive.gov, which does listen on v4. They're also not reachable on a v6-enabled network either. Go figure... Regards, Lew
On Wed, 13 Nov 2024 07:26:06 -0800 Lew Wolfgang <wolfgang@sweet-haven.com> wrote:
On 11/13/24 03:51, Carlos E. R. wrote:
On 2024-11-13 02:03, Lew Wolfgang wrote:
On 11/12/24 16:41, Carlos E. R. via openSUSE Users wrote:
On 2024-11-12 21:22, Lew Wolfgang wrote:
100% are reachable over IPv4.
Not true...
Are you saying that some of the top 1000 web sites aren't reachable via IPv4? That would be interesting.
Depends on what you visit. And what countries you visit.
https://clintonwhitehouse1.archives.gov/
https://clintonwhitehouse2.archives.gov/
42.be
dnslabs.nl
geschwindigkeitstester.de
loopsofzen.uk
game.flyingpenguintech.org
k6usy.net
www.bottlecaps.de
www.slave-auctions.net
www.v6.facebook.com
www.frontarmy.co.uk
https://memegrid.org (also .com and .net)
That is interesting. But these examples are hardly in the top 1,000 global web sites. I wonder if their not supporting v4 is a conscious decision, or just incompetence?
Note that the Clinton links are hosted on archive.gov, which does listen on v4. They're also not reachable on a v6-enabled network either. Go figure...
(nitpick: it's archives.gov) and version 3 is available on IPv4 so it looks like a simple configuration error, rather than some evil plot.
Regards, Lew
On 2024-11-13 17:05, Dave Howorth wrote:
On Wed, 13 Nov 2024 07:26:06 -0800 Lew Wolfgang <...> wrote:
On 11/13/24 03:51, Carlos E. R. wrote:
On 2024-11-13 02:03, Lew Wolfgang wrote:
On 11/12/24 16:41, Carlos E. R. via openSUSE Users wrote:
On 2024-11-12 21:22, Lew Wolfgang wrote:
100% are reachable over IPv4.
Not true...
Are you saying that some of the top 1000 web sites aren't reachable via IPv4? That would be interesting.
Depends on what you visit. And what countries you visit.
https://clintonwhitehouse1.archives.gov/
https://clintonwhitehouse2.archives.gov/
42.be
dnslabs.nl
geschwindigkeitstester.de
loopsofzen.uk
game.flyingpenguintech.org
k6usy.net
www.bottlecaps.de
www.slave-auctions.net
www.v6.facebook.com
www.frontarmy.co.uk
https://memegrid.org (also .com and .net)
That is interesting. But these examples are hardly in the top 1,000 global web sites. I wonder if their not supporting v4 is a conscious decision, or just incompetence?
Some sites are on IPv6 only simply because they don't have IPv4 available. Some countries do not have IPv4 at all. The USA is very privileged.
Note that the Clinton links are hosted on archive.gov, which does listen on v4. They're also not reachable on a v6-enabled network either. Go figure...
(nitpick: it's archives.gov) and version 3 is available on IPv4 so it looks like a simple configuration error, rather than some evil plot.
As I don't have IPv6, I simply had to google the question :-) -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 11/12/24 10:03, Lew Wolfgang wrote:
Works for 99% of users.
Only because those are client/server systems. As long as the server is there, NAT's not a problem.
Regular NAT gives basically 48-bits of addressing. Then, you can put NATs in series to effectively give you unlimited addresses.
NAT on NAT!!! ARGHHH!!!! That's double breaking things. Also, it's not unlimited addresses. It's limited by the number of available TCP or UDP ports.
Then you're in the 1% of use cases.
That's anyone who wants to set up a VPN to their home network, when they're behind CGNAT.
James, et al -- ...and then James Knott said... % On 11/12/24 10:03, Lew Wolfgang wrote: % ... % > Then you're in the 1% of use cases. % % That's anyone who wants to set up a VPN to their home network, when they're % behind CGNAT. /me raises hand :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt
On 11/12/24 16:54, David T-G wrote:
James, et al --
...and then James Knott said... % On 11/12/24 10:03, Lew Wolfgang wrote: % ... % > Then you're in the 1% of use cases. % % That's anyone who wants to set up a VPN to their home network, when they're % behind CGNAT.
/me raises hand
We always knew that you were one of the one-percenters, David! 😉 Regards, Lew
On 11/12/24 01:24, Lew Wolfgang wrote:
IPv6 is certainly less reliable than v4 in my employer's dual-stacked network. Identical hosts running Leap will sometimes not discover their v6 addresses. I've had to configure our ssh servers to listen only on v4, otherwise connection attempts would freeze waiting for a v6 connection.
You may have other issues.
Then there's the problem of rogue routers.
If you're really worried about security, then you need to watch network traffic. Every router will advertise itself.
My phone has v4 and v6 addresses, the v4 is on a carrier-grade NAT.
Is your phone's IPv4 address something like 192.0.0.2? If so you're using 464XLAT. Either way, some form of NAT is still being used.
CIDR, NAT and SNI on v4
You're still using hacks. Also, even CIDR won't provide enough addresses. It's impossible to connect all the world's devices into the IPv4 address space without using hacks and even hacks on hacks. Those hacks add complexity, reliability and security issues.
On 11/12/24 05:38, James Knott wrote:
On 11/12/24 01:24, Lew Wolfgang wrote:
IPv6 is certainly less reliable than v4 in my employer's dual-stacked network. Identical hosts running Leap will sometimes not discover their v6 addresses. I've had to configure our ssh servers to listen only on v4, otherwise connection attempts would freeze waiting for a v6 connection.
You may have other issues.
True.
Then there's the problem of rogue routers.
If you're really worried about security, then you need to watch network traffic. Every router will advertise itself.
Yes, routers advertise themselves in v6. We had one spate of problems where Windows users could accidentally set up their boxes to issue RA's to a dead interface. Sure, a rogue DHCP server could be set up on v4, but not accidentally.
My phone has v4 and v6 addresses, the v4 is on a carrier-grade NAT.
Is your phone's IPv4 address something like 192.0.0.2? If so you're using 464XLAT. Either way, some form of NAT is still being used.
No, it's using 100.64.0.0/10 when not connected to my local NATed WiFi.
CIDR, NAT and SNI on v4
You're still using hacks. Also, even CIDR won't provide enough addresses. It's impossible to connect all the world's devices into the IPv4 address space without using hacks and even hacks on hacks. Those hacks add complexity, reliability and security issues.
But the hacks work. And aren't even hacks if you drop the requirement that all devices can directly reach every other device. That requirement was reasonable when TCP/IP was invented, but why is it needed now on a global basis? CIDR can't supply all needed addresses, true. It can provide something like 3,000,000,000 unique addresses net. Yet there are estimated to be 20,000.000.000 devices currently connected. Sure, some of those are IPv6, but I bet many more are IPv4 NATed. I've got about 20 devices here hiding behind one v4 address, and don't have any issues with our use cases. Regards, Lew
On 11/12/24 10:49, Lew Wolfgang wrote:
Yes, routers advertise themselves in v6. We had one spate of problems where Windows users could accidentally set up their boxes to issue RA's to a dead interface. Sure, a rogue DHCP server could be set up on v4, but not accidentally.
How does one "accidentally" send out RAs, without also "accidentally" setting up a router? That would be even more difficult to do in Windows than Linux.
No, it's using 100.64.0.0/10 when not connected to my local NATed WiFi.
Then they are just using NAT, instead of some transition mechanism such as 464XLAT. That block is allocated to carrier grade NAT.
CIDR can't supply all needed addresses, true. It can provide something like 3,000,000,000 unique addresses net. Yet there are estimated to be 20,000.000.000 devices currently connected. Sure, some of those are IPv6, but I bet many more are IPv4 NATed. I've got about 20 devices here hiding behind one v4 address, and don't have any issues with our use cases.
As I mentioned, IPv6 is mandatory on 4G & 5G. The carriers can optionally provide IPv4, as yours does. Incidentally, when I tether to my cell phone, I get a public IPv6 address along with NAT IPv4.
On 11/12/24 11:05, James Knott wrote:
On 11/12/24 10:49, Lew Wolfgang wrote:
Yes, routers advertise themselves in v6. We had one spate of problems where Windows users could accidentally set up their boxes to issue RA's to a dead interface. Sure, a rogue DHCP server could be set up on v4, but not accidentally.
How does one "accidentally" send out RAs, without also "accidentally" setting up a router? That would be even more difficult to do in Windows than Linux.
Windows users were, at the time, able to configure a network parameter that would basically set up a backdoor network that in most cases wasn't connected to anything. I don't remember the exact "feature". Net result was that IPv6 traffic was enticed to flow to this rogue router and fall into the bit bucket. It was a real pain to diagnose and find out which computer out of thousands was the cause. So it was accidental, the users didn't do this intentionally, most of the time.
No, it's using 100.64.0.0/10 when not connected to my local NATed WiFi.
Then they are just using NAT, instead of some transition mechanism such as 464XLAT. That block is allocated to carrier grade NAT.
Yes.
CIDR can't supply all needed addresses, true. It can provide something like 3,000,000,000 unique addresses net. Yet there are estimated to be 20,000.000.000 devices currently connected. Sure, some of those are IPv6, but I bet many more are IPv4 NATed. I've got about 20 devices here hiding behind one v4 address, and don't have any issues with our use cases.
As I mentioned, IPv6 is mandatory on 4G & 5G. The carriers can optionally provide IPv4, as yours does.
Maybe they had to provide v4 since only half of web sites, even now, don't answer to v6?
Incidentally, when I tether to my cell phone, I get a public IPv6 address along with NAT IPv4.
I haven't used my Pixel for tethering yet, I'll have to play around with it sometime. Regards, Lew
On 11/12/24 15:14, Lew Wolfgang wrote:
Windows users were, at the time, able to configure a network parameter that would basically set up a backdoor network that in most cases wasn't connected to anything. I don't remember the exact "feature". Net result was that IPv6 traffic was enticed to flow to this rogue router and fall into the bit bucket. It was a real pain to diagnose and find out which computer out of thousands was the cause. So it was accidental, the users didn't do this intentionally, most of the time.
I think I know what you're referring to, but I've also forgotten what it's called. It was a local connection that used link local addresses. Since it use link local, it was not routeable.
On 11/12/24 01:24, Lew Wolfgang wrote:
Sorry I'm late to reply. I don't know about VoIP, but Zoom, Teams, Signal, and others work quite well on NAT subnets. Regarding IPSec, I'm using an Aruba Remote Access Point (RAP) to connect to my employer's network. It's sort of like a hardware VPN. I think it uses IPSec, and it works fine on my IPv4 NAT subnet.
VoIP requires a public address. STUN is used to fudge that with NAT. On the other hand, Zoom, etc. work with a server, which is the only part that requires a public address. It isn't all of IPSec that breaks, only authentication headers, which verify the headers haven't been tampered with. NAT, by design, tampers with the headers.
I don't think that SLI requires deep packet inspection. The destination IP is right there where it should be. The server hostname parsing would be done at the destination, not at routing nodes. With SNI, DNS serves sort of like the router.
What about carrier grade NAT? Those routers are not at the destination, but would still have to do SLI, if it's to work. Also, on large networks, the router and firewall are often separate boxes.
On 11/12/24 06:19, James Knott wrote:
I don't think that SLI requires deep packet inspection. The destination IP is right there where it should be. The server hostname parsing would be done at the destination, not at routing nodes. With SNI, DNS serves sort of like the router.
What about carrier grade NAT? Those routers are not at the destination, but would still have to do SLI, if it's to work. Also, on large networks, the router and firewall are often separate boxes.
From my understanding SNI allows a single server at a single IPv4 address to support multiple TLS connections to different name spaces on that one server. Assume one server supports foobar.com and blast.org. and has configured their authoritative DNS to return one IP address for either domain name. Thus, if the client wants to go to foobar.com his DNS returns one address and the name foobar.com is embedded in the TLS handshake. The server then unpacks the TLS dialog and sends the request to the server app serviceing foobar.com. If she wants to got to blast.org, DNS will return the same IP address as foobar.com, but embed blast.org. Thus, routers along the way only have to concern themselves with the one IP address. Thus, the "routing" function is handled by DNS instead of routing tables in individual routers. Regards, Lew
On 11/12/24 15:21, Lew Wolfgang wrote:
Thus, the "routing" function is handled by DNS instead of routing tables in individual routers.
The routing is done by the router, after it examines the specific field in the http header. This means it has to go into the packet, into the http header, read the destination and then forward accordingly. A DNS server cannot do that, as all it does is hand out an address for the given names. It requires a lookup table on the router, to match a name with an address.
On 11/12/24 13:23, James Knott wrote:
On 11/12/24 15:21, Lew Wolfgang wrote:
Thus, the "routing" function is handled by DNS instead of routing tables in individual routers.
The routing is done by the router, after it examines the specific field in the http header. This means it has to go into the packet, into the http header, read the destination and then forward accordingly. A DNS server cannot do that, as all it does is hand out an address for the given names. It requires a lookup table on the router, to match a name with an address.
I don't think I was being clear enough. With SNI the DNS system functions sort of as a router in the Internet as it has developed. Permit me to include below part of the write up by GeoffHuston, Chief Scientist at APNIC. Regards, Lew It’s domain names that operate as service identifiers, and its domain names that underpin the user tests of authenticity of the online service. It’s the DNS that increasingly is used to steer users to the ‘best’ service delivery point for content or service. From this perspective addresses, IPv4 or IPv6, are not the critical resource for a service and its users. The ‘currency’ of this form of CDN network is names. So where are we in 2024? Today’s public Internet is largely a service delivery network using CDNs to push content and service as close to the user as possible. The multiplexing of multiple services onto underlying service platforms is an application-level function tied largely to TLS and service selection using the SNI field of the TLS handshake. We use DNS for ‘closest match’ service platform selection, aiming for CDNs to connect directly to the access networks where users are located. This results in a CDN’s routing table with an average path length designed to converge to just 1! From this aspect the DNS has supplanted the role of routing! While we don’t route ‘names’ on today’s Internet, it functions in a way that is largely equivalent to a named data network. – In other words, no longer addresses but names. There are a few additional implications of this architectural change for the Internet. TLS, like it or not (and there is much to criticize about the robustness of TLS), is the sole underpinning of authenticity in the Internet. DNSSEC has not gathered much momentum to date. DNSSEC is too complex, too fragile and just too slow to use for most services and their users. Some value its benefits highly enough that they are prepared to live with its shortcomings, but that’s not the case for most name holders and most users, and no amount of passionate exhortations about DNSSEC will change this! It supports the view that it’s not the mapping of a name to an IP address that’s critical. What is critical is that the named service can demonstrate that it is operated by the owner of the name. Secondly, the Routing PKI, the framework for securing information being passed in the BGP routing protocol, is really not all that useful in a network where there is no routing! The implication of these observations is that the transition to IPv6 is progressing very slowly not because this industry is chronically short-sighted. There is something else going on here. IPv6 alone is not critical to a large set of end-user service delivery environments. We’ve been able to take a 1980s address-based architecture and scale it more than a billion-fold by altering the core reliance on distinguisher tokens from addresses to names. There was no real lasting benefit in trying to leap across to just another 1980s address-based architecture – meaning IPv6 – with only a few annoying stupid differences, apart from longer addresses!
On 11/12/24 17:26, Lew Wolfgang wrote:
I don't think I was being clear enough. With SNI the DNS system functions sort of as a router in the Internet as it has developed. Permit me to include below part of the write up by GeoffHuston, Chief Scientist at APNIC.
All a DNS server does is provide an address to a host name and often a host name to an address. That's it. With SNI, the destination host name is extracted from the packet to decide what to do with the packet. This could mean deciding which virtual server to use on a physical server or, if in a router, to look up the destination. The problem with NAT is multiple devices are hiding behind a single public address. In this context, the router is using that host name to decide where to send the packet. In this instance, the DNS was used to find the public address, not to decide what to do when the packet hits the router. The router will then have to examine all incoming packets, to determine what the local destination is, using either a hosts file or local DNS. Once again, a router should not be doing that. It's supposed to route solely on the IP address. My understanding is the original purpose of SNI was the virtual server situation, not routing. Regardless, DNS has nothing to do with routing. From the article: "It’s the DNS that increasingly is used to steer users to the ‘best’ service delivery point for content or service." With large servers, such as Google, etc., the servers are distributed over an area. The DNS can be used to determine the appropriate destination server for a user, depending on their location. The steering mentioned in the article simply means providing the IP address of the nearest, or otherwise best, server. Then the routers can do their work to get their.
On 11/12/24 14:41, James Knott wrote:
On 11/12/24 17:26, Lew Wolfgang wrote:
I don't think I was being clear enough. With SNI the DNS system functions sort of as a router in the Internet as it has developed. Permit me to include below part of the write up by GeoffHuston, Chief Scientist at APNIC.
All a DNS server does is provide an address to a host name and often a host name to an address. That's it. With SNI, the destination host name is extracted from the packet to decide what to do with the packet. This could mean deciding which virtual server to use on a physical server or, if in a router, to look up the destination.
The non-natted destination server is responsible for extracting the service names. Routers only need to look at the IP addresses as usual.
The problem with NAT is multiple devices are hiding behind a single public address. In this context, the router is using that host name to decide where to send the packet. In this instance, the DNS was used to find the public address, not to decide what to do when the packet hits the router. The router will then have to examine all incoming packets, to determine what the local destination is, using either a hosts file or local DNS. Once again, a router should not be doing that. It's supposed to route solely on the IP address.
In our CDN oriented Internet, public-facing servers aren't on natted networks. It's the clients that are on natted networks. So the routers operate as usual. CIDR helps to increase the number of publicly reachable servers, SNI increases the number of applications that can be supported by the CIDR addresses, and NAT increases the number of clients that can reach the CIDR/SNI servers. All without increasing the load on routers. With IPv4 the number of available names is virtually infinite, and the number of nested natted clients is virtually infinite, the main rationale for IPv6 is then moot for this use case. If your use case requires true point-to-point, then IPv6 is your ticket.
My understanding is the original purpose of SNI was the virtual server situation, not routing. Regardless, DNS has nothing to do with routing.
From the article: "It’s the DNS that increasingly is used to steer users to the ‘best’ service delivery point for content or service."
That's the point I was trying to make.
With large servers, such as Google, etc., the servers are distributed over an area. The DNS can be used to determine the appropriate destination server for a user, depending on their location. The steering mentioned in the article simply means providing the IP address of the nearest, or otherwise best, server. Then the routers can do their work to get their.
Regards, Lew
On 11/12/24 15:21, Lew Wolfgang wrote:
From my understanding SNI allows a single server at a single IPv4 address to support multiple TLS connections to different name spaces on that one server.
Yep, one server. That's a bit different from multiple computers behind a router. If you expect a router to be able to do that, then it has to read the name in the packet. Here's the Wikipedia article on SNI: https://en.wikipedia.org/wiki/Server_Name_Indication
On 11/10/24 13:11, Lew Wolfgang wrote:
So what is to be gained from IPv6 adoption? From my perspective it increases complexity while reducing security and reliability.
Forgot to mention, some people are stuck behind carrier grade NAT. This means they haven't a hope of connecting to their own network, without using some external service. Yet another hack to get around the address shortage.
On 2024-11-10 20:22, James Knott wrote:
On 11/10/24 13:11, Lew Wolfgang wrote:
So what is to be gained from IPv6 adoption? From my perspective it increases complexity while reducing security and reliability.
Forgot to mention, some people are stuck behind carrier grade NAT. This means they haven't a hope of connecting to their own network, without using some external service. Yet another hack to get around the address shortage.
Yep. In Spain, minor providers use this system, which makes it impossible to connect to your home from outside, directly. Other minor providers switched instead to IPv6 by default. Telefónica, probably the major provider, gave IPv6 on a Beta. I had it for some time. It gleaned that some routers were not ready, for example mine: the firewall was non existent. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On Sun, 10 Nov 2024 22:38:19 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
Telefónica, probably the major provider, gave IPv6 on a Beta. I had it for some time. It gleaned that some routers were not ready, for example mine: the firewall was non existent.
Did Telefónica supply the router? Or is it a third-party item?
On 2024-11-11 13:11, Dave Howorth wrote:
On Sun, 10 Nov 2024 22:38:19 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
Telefónica, probably the major provider, gave IPv6 on a Beta. I had it for some time. It gleaned that some routers were not ready, for example mine: the firewall was non existent.
Did Telefónica supply the router? Or is it a third-party item?
Telefónica. Using a third party router is difficult because AFAIK they don't publish the specs. This is against EU law. This is, I'm sorry to say, a security issue with IPv6: the router firewall being transparent on IPv6. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On 11/11/24 10:45, Carlos E. R. wrote:
This is, I'm sorry to say, a security issue with IPv6: the router firewall being transparent on IPv6.
There's nothing to stop you from installing your own firewall behind theirs. I doesn't have to be a router. I run pfSense and I believe it can be set up in that manner. Also, with the sparse address space, it's hard for an attacker to find anything to attack.
On 2024-11-11 16:48, James Knott wrote:
On 11/11/24 10:45, Carlos E. R. wrote:
This is, I'm sorry to say, a security issue with IPv6: the router firewall being transparent on IPv6.
There's nothing to stop you from installing your own firewall behind theirs. I doesn't have to be a router. I run pfSense and I believe it can be set up in that manner. Also, with the sparse address space, it's hard for an attacker to find anything to attack.
You mean this? Telefonica-|------firewall----Switch---|--- router |-- |---- |-- |----- |-- |------ So, more hardware, and more software to configure. In any case, I might do it, but the masses of million users of Telefónica are more exposed. A computer can have its own firewall, but the printer doesn't, IoT doesn't, and they broadcast. Ok, there are millions of addresses in the LAN, but for example when you send an email that IP is known. A determined attacker wanting to attack me will find out where my printer is. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 11/12/24 07:13, Carlos E. R. wrote:
Ok, there are millions of addresses in the LAN, but for example when you send an email that IP is known. A determined attacker wanting to attack me will find out where my printer is.
You don't send an email to an IP address. You send it to an account on a server. Also, with IPv6, a LAN has a gazillion addresses (2^64 or 18.4 billion, billion).
On 2024-11-12 14:48, James Knott wrote:
On 11/12/24 07:13, Carlos E. R. wrote:
Ok, there are millions of addresses in the LAN, but for example when you send an email that IP is known. A determined attacker wanting to attack me will find out where my printer is.
You don't send an email to an IP address. You send it to an account on a server. Also, with IPv6, a LAN has a gazillion addresses (2^64 or 18.4 billion, billion).
And the server writes your home IP into the received headers. At least some servers do. This is yours: Received: from ?IPV6:2607:fea8:4c82:5900:...? ([2607:fea8:4c82:5900:...]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4de787d703bsm1997731173.108.2024.11.12.05.48.56 for <users@lists.opensuse.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Nov 2024 05:48:56 -0800 (PST) -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 11/12/24 09:25, Carlos E. R. wrote:
You don't send an email to an IP address. You send it to an account on a server. Also, with IPv6, a LAN has a gazillion addresses (2^64 or 18.4 billion, billion).
And the server writes your home IP into the received headers. At least some servers do.
Yep, but you didn't use my address to send the email. It was sent to your SMTP server, then forwarded to my ISP's server, where my email client found it.
On 2024-11-12 19:51, James Knott wrote:
On 11/12/24 09:25, Carlos E. R. wrote:
You don't send an email to an IP address. You send it to an account on a server. Also, with IPv6, a LAN has a gazillion addresses (2^64 or 18.4 billion, billion).
And the server writes your home IP into the received headers. At least some servers do.
Yep, but you didn't use my address to send the email. It was sent to your SMTP server, then forwarded to my ISP's server, where my email client found it.
The point is that the exact IP of your computer is published and can be used to target an attack. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
Le 12/11/2024 à 19:55, Carlos E. R. a écrit :
The point is that the exact IP of your computer is published and can be used to target an attack.
exactly like any old post office mail... jdd -- https://dodin.org
On Tue, 12 Nov 2024 20:00:42 +0100 "jdd@dodin.org" <jdd@dodin.org> wrote:
Le 12/11/2024 à 19:55, Carlos E. R. a écrit :
The point is that the exact IP of your computer is published and can be used to target an attack.
exactly like any old post office mail...
Indeed and in the real world there are special provisions in law to deal with attack and other offences based on using postal addresses, precisely because their public nature can be problematic. And my phone number is ex-directory because that notion exists for similar reasons. So your point strengthens Carlos' argument.
On 2024-11-12 12:55, Carlos E. R. wrote:
On 2024-11-12 19:51, James Knott wrote:
On 11/12/24 09:25, Carlos E. R. wrote:
You don't send an email to an IP address. You send it to an account on a server. Also, with IPv6, a LAN has a gazillion addresses (2^64 or 18.4 billion, billion).
And the server writes your home IP into the received headers. At least some servers do.
Yep, but you didn't use my address to send the email. It was sent to your SMTP server, then forwarded to my ISP's server, where my email client found it.
The point is that the exact IP of your computer is published and can be used to target an attack.
On this basis alone, we should all just stop connecting our computers to the internet, because everything we do can be used to target an attack.
On 11/12/24 13:55, Carlos E. R. wrote:
The point is that the exact IP of your computer is published and can be used to target an attack.
Did it use the consistent address or a privacy address? Privacy addresses only last a week. Either way, they'd still have to get through my firewall and I only allow OpenVPN in.
On 11/12/24 14:23, James Knott wrote:
On 11/12/24 13:55, Carlos E. R. wrote:
The point is that the exact IP of your computer is published and can be used to target an attack.
Did it use the consistent address or a privacy address? Privacy addresses only last a week. Either way, they'd still have to get through my firewall and I only allow OpenVPN in.
Also, I've had the same IPv4 address for a couple of years.
On 11/12/24 05:48, James Knott wrote:
On 11/12/24 07:13, Carlos E. R. wrote:
Ok, there are millions of addresses in the LAN, but for example when you send an email that IP is known. A determined attacker wanting to attack me will find out where my printer is.
You don't send an email to an IP address. You send it to an account on a server. Also, with IPv6, a LAN has a gazillion addresses (2^64 or 18.4 billion, billion).
Why do you need such a massive subnet? Security through obscurity? I'd rather have separate independent subnets with a DMZ. I don't want my light bulbs to ssh in to my desktop. I've always wondered why IPv6 is /64 by default? Seems like a waste. Regards, Lew
On 11/12/24 10:53, Lew Wolfgang wrote:
You don't send an email to an IP address. You send it to an account on a server. Also, with IPv6, a LAN has a gazillion addresses (2^64 or 18.4 billion, billion).
Why do you need such a massive subnet? Security through obscurity? I'd rather have separate independent subnets with a DMZ. I don't want my light bulbs to ssh in to my desktop.
I've always wondered why IPv6 is /64 by default? Seems like a waste.
I suspect they wanted to avoid running out of addresses in the foreseeable future (before the heat death of the universe 😉 ). The address is large enough to contain the MAC address, if desired. You may recall the old Novell Netware, which had a 16 bit network address and 48 bit host address, usually the MAC address. As for /64, it's just splitting the 128 bit IPv6 address in half.
On 11/12/24 11:09, James Knott wrote:
On 11/12/24 10:53, Lew Wolfgang wrote:
You don't send an email to an IP address. You send it to an account on a server. Also, with IPv6, a LAN has a gazillion addresses (2^64 or 18.4 billion, billion).
Why do you need such a massive subnet? Security through obscurity? I'd rather have separate independent subnets with a DMZ. I don't want my light bulbs to ssh in to my desktop.
I've always wondered why IPv6 is /64 by default? Seems like a waste.
I suspect they wanted to avoid running out of addresses in the foreseeable future (before the heat death of the universe 😉 ).
Exactly. Why carry around all those extra host bits if they'll never be used. 24 makes sense to include MAC addresses, maybe round up to 32 in an abundance of caution. But 64? Wouldn't 4.3 billion host address be sufficient with /32? Regards, Lew
On 11/12/24 15:24, Lew Wolfgang wrote:
Exactly. Why carry around all those extra host bits if they'll never be used. 24 makes sense to include MAC addresses, maybe round up to 32 in an abundance of caution. But 64? Wouldn't 4.3 billion host address be sufficient with /32?
A MAC address is 48 bits, so it has to be at least that big, as was the case with Netware. As I mentioned, 64 was likely selected as it cut the address in half. Also, with modern networks, moving bits around is trivial. One other aspect is the sparely populated, huge address space makes it extremely difficult to find something to attack, unlike with IPv4, where most addresses are occupied.
On 11/12/24 13:28, James Knott wrote:
On 11/12/24 15:24, Lew Wolfgang wrote:
Exactly. Why carry around all those extra host bits if they'll never be used. 24 makes sense to include MAC addresses, maybe round up to 32 in an abundance of caution. But 64? Wouldn't 4.3 billion host address be sufficient with /32?
A MAC address is 48 bits, so it has to be at least that big, as was the case with Netware. As I mentioned, 64 was likely selected as it cut the address in half. Also, with modern networks, moving bits around is trivial. One other aspect is the sparely populated, huge address space makes it extremely difficult to find something to attack, unlike with IPv4, where most addresses are occupied.
Of course you're correct! 48-bits in a MAC address. That makes a bit more sense. After all, /64 is a nice power of two. It's amazing, Ethernet addressing was developed in 1973. How prescient was Bob Metcalfe and his team to settle on 48-bit addressing! It's funny what one remembers. I recall sitting on the toilet at work in 1976 reading a EDN magazine article talking about how packet switched networks were the wave of the future. It was ten years later when I found myself pulling that yellow Thicknet coax around to set up our first Ethernet subnet. Now look at what we have! Regards, Lew
On 11/12/24 17:54, Lew Wolfgang wrote:
Of course you're correct!
So, what else is new? 😉
48-bits in a MAC address. That makes a bit more sense. After all, /64 is a nice power of two.
It's amazing, Ethernet addressing was developed in 1973. How prescient was Bob Metcalfe and his team to settle on 48-bit addressing! It's funny what one remembers. I recall sitting on the toilet at work in 1976 reading a EDN magazine article talking about how packet switched networks were the wave of the future. It was ten years later when I found myself pulling that yellow Thicknet coax around to set up our first Ethernet subnet. Now look at what we have!
Look up Ethernet Blue Book, to see the first official spec from 1980. However, originally, Ethernet had an 8 bit MAC address, just like ARCnet.
On 11/12/24 15:25, James Knott wrote:
On 11/12/24 17:54, Lew Wolfgang wrote:
Of course you're correct!
So, what else is new? 😉
48-bits in a MAC address. That makes a bit more sense. After all, /64 is a nice power of two.
It's amazing, Ethernet addressing was developed in 1973. How prescient was Bob Metcalfe and his team to settle on 48-bit addressing! It's funny what one remembers. I recall sitting on the toilet at work in 1976 reading a EDN magazine article talking about how packet switched networks were the wave of the future. It was ten years later when I found myself pulling that yellow Thicknet coax around to set up our first Ethernet subnet. Now look at what we have!
Look up Ethernet Blue Book, to see the first official spec from 1980. However, originally, Ethernet had an 8 bit MAC address, just like ARCnet.
I was just going by my friend ChatGPT. Regards, Lew Ethernet addressing was invented in *1973* as part of the development of Ethernet technology at Xerox PARC (Palo Alto Research Center) by Bob Metcalfe and his team. Ethernet was designed to facilitate local networking for computers and initially used a simple 48-bit addressing scheme to uniquely identify each device on a network, which remains the basis for modern Ethernet MAC (Media Access Control) addressing. The formal publication of Ethernet, including its addressing method, appeared in a 1976 paper titled /"Ethernet: Distributed Packet Switching for Local Computer Networks"/ by Metcalfe and David Boggs. Ethernet and its addressing became standardized in 1980 as part of the IEEE 802.3 standard, which formally established Ethernet technology for widespread use.
On Tue, 12 Nov 2024 18:25:20 -0500 James Knott <james.knott@jknott.net> wrote:
On 11/12/24 17:54, Lew Wolfgang wrote:
Of course you're correct!
So, what else is new? 😉
48-bits in a MAC address. That makes a bit more sense. After all, /64 is a nice power of two.
It's amazing, Ethernet addressing was developed in 1973. How prescient was Bob Metcalfe and his team to settle on 48-bit addressing! It's funny what one remembers. I recall sitting on the toilet at work in 1976 reading a EDN magazine article talking about how packet switched networks were the wave of the future. It was ten years later when I found myself pulling that yellow Thicknet coax around to set up our first Ethernet subnet. Now look at what we have!
Look up Ethernet Blue Book, to see the first official spec from 1980. However, originally, Ethernet had an 8 bit MAC address, just like ARCnet.
Hmm, both are right. But you're talking about different things. My copy of the blue book says that the destination and source data link addresses are each 6 octets in length and "A station's physical address should be distinct from the physical address of any other station on ANY Ethernet." (p21) But there were obvious physical restrictions for the number of stations that could be connected to a single coax cable of max length 500 m with bee stings at 5 m intervals. The first experimental Ethernet was a single segment that ran at 3 Mbps and had 8 bit addresses, as reported in ETHERNET: DISTRIBUTED PACKET SWITCHING FOR LOCAL COMPUTER NETWORKS. But that was just a convenient size for the first experimental rig, and they recognised that larger addresses were desirable in production.
On 11/13/24 07:08, Dave Howorth wrote:
Hmm, both are right. But you're talking about different things. My copy of the blue book says that the destination and source data link addresses are each 6 octets in length
That's in the official spec. Ethernet was originally an experiment within Xerox. At that time, it had an 8 bit MAC. In addition to ARCnet, I used to work on one other system that had an 8 bit MAC. It was a proprietary network from Rockwell Collins, which I worked on in the Air Canada reservation system, starting in early 1978,
On Wed, 13 Nov 2024 07:12:03 -0500 James Knott <james.knott@jknott.net> wrote:
On 11/13/24 07:08, Dave Howorth wrote:
Hmm, both are right. But you're talking about different things. My copy of the blue book says that the destination and source data link addresses are each 6 octets in length
That's in the official spec. Ethernet was originally an experiment within Xerox. At that time, it had an 8 bit MAC. In addition to ARCnet, I used to work on one other system that had an 8 bit MAC. It was a proprietary network from Rockwell Collins, which I worked on in the Air Canada reservation system, starting in early 1978,
He says, cutting out the bit where I explained what you were talking about :)
Lew, et al -- ...and then Lew Wolfgang said... % ... % an abundance of caution.?? But 64??? Wouldn't 4.3 billion host address be % sufficient with /32? "I see a world market for maybe seven computers." Yep. :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt
On 11/12/24 04:13, Carlos E. R. wrote:
On 2024-11-11 16:48, James Knott wrote:
On 11/11/24 10:45, Carlos E. R. wrote:
This is, I'm sorry to say, a security issue with IPv6: the router firewall being transparent on IPv6.
There's nothing to stop you from installing your own firewall behind theirs. I doesn't have to be a router. I run pfSense and I believe it can be set up in that manner. Also, with the sparse address space, it's hard for an attacker to find anything to attack.
You mean this?
Telefonica-|------firewall----Switch---|--- router |-- |---- |-- |----- |-- |------
So, more hardware, and more software to configure.
You can get a cheap firewall, and they're fun to configure. You certainly have the skills.
In any case, I might do it, but the masses of million users of Telefónica are more exposed. A computer can have its own firewall, but the printer doesn't, IoT doesn't, and they broadcast.
Ok, there are millions of addresses in the LAN, but for example when you send an email that IP is known. A determined attacker wanting to attack me will find out where my printer is.
Exactly! I'm starting to remember my problems setting up IPv6 here at Wolfgang Manor. I've got a separate NAT'ed subnet for IoT things. My scale, outside security cameras, and whatnot can be compromised and I don't really care. I couldn't set up isolated subnets with the IPv6 service I was getting from my ISP. I don't want my scale to ssh into my Leap 15.6 desktop! The router I use, a Zyxel USG40, provides four RJ-45 jacks that can be configured as four independent NAT'ed IPv4 subnets. I couldn't do this with v6. The Zyxel's WAN port is connected to my Cable Modem which has a COAX cable connecting to a fiber relay point in the street. It would be nice to have fiber to my modem, but it is what it is. I remember when we had only POTS telephone lines and a Hayes 19.2kbaud SmartModem. Regards, Lew
On 11/12/24 10:19, Lew Wolfgang wrote:
Exactly! I'm starting to remember my problems setting up IPv6 here at Wolfgang Manor. I've got a separate NAT'ed subnet for IoT things. My scale, outside security cameras, and whatnot can be compromised and I don't really care. I couldn't set up isolated subnets with the IPv6 service I was getting from my ISP. I don't want my scale to ssh into my Leap 15.6 desktop!
I'm running pfSense for my firewall/router. I have my main LAN, guest WiFi, test LAN, OpenVPN and connection to my Cisco router. All have their own NAT IPv4 subnet, as well as IPv6.
Le 11/11/2024 à 16:45, Carlos E. R. a écrit :
This is, I'm sorry to say, a security issue with IPv6: the router firewall being transparent on IPv6.
it's a feature! have your own firewall on your workstation jdd -- https://dodin.org
On 11/11/24 08:37, jdd@dodin.org wrote:
Le 11/11/2024 à 16:45, Carlos E. R. a écrit :
This is, I'm sorry to say, a security issue with IPv6: the router firewall being transparent on IPv6.
it's a feature!
have your own firewall on your workstation
What ever happened to Defense in Depth? Regards, Lew
On 11/10/24 13:11, Lew Wolfgang wrote:
So what is to be gained from IPv6 adoption? From my perspective it increases complexity while reducing security and reliability.
Incidentially, IPv4 addressing is a hack. Originally, in the demo version of IPv4, there were 256 networks with 24 bits for hosts. This obviously was not enough to be practical, so address classes were created. Then, as the Internet became popular, even that wasn't enough, so CIDR, with variable length subnets, was created. This increases the workload on routers. With IPv6, the address is split into 64 bits for the network address and 64 bits for the host address within the network.
On 2024-11-10 19:11, Lew Wolfgang wrote:
Hi Folks,
...
They have developed a method to measure IPv6 compatibility from the user's perspective. Their measurements show that after more than 25 years of IPv6 only 41% of users are IPv6 enabled, on a global basis. They show a trend line where if the adoption rate is linear 100% will be reached about the year 2045.
Yet they show that the adoption rate for the US hit about 51% in 2019 but has remain flat since then! (this is being written in Nov 2024)
The USA can survive with IpV4 because a very large spool was assigned to it. But other countries have less addresses per inhabitant that you have; some countries have not enough at all, and are IPv6 by default. ...
This all implies that IPv4 will always be with us. IPv6 will increase globally to some point, but will level off as it has in the US. This of course is anathema to IP purists who claim that the Internet was designed on the principle that every device has a globally unique address. But in reality, is this really necessary?
It allows features that were initially designed but made impossible by NAT to work again. ... -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
Am Sonntag, 10. November 2024, 22:45:59 Mitteleuropäische Normalzeit schrieb Carlos E. R.:
On 2024-11-10 19:11, Lew Wolfgang wrote:
Hi Folks,
...
They have developed a method to measure IPv6 compatibility from the user's perspective. Their measurements show that after more than 25 years of IPv6 only 41% of users are IPv6 enabled, on a global basis. They show a trend line where if the adoption rate is linear 100% will be reached about the year 2045.
Yet they show that the adoption rate for the US hit about 51% in 2019 but has remain flat since then! (this is being written in Nov 2024)
The USA can survive with IpV4 because a very large spool was assigned to it. But other countries have less addresses per inhabitant that you have; some countries have not enough at all, and are IPv6 by default.
Unfortunately, it's never been those countries that "matter" (to those countries in charge). Long time ago we did a title track in Linux-Magazin on IPv6, and I'm, somewhat sad, but mostly indifferent about having been right with our predictions, like "ipv4 will remain significant until late 20ies or mid-thirties". When introducing IPV6, the advantages were not communictated convincingly and many other mistakes were made. It fixed a problem noone had (then). Today it's different, but still the workarounds (e.g. VPN) work for most. And an IP is getting less and less important to the end user, it's more about platforms and content. I would not be surprised if the while ipv6 thingy passes by unnoticed to a whatever it will be successor. I wouldn't suggest spending much time on it, unless you have to work-wise, the investment might not pay off... 15y ago we wrote that ipv6 is "mostly a consulting, training and documentation topic" and I still think it does not bother user layers. At least it should not. Jm2c
...
This all implies that IPv4 will always be with us. IPv6 will increase globally to some point, but will level off as it has in the US. This of course is anathema to IP purists who claim that the Internet was designed on the principle that every device has a globally unique address. But in reality, is this really necessary?
It allows features that were initially designed but made impossible by NAT to work again.
...
-- Best Regards - Mit freundlichen Grüßen, Markus Feilner, Feilner IT - 20 years of open services - Digital Sustainability, Sovereignty, Sobriety Open Source Strategy, Knowledge Management, Documentation Trainings, Workshops, Coaching, Networking, Politics, Journalism https://www.feilner-it.net, 93059 Regensburg Wöhrdstr. 10, +49 170 302 7092 (+Signal) https://mastodon.cloud/@mfeilner https://mastodon.social/@FeilnerIT PGP: 40A3C306F96133067C11CFD9A958A906268C9F0A http://www.feilner-it.net/files/MFpub.asc Xing: http://www.xing.com/profile/Markus_Feilner LinkedIn: https://www.linkedin.com/in/markusfeilner @mfeilner: Mastodon, Matrix, Jabber, ... Once you see something, you can't unsee it. And once you've seen it, keeping quiet, saying nothing, becomes as political an act as speaking out. (Arundhati Roy)
On 2024-11-11 01:23, Markus Feilner wrote:
Am Sonntag, 10. November 2024, 22:45:59 Mitteleuropäische Normalzeit schrieb Carlos E. R.:
On 2024-11-10 19:11, Lew Wolfgang wrote:
Hi Folks,
...
They have developed a method to measure IPv6 compatibility from the user's perspective. Their measurements show that after more than 25 years of IPv6 only 41% of users are IPv6 enabled, on a global basis. They show a trend line where if the adoption rate is linear 100% will be reached about the year 2045.
Yet they show that the adoption rate for the US hit about 51% in 2019 but has remain flat since then! (this is being written in Nov 2024)
The USA can survive with IpV4 because a very large spool was assigned to it. But other countries have less addresses per inhabitant that you have; some countries have not enough at all, and are IPv6 by default.
Unfortunately, it's never been those countries that "matter" (to those countries in charge).
You are right, of course.
Long time ago we did a title track in Linux-Magazin on IPv6, and I'm, somewhat sad, but mostly indifferent about having been right with our predictions, like "ipv4 will remain significant until late 20ies or mid-thirties".
When introducing IPV6, the advantages were not communictated convincingly and many other mistakes were made. It fixed a problem noone had (then). Today it's different, but still the workarounds (e.g. VPN) work for most. And an IP is getting less and less important to the end user, it's more about platforms and content.
I would not be surprised if the while ipv6 thingy passes by unnoticed to a whatever it will be successor. I wouldn't suggest spending much time on it, unless you have to work-wise, the investment might not pay off... 15y ago we wrote that ipv6 is "mostly a consulting, training and documentation topic" and I still think it does not bother user layers. At least it should not.
For practical purposes, I am stuck with IPv4 until my ISP decides to switch, and they ain't switching any time soon. AFAIK, their Beta test of IPv6 was a failure. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
Am 11.11.24 um 02:23 schrieb Carlos E. R.:
For practical purposes, I am stuck with IPv4 until my ISP decides to switch, and they ain't switching any time soon. AFAIK, their Beta test of IPv6 was a failure.
I'm using tunnelbroker.net to get an IPv6 address for my DSL until my provider decides to use IPv6 by themselves. I'm a customer of congstar, which is a daughter of deutsche telekom. This conglomerate decided that the technical operation of the net is run by deutsche telekom. They use IPv6 for quite some time now - for their own customers. But since I am not their customer, they can't tell me anything about IPv6. And congstar can't tell me because all the technics are handled by deutsche telekom. Germany at it's best. BTW, my cable provider gives me IPv6 from day 1 on. So all hosts have 2 IPv6 addresses in separate subnets. Werner --
On 2024-11-11 13:10, Werner Flamme via openSUSE Users wrote:
Am 11.11.24 um 02:23 schrieb Carlos E. R.:
For practical purposes, I am stuck with IPv4 until my ISP decides to switch, and they ain't switching any time soon. AFAIK, their Beta test of IPv6 was a failure.
I'm using tunnelbroker.net to get an IPv6 address for my DSL until my provider decides to use IPv6 by themselves.
I'm aware of that, and I refuse to do so. I tried, as a matter of fact. Did not work. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On 11/10/24 19:23, Markus Feilner wrote:
I would not be surprised if the while ipv6 thingy passes by unnoticed to a whatever it will be successor. I wouldn't suggest spending much time on it, unless you have to work-wise, the investment might not pay off... 15y ago we wrote that ipv6 is "mostly a consulting, training and documentation topic" and I still think it does not bother user layers. At least it should not.
As I mentioned, WRT 4G & 5G cell phones, and as Carlos mentioned about some parts of the world, IPv6 is essential and not going away. Maybe some around here should get off their butts and start working with it.
Am Montag, 11. November 2024, 02:30:08 Mitteleuropäische Normalzeit schrieb James Knott:
As I mentioned, WRT 4G & 5G cell phones, and as Carlos mentioned about some parts of the world, IPv6 is essential and not going away. Maybe some around here should get off their butts and start working with it.
I could say exactly the same about IPV4. :-) -- Best Regards - Mit freundlichen Grüßen, Markus Feilner, Feilner IT - 20 years of open services - Digital Sustainability, Sovereignty, Sobriety Open Source Strategy, Knowledge Management, Documentation Trainings, Workshops, Coaching, Networking, Politics, Journalism https://www.feilner-it.net, 93059 Regensburg Wöhrdstr. 10, +49 170 302 7092 (+Signal) https://mastodon.cloud/@mfeilner https://mastodon.social/@FeilnerIT PGP: 40A3C306F96133067C11CFD9A958A906268C9F0A http://www.feilner-it.net/files/MFpub.asc Xing: http://www.xing.com/profile/Markus_Feilner LinkedIn: https://www.linkedin.com/in/markusfeilner @mfeilner: Mastodon, Matrix, Jabber, ... Once you see something, you can't unsee it. And once you've seen it, keeping quiet, saying nothing, becomes as political an act as speaking out. (Arundhati Roy)
participants (9)
-
Carlos E. R. -
Darryl Gregorash -
Dave Howorth -
David T-G -
James Knott -
jdd＠dodin.org -
Lew Wolfgang -
Markus Feilner -
Werner Flamme