Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.networking > #5018 > unrolled thread
| Started by | Mike Mocha <mocha@mailexcite.com> |
|---|---|
| First post | 2022-02-09 08:16 +0000 |
| Last post | 2022-02-15 09:16 -0800 |
| Articles | 20 on this page of 174 — 14 participants |
Back to article view | Back to comp.os.linux.networking
IPv6 Hardware Firewall Mike Mocha <mocha@mailexcite.com> - 2022-02-09 08:16 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-09 10:01 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-09 11:18 +0100
Re: IPv6 Hardware Firewall Mike Scott <usenet.16@scottsonline.org.uk.invalid> - 2022-02-09 15:17 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-09 16:39 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-09 11:16 +0100
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-09 16:54 +0000
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-09 17:57 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-10 08:27 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 10:59 -0700
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-10 19:14 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-10 20:39 +0100
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-10 20:25 +0000
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 14:45 -0700
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-10 22:24 +0000
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 12:49 -0700
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-10 20:48 +0000
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 14:46 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-10 10:08 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 11:01 -0700
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-10 19:15 +0000
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 12:44 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-10 21:34 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 14:01 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-11 14:22 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-11 11:27 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-12 10:49 +0100
Re: IPv6 Hardware Firewall Jorgen Grahn <grahn+nntp@snipabacken.se> - 2022-02-13 19:43 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-13 21:14 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-14 08:47 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 11:48 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-15 20:08 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 12:19 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-15 21:09 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 18:09 -0700
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-10 20:43 +0000
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 14:06 -0700
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-10 21:54 +0000
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-11 14:22 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-11 14:34 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-11 11:35 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-11 19:39 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-11 12:06 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-12 10:50 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-12 19:36 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-13 07:55 +0100
Re: IPv6 Hardware Firewall Bit Twister <BitTwister@mouse-potato.com> - 2022-02-13 03:59 -0600
Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-13 14:02 -0800
Re: IPv6 Hardware Firewall Bit Twister <BitTwister@mouse-potato.com> - 2022-02-13 18:05 -0600
Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-15 09:13 -0800
Re: IPv6 Hardware Firewall Bit Twister <BitTwister@mouse-potato.com> - 2022-02-15 11:36 -0600
Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-15 20:32 -0800
Re: IPv6 Hardware Firewall "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2022-02-15 23:39 -0500
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-13 13:52 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 11:50 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-15 20:09 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-11 11:29 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-12 10:52 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-12 19:40 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-13 13:58 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 11:53 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-16 09:28 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-16 13:04 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-16 21:17 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-17 10:59 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-13 14:05 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 11:56 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-15 20:11 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 12:17 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-16 09:29 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-16 13:08 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-17 11:00 +0100
Re: IPv6 Hardware Firewall Roger Blake <rogblake@iname.invalid> - 2022-02-10 04:08 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-10 08:30 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 10:56 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-10 19:49 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 12:13 -0700
Re: IPv6 Hardware Firewall meff <email@example.com> - 2022-02-11 04:07 +0000
Re: IPv6 Hardware Firewall "Vincent Coen" <VBCoen@gmail.com> - 2022-02-10 21:33 +0000
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 14:48 -0700
Re: IPv6 Hardware Firewall "Vincent Coen" <VBCoen@gmail.com> - 2022-02-11 01:20 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-11 09:35 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-11 11:45 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-11 20:03 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-11 12:14 -0700
Re: IPv6 Hardware Firewall Roger Blake <rogblake@iname.invalid> - 2022-02-12 00:33 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-12 09:27 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-12 10:54 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-12 11:01 +0100
OT Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-12 12:06 -0800
Re: OT Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-12 21:39 +0100
Re: OT Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-13 13:27 -0800
Re: IPv6 Hardware Firewall Roger Blake <rogblake@iname.invalid> - 2022-02-14 02:12 +0000
Re: IPv6 Hardware Firewall Roger Blake <rogblake@iname.invalid> - 2022-02-14 02:06 +0000
Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-15 09:14 -0800
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-10 10:10 +0100
Re: IPv6 Hardware Firewall Mike Mocha <mocha@mailexcite.com> - 2022-02-11 07:28 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-11 09:41 +0100
Re: IPv6 Hardware Firewall Roger Blake <rogblake@iname.invalid> - 2022-02-12 00:38 +0000
Re: IPv6 Hardware Firewall David Brown <david.brown@hesbynett.no> - 2022-02-13 11:49 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-13 13:51 +0100
Re: IPv6 Hardware Firewall David Brown <david.brown@hesbynett.no> - 2022-02-13 14:54 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-13 15:31 +0100
Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-13 14:07 -0800
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 12:25 -0700
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 12:15 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-15 21:18 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 18:18 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-16 16:24 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-16 13:16 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-17 11:03 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-17 10:20 -0700
Re: IPv6 Hardware Firewall meff <email@example.com> - 2022-02-16 01:53 +0000
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-16 09:37 +0000
Re: IPv6 Hardware Firewall meff <email@example.com> - 2022-02-16 19:50 +0000
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-17 11:41 +0000
Re: IPv6 Hardware Firewall meff <email@example.com> - 2022-02-17 21:22 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-16 16:26 +0100
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-16 16:48 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-16 19:13 +0100
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-16 19:15 +0000
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-16 20:56 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-16 21:18 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-17 11:06 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-17 10:27 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-18 08:26 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-18 12:05 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-18 10:41 -0700
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-18 10:43 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-18 20:20 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-18 20:34 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-18 13:46 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-19 10:03 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-19 17:03 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-20 07:39 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-20 08:52 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-20 14:05 +0100
Re: IPv6 Hardware Firewall Roger Blake <rogblake@iname.invalid> - 2022-02-20 22:50 +0000
Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-20 18:10 -0800
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-21 08:16 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-21 08:57 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-21 18:41 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-21 11:31 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-21 21:09 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-22 16:44 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-20 08:51 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-19 17:11 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-20 07:41 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-19 17:13 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-20 07:42 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-18 20:33 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-18 20:47 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-19 10:03 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-18 10:35 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-18 20:36 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-18 13:41 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-19 07:43 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-19 10:08 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-19 10:07 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-19 17:08 -0700
Re: IPv6 Hardware Firewall David Brown <david.brown@hesbynett.no> - 2022-02-16 13:01 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-16 19:12 +0100
Re: IPv6 Hardware Firewall David Brown <david.brown@hesbynett.no> - 2022-02-17 09:12 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-17 10:31 -0700
Re: IPv6 Hardware Firewall David Brown <david.brown@hesbynett.no> - 2022-02-18 09:25 +0100
Re: IPv6 Hardware Firewall meff <email@example.com> - 2022-02-17 21:21 +0000
Re: IPv6 Hardware Firewall David Brown <david.brown@hesbynett.no> - 2022-02-18 09:25 +0100
Re: IPv6 Hardware Firewall meff <email@example.com> - 2022-02-11 10:28 +0000
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-11 10:56 +0000
Re: IPv6 Hardware Firewall Roger Blake <rogblake@iname.invalid> - 2022-02-12 00:36 +0000
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-12 10:56 +0100
Re: IPv6 Hardware Firewall Roger Blake <rogblake@iname.invalid> - 2022-02-14 02:15 +0000
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-14 08:52 +0100
Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-15 09:16 -0800
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2022-02-13 13:51 +0100 |
| Message-ID | <20220213135148.0dc315e6@ryz> |
| In reply to | #5087 |
Am Sonntag, 13. Februar 2022, um 11:49:22 Uhr schrieb David Brown: > On 11/02/2022 09:41, Marco Moock wrote: > > Am Freitag, 11. Februar 2022, um 07:28:05 Uhr schrieb Mike Mocha: > > > >> Thanks for all the responses! Something that still is not making > >> sense to me, if for example we have a home network that contains > >> many different IPv6 devices connected, how do we control what > >> ports get exposed on each device? > > > > The concept of the internet (IPv4 and IPv6) is that every device > > has an unique address that is reachable from any other node. > > That /was/ the original idea - back when IP networking was for a few > specialised uses such as military research, universities, and a few > niche companies. Such a concept does not scale to today's networking > needs, and that has /nothing/ to do with the number of IPv4 addresses. They scale very well if you have enough addresses available. It is much easier because you don't need a NAT/PAT table nor create concepts for interconnecting LANs with RF1918 address etc. > It is a /long/ time since computers and users have had the level of > trust that existed then. With more software, has come more security > holes. The average level of knowledge of users has dropped as > computers arrived on every desk, not just the desks of experts. > > The number of connected nodes has increased dramatically over the > decades. Unique addressing is not the issue - it's an irrelevancy. A > system where any node can address any other node simply does not > scale. It does very well, a home customer has about 2^64 addresses available. Tell me what you can't do with that. > So what we have is a somewhat hierarchical system - basically on two > levels. There is the "internet" which supports wide-range access and > routing, with many servers directly on that network. And there is > there are countless local networks with interaction within the > network, and access to internet-based servers, but with no need for > anything outside to get in. Why do we need a hierarchical system here? If we want addresses for local-only services we can use ULA. also more than enough addresses available for all your needs. > Rounded to the nearest tenth of a percent, all computers are > client-only. (Yes, the remaining fraction that act as servers is > important.) They are mobile phones, home computers, work desktops, > etc. All of these need to be able to access servers on the internet. That is what big companies and providers tells us. Everybody that wants to use VoIP without any problems needs to be reachable from the outside. > /None/ of them need to be accessed by any other computer. The only > time something tries to directly access them, is an attack from some > hacker, worm or other malware. No one wants that, or to make that > easier. Then they can operate an SPI firewall. Windows has one enabled by default, most home routers have one enabled. > Of course you can say that it is the job of the firewall to block > incoming connections while allowing packets of established connections > to pass through from the internet. But when the firewall is already > doing this connection tracking, it can also do NAT'ing at little cost. > That then makes the routing process upstream /hugely/ easier. Why should it do NAT? What makes it better in the routing? I see no benefit at all. > What benefit would there be from each device having a unique IP > address that is used directly, without NAT? The device would /not/ > be reachable from any other node - if you think that would be a good > thing, with every hacker on the other side of the globe having direct > access to your grandma's mobile, you are living on a different planet. The grandma's router has an SPI fw enabled. Grandma's Windows has an SPI FW enabled by default, so no problem. If you have a good operating system, no server software runs on the public addresses. Then there is also no problem at all without NAT or an SPI fw. > The only people that would see this as a direct benefit are the > Facebooks of the world, and the porn-site based scammers and > blackmailers. (That includes "legitimate" porn sites that get hacked > by scammers and blackmailers.) They'd love to know /exactly/ which > computer was used, as accurately as possible, rather than seeing > common router IP addresses. Because of proxy servers and NAT companies like Facebook and Google created other methods of tracking. They use User Agents, Cookies, Browser storage to identify a user, they don't need an unique IP address. > > NAT and all that > > crap are just temporary solutions for keeping IPv4 alive. > > NAT is a fine example of the flexibility of IP networking, and does a > fine job of helping compartmentalise and modularise the network. It > is also extremely easy to have a simple NAT setup - these days pretty > much every home has a NAT router with Wifi, that comes out of the box > with a setup that provides a basic level of security for the home > (except for the NAT routers that have hopeless default passwords). NAT first creates a flexibility and then you see how bad it is. Think about DNS with servers that have private addresses and should have a host name. You then need NAT hairpinning and other nasty stuff. > In the days of dial-up, people would take their Windows XP machines > and connect directly to the internet, getting a global IP that was > reachable from any node. Their machine would be taken over by > hostile hackers and bots long before it had managed to download the > latest service packs and updates, which at best only blocked half the > attacks anyway. Now they connect their new Windows machines to their > NAT router, and /no/ attacks get in (until they do something stupid, > like click on a phishing email link). The main problem of that is that Windows has enabled server software like NetBIOS over IP and SMB. This is the problem and NAT/SPI should now solve the biggest security problem that MS was able to create? Personally, I don't care anymore about windows machines because they are insecure by design. > > We should > > switch to IPv6 ASAP. > > > There are certainly cases where a greater availability of globally > unique addresses would be helpful. While almost all computers are not > servers, /some/ are, and sometimes a unique address on the internet > would be handy. > > I see some benefits to IPv6, but not enough to bother much about it as > yet. And when I do start using it seriously, it will be with NAT. Then do it if you like a really bad network infrastructure. What I wanna is that I can switch off IPv4 at all at my side without having problems to connect to other's servers.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-02-13 14:54 +0100 |
| Message-ID | <sub2i3$l0f$1@dont-email.me> |
| In reply to | #5088 |
On 13/02/2022 13:51, Marco Moock wrote: > Am Sonntag, 13. Februar 2022, um 11:49:22 Uhr schrieb David Brown: >> In the days of dial-up, people would take their Windows XP machines >> and connect directly to the internet, getting a global IP that was >> reachable from any node. Their machine would be taken over by >> hostile hackers and bots long before it had managed to download the >> latest service packs and updates, which at best only blocked half the >> attacks anyway. Now they connect their new Windows machines to their >> NAT router, and /no/ attacks get in (until they do something stupid, >> like click on a phishing email link). > > The main problem of that is that Windows has enabled server software > like NetBIOS over IP and SMB. This is the problem and NAT/SPI should > now solve the biggest security problem that MS was able to create? > Personally, I don't care anymore about windows machines because they > are insecure by design. > As long as /you/ are all right, screw the rest of the world? It's fine to blame MS for a decades-long attitude where security is an afterthought at best - you'll find few people who are particularly impressed with Windows security (and even fewer in a newsgroup like this one!). But in one simple step, NAT eliminates a whole major class of security issues for client systems (including Linux and other OS's). It does so in a way that is not only easy to get right, it is also hard to get wrong. Security is not a feature - a one-off item that you attach to your network. It is a process, and it is a matter of layers and combinations. Each part reduces the overall risk of breaches - none is absolute on its own, but in total you find an acceptable risk level. And it is always a balance between keeping out the stuff you don't want, while letting in the stuff you /do/ want with as little user inconvenience as possible. NAT plays an important part in the security in a lot of systems because it provides a huge step at keeping out unwanted stuff while being of very little inconvenience to most users. And it does this for practically nothing - stand-alone NAT routers for small networks cost peanuts, and any serious router for a big network will do it with negligible delay or overhead. There are not many security measures that are so effective for so low cost.
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2022-02-13 15:31 +0100 |
| Message-ID | <20220213153127.79cc7ea3@ryz> |
| In reply to | #5092 |
Am Sonntag, 13. Februar 2022, um 14:54:10 Uhr schrieb David Brown: > NAT plays an important part in the security > in a lot of systems because it provides a huge step at keeping out > unwanted stuff while being of very little inconvenience to most users. > And it does this for practically nothing - stand-alone NAT routers for > small networks cost peanuts, and any serious router for a big network > will do it with negligible delay or overhead. There are not many > security measures that are so effective for so low cost. Every SPI firewall does the same and costs the same. There is absolutely NO security reason for NAT at all. SPI works perfectly well and is included for IPv6 in every home router. SPI also costs nothing but doesn't have the nasty things of NAT. NAT wasn't intended for security, it was intended for expanding the lifetime of IPv4.
[toc] | [prev] | [next] | [standalone]
| From | jrg <jeff.g.group@att.net> |
|---|---|
| Date | 2022-02-13 14:07 -0800 |
| Message-ID | <subvee$115p$1@gioia.aioe.org> |
| In reply to | #5092 |
On 2/13/22 05:54, David Brown wrote: > As long as/you/ are all right, screw the rest of the world? sounds like an echo...
[toc] | [prev] | [next] | [standalone]
| From | Grant Taylor <gtaylor@tnetconsulting.net> |
|---|---|
| Date | 2022-02-15 12:25 -0700 |
| Message-ID | <sugunl$4tk$1@tncsrv09.home.tnetconsulting.net> |
| In reply to | #5092 |
On 2/13/22 6:54 AM, David Brown wrote: > But in one simple step, NAT eliminates a whole major class of security > issues for client systems (including Linux and other OS's). It does > so in a way that is not only easy to get right, it is also hard to > get wrong. I think that the second part of that is extremely germane: "easy to get right" and more importantly "had to get wrong". > And it is always a balance between keeping out the stuff you don't > want, while letting in the stuff you /do/ want with as little user > inconvenience as possible. NAT plays an important part in the security > in a lot of systems because it provides a huge step at keeping out > unwanted stuff while being of very little inconvenience to most users. I read that statement a little differently and I think that it's worth sharing the idea. Do something that implicitly breaks communications (e.g. incompatible addressing) such that you must do something that explicitly enables communications (e.g. NAT / proxy). There is a lot to be said for a security system that requires explicit precise action to make something externally available while just about anything else will fail to communicate externally in one of many ways. I say "just about" because even a blind hog finds a truffle on occasion. Chaos also dictates that the dryer be folded when you open it for the first time. -- Grant. . . . unix || die
[toc] | [prev] | [next] | [standalone]
| From | Grant Taylor <gtaylor@tnetconsulting.net> |
|---|---|
| Date | 2022-02-15 12:15 -0700 |
| Message-ID | <sugu35$ia2$1@tncsrv09.home.tnetconsulting.net> |
| In reply to | #5088 |
On 2/13/22 5:51 AM, Marco Moock wrote: > They scale very well if you have enough addresses available. I believe that David was referring to the security implications related to trust rather than the addressing of the underlying protocol. If nothing else, based on population size of connected devices. > Why do we need a hierarchical system here? If we want addresses for > local-only services we can use ULA. also more than enough addresses > available for all your needs. Site-local vs link-local immediately comes to mind. > That is what big companies and providers tells us. Everybody that > wants to use VoIP without any problems needs to be reachable from > the outside. I've used VoIP without any problem without globally routed addresses. There is a difference in something being simpler / more pristine vs less simple / less pristine and still working perfectly fine. The latter tends to negate the former as arguments for must have global reach ability. > Then they can operate an SPI firewall. Windows has one enabled by > default, most home routers have one enabled. I think that it's important to keep time & context in mind. Windows has an SPI firewall enabled by default /now/. It did not 20 years ago. > If you have a good operating system, no server software runs on the > public addresses. Then there is also no problem at all without NAT > or an SPI fw. I will not bet my security on "good operating system" nor "no server software runs on the public address" /alone/. Does "belt and suspenders" or "layers of security" mean anything? > Because of proxy servers and NAT companies like Facebook and Google > created other methods of tracking. They use User Agents, Cookies, > Browser storage to identify a user, they don't need an unique IP > address. I'm fairly certain that the User-Agent and Cookies headers pre-date wide adoption of NAT. The definitely pre-date Facebook and Google. Also, trusting the IP address alone is insufficient. IPs used to be far more dynamic than they are today. Thus you couldn't rely on them for identification in the vast majority of situations. > NAT first creates a flexibility and then you see how bad it is. Think > about DNS with servers that have private addresses and should have > a host name. You then need NAT hairpinning and other nasty stuff. I guess setting up an internal zone to resolve the name to the LAN IP is "other nasty stuff". > The main problem of that is that Windows has enabled server software > like NetBIOS over IP and SMB. This is the problem and NAT/SPI should > now solve the biggest security problem that MS was able to create? > Personally, I don't care anymore about windows machines because they > are insecure by design. > > Then do it if you like a really bad network infrastructure. What I > wanna is that I can switch off IPv4 at all at my side without having > problems to connect to other's servers. Currently (2022) you will have better connectivity with IPv4+IPv6 with NAT than you will with IPv6 only. Sadly, the Internet isn't even close to parity between IPv4 and IPv6 from a service availability standpoint. -- Grant. . . . unix || die
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2022-02-15 21:18 +0100 |
| Message-ID | <20220215211807.08a73313@ryz> |
| In reply to | #5116 |
Am Dienstag, 15. Februar 2022, um 12:15:00 Uhr schrieb Grant Taylor: > On 2/13/22 5:51 AM, Marco Moock wrote: > > Why do we need a hierarchical system here? If we want addresses > > for local-only services we can use ULA. also more than enough > > addresses available for all your needs. > > Site-local vs link-local immediately comes to mind. True, both are there and there are use cases where they are useful or not. > > That is what big companies and providers tells us. Everybody that > > wants to use VoIP without any problems needs to be reachable from > > the outside. > > I've used VoIP without any problem without globally routed addresses. I also have that situation at home, but it is very annoying. > > Then they can operate an SPI firewall. Windows has one enabled by > > default, most home routers have one enabled. > > I think that it's important to keep time & context in mind. Windows > has an SPI firewall enabled by default /now/. It did not 20 years > ago. I know, but the main problem already was and is still that Windows is running server software by default. > > If you have a good operating system, no server software runs on the > > public addresses. Then there is also no problem at all without NAT > > or an SPI fw. > > I will not bet my security on "good operating system" nor "no server > software runs on the public address" /alone/. Does "belt and > suspenders" or "layers of security" mean anything? I know that, but I definitely don't rely on firewalling. I disable the cause of the security issue and I don't try to make it less vulnerable with a FW. > Also, trusting the IP address alone is insufficient. IPs used to be > far more dynamic than they are today. Thus you couldn't rely on them > for identification in the vast majority of situations. I also don't rely on them for auth, but i use them as an additional criteria if possible. > > NAT first creates a flexibility and then you see how bad it is. > > Think about DNS with servers that have private addresses and should > > have a host name. You then need NAT hairpinning and other nasty > > stuff. > > I guess setting up an internal zone to resolve the name to the LAN IP > is "other nasty stuff". Yes, that is what I mean because that often creates problems. Forst, DNS uses caching and a computer that was outside my have the public IP in its cache (TTL not expired yet) and will not ask the name server again when coming to the internal net. Then a computer doesn't need to use the specific DNS to resolve the name. Maybe it is configured to use a specific DNS. Google Chrome and Firefox offer DNS over HTTPS and maybe use that instead of the DNS the computer gets via IPv6-RA/DHCP. > > The main problem of that is that Windows has enabled server > > software like NetBIOS over IP and SMB. This is the problem and > > NAT/SPI should now solve the biggest security problem that MS was > > able to create? Personally, I don't care anymore about windows > > machines because they are insecure by design. > > > > Then do it if you like a really bad network infrastructure. What I > > wanna is that I can switch off IPv4 at all at my side without > > having problems to connect to other's servers. > > Currently (2022) you will have better connectivity with IPv4+IPv6 > with NAT than you will with IPv6 only. Sadly, the Internet isn't > even close to parity between IPv4 and IPv6 from a service > availability standpoint. Full ack, it is really annoying that I still need to have IPv4 connectivity, especially when self-hosting my servers I need to access from IPv4-only nets.
[toc] | [prev] | [next] | [standalone]
| From | Grant Taylor <gtaylor@tnetconsulting.net> |
|---|---|
| Date | 2022-02-15 18:18 -0700 |
| Message-ID | <suhjch$h1j$1@tncsrv09.home.tnetconsulting.net> |
| In reply to | #5121 |
On 2/15/22 1:18 PM, Marco Moock wrote: > True, both are there and there are use cases where they are useful > or not. That can be said about any and all tools in the proverbial networking tool box. ;-) > I also have that situation at home, but it is very annoying. What /specifically/ is annoying? What doesn't function at all? What doesn't function to satisfactorily? What do you want to change? What would you change it to? Why would you change it? I'm genuinely asking in the spirit of discussion to understand and learn from your viewpoint. > I know, but the main problem already was and is still that Windows > is running server software by default. I think that "by default" is the most operative part of that statement. It's entirely possible to configure Windows so that it's considerably safer to have as a server. But it takes effort and is decidedly against the default. One of the first things to do is to unbind Client for Microsoft Networks and File & Printer Sharing from NICs. }:-) > I know that, but I definitely don't rely on firewalling. I disable the > cause of the security issue and I don't try to make it less vulnerable > with a FW. As well you should. > I also don't rely on them for auth, but i use them as an additional > criteria if possible. Fair enough. I think that IPSec AH and / or ESP is a LOT better for authentication than IP. That being said, I only allow IPSec from known endpoints that should be speaking it. No need to expose services to the world where it's not needed. > Yes, that is what I mean because that often creates problems. ACK > Forst, DNS uses caching and a computer that was outside my have the > public IP in its cache (TTL not expired yet) and will not ask the > name server again when coming to the internal net. Understood. I'd be curious to know what client device is retaining local stub resolver cache when changing networks and therefore likely changing DNS server configuration. > Then a computer doesn't need to use the specific DNS to resolve the > name. Maybe it is configured to use a specific DNS. Google Chrome > and Firefox offer DNS over HTTPS and maybe use that instead of the > DNS the computer gets via IPv6-RA/DHCP. Don't et me started on the over zealous use of DoH. There are MANY aspects of enterprise networks which break when things naively assume that an outside the enterprise DNS server can provide the same DNS service. > Full ack, it is really annoying that I still need to have IPv4 > connectivity, especially when self-hosting my servers I need to access > from IPv4-only nets. Sadly, I think we're going to be in the current state for one to three decades. -- Grant. . . . unix || die
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2022-02-16 16:24 +0100 |
| Message-ID | <20220216162433.505a8d4a@ryz> |
| In reply to | #5123 |
Am Dienstag, 15. Februar 2022, um 18:18:24 Uhr schrieb Grant Taylor: > On 2/15/22 1:18 PM, Marco Moock wrote: > > I also have that situation at home, but it is very annoying. > > What /specifically/ is annoying? That I need a special application gateway (that does NAT in the background) on my Cisco router to make SIP/RTSP work. > What doesn't function at all? If I don't have such a special NAT "gateway" I wouldn't be able to be called from others via IPV4. > What do you want to change? Getting rid off NAT here to get rid off that gateway. With IPv6 I don't need that and it is a much easier configuration. Easier for me means more reliable because less things can get broken. > > I know, but the main problem already was and is still that Windows > > is running server software by default. > > I think that "by default" is the most operative part of that > statement. > > It's entirely possible to configure Windows so that it's considerably > safer to have as a server. But it takes effort and is decidedly > against the default. One of the first things to do is to unbind > Client for Microsoft Networks and File & Printer Sharing from NICs. Full ack, that's what I do at work when I have a Windows computer for specific applications. > > Forst, DNS uses caching and a computer that was outside my have the > > public IP in its cache (TTL not expired yet) and will not ask the > > name server again when coming to the internal net. > > Understood. > > I'd be curious to know what client device is retaining local stub > resolver cache when changing networks and therefore likely changing > DNS server configuration. I assume systemd-resolved does, I already experienced that with it. The reason for that is that DNS with global resolved domains is intended to equal regardless which resolver ask. For the caches I see no reason in clearing the cache if the network comes up/down. > > Then a computer doesn't need to use the specific DNS to resolve the > > name. Maybe it is configured to use a specific DNS. Google Chrome > > and Firefox offer DNS over HTTPS and maybe use that instead of the > > DNS the computer gets via IPv6-RA/DHCP. > > Don't et me started on the over zealous use of DoH. There are MANY > aspects of enterprise networks which break when things naively assume > that an outside the enterprise DNS server can provide the same DNS > service. Completely agree, but if you have just one computer that isn't administered by the company you need to emanate that some users don't use your local resolver. > > Full ack, it is really annoying that I still need to have IPv4 > > connectivity, especially when self-hosting my servers I need to > > access from IPv4-only nets. > > Sadly, I think we're going to be in the current state for one to > three decades. Maybe yes, but there is hope over the horizon, some big tech companies implement IPv6 and I just wait until they say "we switch off IPv4 in one year" or "websites without IPv6 connectivity will be unlisted from Google".
[toc] | [prev] | [next] | [standalone]
| From | Grant Taylor <gtaylor@tnetconsulting.net> |
|---|---|
| Date | 2022-02-16 13:16 -0700 |
| Message-ID | <sujm1k$g82$1@tncsrv09.home.tnetconsulting.net> |
| In reply to | #5131 |
On 2/16/22 8:24 AM, Marco Moock wrote: > That I need a special application gateway (that does NAT in the > background) on my Cisco router to make SIP/RTSP work. > > If I don't have such a special NAT "gateway" I wouldn't be able to > be called from others via IPV4. What's more responsible for that problem? SIP itself or NAT? There are many other protocols that work through NAT perfectly fine without the need for such shenanigans. It's been a while, but I think that it is possible for SIP clients to connect to a globally routed IPv4 address that is port forwarded / NATed to an internal server without the need for the NAT gateway shenanigans. But, maybe I'm mis-remembering things. Maybe it was configuration of the SIP server saying "Report $THIS external IP." > Getting rid off NAT here to get rid off that gateway. With IPv6 I > don't need that and it is a much easier configuration. Easier for > me means more reliable because less things can get broken. Fair enough. > I assume systemd-resolved does, I already experienced that with > it. The reason for that is that DNS with global resolved domains is > intended to equal regardless which resolver ask. For the caches I > see no reason in clearing the cache if the network comes up/down. Bleck I actively avoid systemd and it's ilk. > Completely agree, but if you have just one computer that isn't > administered by the company you need to emanate that some users don't > use your local resolver. > > Maybe yes, but there is hope over the horizon, some big tech companies > implement IPv6 and I just wait until they say "we switch off IPv4 > in one year" or "websites without IPv6 connectivity will be unlisted > from Google". Ha! I don't think we'll see big services turning off IPv4 any time soon. I doubt we will see it in the next decade, if not more like two decades. As long as there are more than a tiny percentage of IPv4 only clients, the big players will still have IPv4 connectivity. -- Grant. . . . unix || die
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2022-02-17 11:03 +0100 |
| Message-ID | <sul6hc$v6hj$1@news1.tnib.de> |
| In reply to | #5141 |
Grant Taylor <gtaylor@tnetconsulting.net> wrote: >On 2/16/22 8:24 AM, Marco Moock wrote: >> That I need a special application gateway (that does NAT in the >> background) on my Cisco router to make SIP/RTSP work. >> >> If I don't have such a special NAT "gateway" I wouldn't be able to >> be called from others via IPV4. > >What's more responsible for that problem? SIP itself or NAT? There are >many other protocols that work through NAT perfectly fine without the >need for such shenanigans. SIP is a really horrible protocol. It should have been in an April Fools RFC. >It's been a while, but I think that it is possible for SIP clients to >connect to a globally routed IPv4 address that is port forwarded / NATed >to an internal server without the need for the NAT gateway shenanigans. That is incredibly painful, especially if you want to _receive_ calls. >But, maybe I'm mis-remembering things. Maybe it was configuration of >the SIP server saying "Report $THIS external IP." Maybe. Doesn't work with a dynmic IP address. >> I assume systemd-resolved does, I already experienced that with >> it. The reason for that is that DNS with global resolved domains is >> intended to equal regardless which resolver ask. For the caches I >> see no reason in clearing the cache if the network comes up/down. > >Bleck > >I actively avoid systemd and it's ilk. Why am I not surprised about that? >> Completely agree, but if you have just one computer that isn't >> administered by the company you need to emanate that some users don't >> use your local resolver. >> >> Maybe yes, but there is hope over the horizon, some big tech companies >> implement IPv6 and I just wait until they say "we switch off IPv4 >> in one year" or "websites without IPv6 connectivity will be unlisted >> from Google". > >Ha! I don't think we'll see big services turning off IPv4 any time >soon. I doubt we will see it in the next decade, if not more like two >decades. Yes. You're part of the party that makes sure it's going to happen this way. That does not mean that internal networks won't go single stack IPv6. I don't mind having a handful of dual-stacked, internet-facing servers. Greetings Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | Grant Taylor <gtaylor@tnetconsulting.net> |
|---|---|
| Date | 2022-02-17 10:20 -0700 |
| Message-ID | <sum053$7dp$1@tncsrv09.home.tnetconsulting.net> |
| In reply to | #5147 |
On 2/17/22 3:03 AM, Marc Haber wrote: > SIP is a really horrible protocol. It should have been in an April > Fools RFC. Agreed. > That is incredibly painful, especially if you want to _receive_ calls. I'll give you that it's painful from a technology and configuration standpoint. But I disagree about the receiveing calls part. There are MANY VoIP users that have done nothing that are receiving calls through this type of configuration. The trick is that the calls come in over an established connection from between external server and the VoIP endpoint. Is it as pure as the calls coming directly to the VoIP endpoint? Nope. Did it stop Vonnage et al. from offering VoIP service to these types of VoIP endpoints? Nope. Does it work through indirect methods? Yep. > Maybe. Doesn't work with a dynmic IP address. There are multiple ugly solutions that allow dynamic IPs to work. Usually related to learning the (new) current external IP and re-configuring themselves / re-registering with the upstream VoIP server. Again, see Vonnage et al. doing this for years. > Why am I not surprised about that? > > Yes. You're part of the party that makes sure it's going to happen > this way. I think quite the contrary. I advocate for IPv6 adoption. I've adopted IPv6 on all my personal things for longer than I can remember. I ask multiple vendors when they are going to start offering, much less actually supporting (as in help desk) IPv6. I'm also quite realistic that we're going to have IPv4 for a LONG time. > That does not mean that internal networks won't go single stack IPv6. > I don't mind having a handful of dual-stacked, internet-facing servers. In some ways that seems like a disingenuous response. It doesn't really matter /how/ you support IPv4, or /where/ you support IPv4. The fact remains that you *ARE* supporting IPv4 in some way somewhere in your network. If you're communicating with an IPv4 endpoint in any capacity, you are supporting the perpetuation of IPv4. -- Grant. . . . unix || die
[toc] | [prev] | [next] | [standalone]
| From | meff <email@example.com> |
|---|---|
| Date | 2022-02-16 01:53 +0000 |
| Message-ID | <suhler$ege$1@dont-email.me> |
| In reply to | #5121 |
On 2022-02-15, Marco Moock <mo01@posteo.de> wrote: > I know, but the main problem already was and is still that Windows is > running server software by default. I'm sympathetic to your anger at NAT, but I think it's unrealistic in this day and age to expect people to have _full control_ of their local network. Some folks live with someone else (relatives, parent, shared housing) who controls their network, other times you have guests who join your network who are running things you have no control over. When I was a kid hacking around, I was running all sorts of insecure garbage (and writing insecure code (though that was a different time)) on my machine. You could try to partition your network into a "guest" subnet and a "home" subnet and place a stateful firewall in front of the guest subnet, but very few consumer router/AP combos offer a user-friendly way to make this separation. (Happy to be proven wrong on this point.)
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2022-02-16 09:37 +0000 |
| Message-ID | <slrnt0phfq.idl.dan@djph.net> |
| In reply to | #5124 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 meff wrote: > [...] > You could try to partition your network into a "guest" subnet and a > "home" subnet and place a stateful firewall in front of the guest > subnet, but very few consumer router/AP combos offer a user-friendly > way to make this separation. (Happy to be proven wrong on this point.) Even the $50 TPLink stuff can do a guest WiFi network, such as the Archer A7. Should take you right to chapter 8.1 "Create a guest network". https://static.tp-link.com/2021/202103/20210325/1910012976_Archer%20C7&A7_UG_REV5.2.0.pdf#page=40 -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmIMxfgACgkQbWVw5Uzn KGCpXw//cJlx4hk3obn2PU52Fb+d667IfMdMzOqOg2j/L+CGL5zBMKV/wYO/5gBJ VAytZi1lLbMfXRXDR8rmOorP977CgPRYK1+7+zfpx7/NQe5g/9oKjH1C4NQlXE9A 0xwATaSQO6WVAyQ25El7Ln8BqeMZZP44vFY19FNTjBomQgaIN8p39F9j/drtnZJE Yb6bLHnyaHRPfSFEOKzPwqnTErA3XYBZFxYe8mRa+OCLT4xP/9DZGq8wSbibahNL q79buT5bHsLmuJHld0DOT17le+xr0u1e4YLTNGAGYNo+ZVZ64G+/MO/XGcKg6OXO z7iSaVWamiMQ6ed0tTeYL8eamqDfXWTqAFIT+n8UIm5vnkHCp2pmon+YV7jJVhRV 0VorsyjdUhXhNChl8G5Ut7XS4HBvZkdZQQfWwWh4Mj8GIwzBSQsOlqFy7OMSeKS4 cWRGUeWAO8WPzLdJIeuxkEtRlpNQUwU7hsOq7Bf2gPLBpmyiCD50lRCMGvOphHsJ 1nLWCGJ/K9dP2Lkcvz8HxQ+GPY2llrq/JaSRqm+t+cmtigk2lwvUZ0Pg7qYpByu1 k756GjdXhpcbY+uAWOnZtO5J8dmAJh1S4J33ctRrsVy5CKJ7vK2aSa8IKAduy5jo xzlgW3MVFRTnyzsEllEF8sV6aADGUlwHoIZBCTUwk0LFFoahaHc= =7m1H -----END PGP SIGNATURE----- -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860
[toc] | [prev] | [next] | [standalone]
| From | meff <email@example.com> |
|---|---|
| Date | 2022-02-16 19:50 +0000 |
| Message-ID | <sujki0$omp$1@dont-email.me> |
| In reply to | #5129 |
On 2022-02-16, Dan Purgert <dan@djph.net> wrote: > Even the $50 TPLink stuff can do a guest WiFi network, such as the > Archer A7. Sorry I'm specifically referring to IPv6 subnetting here.
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2022-02-17 11:41 +0000 |
| Message-ID | <slrnt0sd55.idl.dan@djph.net> |
| In reply to | #5137 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 meff wrote: > On 2022-02-16, Dan Purgert <dan@djph.net> wrote: >> Even the $50 TPLink stuff can do a guest WiFi network, such as the >> Archer A7. > > Sorry I'm specifically referring to IPv6 subnetting here. And it can do v6 as well ... obviously your ISP would need to support it. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmIONKUACgkQbWVw5Uzn KGAaBg/9HlfwcDtw5hNgeqtuM3BBAtyDmqKSRfNq/ASWnZ/RWxFmxLNDdnX//76z 73NkYJM6ERXTYCdlDqS4TbgR8N2CueK17kpl2Y/NcGN9aCgOWzHQK7DRXQWI/2h5 naLSsl7VkBA5AKAsh4q4UweqXEJP/nP5CB7AaTvo8Cg7Tj6iS8aOxzfx4WF8YFfg HICRilNCYv+bmRlFJuPuyVIzhUw17t55Cilb92CHiPU5So3ZLHjstZi71voWr+zx G8uCgZkzZ0pPB0uDKzMKjkXcIdW8m+Fi0Q6P9/yXPIhER0ZQ/YS/A2yDvBQx0Hcv 4Qp+GKh2qLLbAwP2FAUsOBOusGz4Fi3nKMFL/RRmSTgiiDQsbD1d0dz78LQM2BlD e9dJ1bYr8tkseohSSkKZoKtAJxowhXa+vslTUCsfiQUkq1+teiXK0L9EBai59yiq Zcr/B4+C3LKaGnQc2QQJcv/ilZuUkD3n6720r3mNzN5bumhtZOUpXchynXGnBFlS WplxW7B5aD9Eg6HUwczVsFnFGpSRTkkDWkdyp8N6w2fJJgmPU1H/TivESzCIqROP NigCot8XP+BeJR7qim9/bmwke07M06YzF4QZEPTgh9e6znMUMVYsnIJJkBPeqOIk RsYFSGRKVlJfXAeob8mGcaCtm6BXGsbuMN5N2DsPLvnvvLyA+B8= =wGXy -----END PGP SIGNATURE----- -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860
[toc] | [prev] | [next] | [standalone]
| From | meff <email@example.com> |
|---|---|
| Date | 2022-02-17 21:22 +0000 |
| Message-ID | <sumead$mpo$2@dont-email.me> |
| In reply to | #5149 |
On 2022-02-17, Dan Purgert <dan@djph.net> wrote: > And it can do v6 as well ... obviously your ISP would need to support > it. Good to know, thanks. I'll be helping setup a home network for a family member soon anyway so it's a timely recommendation thanks.
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2022-02-16 16:26 +0100 |
| Message-ID | <20220216162643.14b162e1@ryz> |
| In reply to | #5124 |
Am Mittwoch, 16. Februar 2022, um 01:53:31 Uhr schrieb meff: > You could try to partition your network into a "guest" subnet and a > "home" subnet and place a stateful firewall in front of the guest > subnet, but very few consumer router/AP combos offer a user-friendly > way to make this separation. (Happy to be proven wrong on this point.) The main problem here is that most people don't care about their network. Additionally, many ISPs only offer /64 prefixes and it is a PITA to subnet them to 2 /65 because you then need DHCPv6 to address your devices. The additional work isn't worth the goal here for most people.
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2022-02-16 16:48 +0000 |
| Message-ID | <slrnt0qaop.idl.dan@djph.net> |
| In reply to | #5132 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Marco Moock wrote: > Am Mittwoch, 16. Februar 2022, um 01:53:31 Uhr schrieb meff: > >> You could try to partition your network into a "guest" subnet and a >> "home" subnet and place a stateful firewall in front of the guest >> subnet, but very few consumer router/AP combos offer a user-friendly >> way to make this separation. (Happy to be proven wrong on this point.) > > The main problem here is that most people don't care about their > network. Additionally, many ISPs only offer /64 prefixes and it is a > PITA to subnet them to 2 /65 because you then need DHCPv6 to address > your devices. The additional work isn't worth the goal here for most > people. Last time I had a "whole home gateway" from the ISP, it'd give a completely separate /64 to the "Guest WiFi" (if v6 was enabled on it). -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmINKxkACgkQbWVw5Uzn KGBQBg/+KGPfZUHFRMireLT0LNXTphdcJafbRdYQjSOXyRfPcq2tPzoZorL/hNpZ e0FYiimtwrrr1GO5XwlTubj3GcG2jObDGMuA2PRdfFS+PMPevu4H2YYD649fTjZ4 vkuKWE4kbtlKrVFtZtYQXjXfMZ/gqk13XloBWo6Xwh2Jf4ZaJ0ASuNG6oCELayaa 9s55DFcL4E3kGk0inyGfE89+o8MlzDkYEucYhxwMKdH+6JGw2HpV0nSIr8z8Kvmx 7DbFz8EP3E6L+gMtsWVzoAoQmkK6AIAIrCk+m0EM4qHz7yPOj2t4KM6t53TeUwyO p0pnERI8h+ZM/ML+nQqdVJxwc7PwjEYKy8M8Stp/qHG5NnuUp1+deWmuODdXmrUI UG1COcr0HKEZfhKRl7Zgq6rR00MwE2rSwKZL+HJ3QWR/or9BjDtaZhTHPGBQAXvB d0LRqzO6fZ8SKEU+yomlvlAGsmb3w5KruZXysUnv/UWTzVVFkQpp9toM/DwMXdtX xaqTnejh/9DnjHQd6+885bfYY4tv1r8qguQCQtXXCcwXJo7a0wtEFEWD9sZO9ZM8 eMLa+8jtGsIzDBLiotZGgOW9j416hqE5F25haQbKq6brIGeo46CqmU4PcLrDk1Ri UbjoX7MzddMqlVHzaLl4o8195Jl0H3zARi5r2MU7Qb32OEJvu00= =3sv2 -----END PGP SIGNATURE----- -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2022-02-16 19:13 +0100 |
| Message-ID | <20220216191307.0fd4d19e@ryz> |
| In reply to | #5133 |
Am Mittwoch, 16. Februar 2022, um 16:48:45 Uhr schrieb Dan Purgert: > Last time I had a "whole home gateway" from the ISP, it'd give a > completely separate /64 to the "Guest WiFi" (if v6 was enabled on it). That is the best practice, but sometimes not possible because the customer only gets /64 at all.
[toc] | [prev] | [next] | [standalone]
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
Back to top | Article view | comp.os.linux.networking
csiph-web