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 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2022-02-16 19:15 +0000 |
| Message-ID | <slrnt0qjbl.idl.dan@djph.net> |
| In reply to | #5135 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Marco Moock wrote: > 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. Yes, the "customer" network only got one /64. If you enabled the "guest WiFi" on the device (again, supplied by the ISP), it got a completely separate /64. They finally allowed a modem-only option, so said ISP-supplied gateway has been returned & I'm using my own router; which can request a /56 or something like that. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmINTXQACgkQbWVw5Uzn KGDYSw/+P+DAiVfQsc1vDw4FKn4z0z5EqC0+UdY47BNtPocHRU//eIaFb1vhluXf U+FcSO9g9WGfZWFd7UcxDuNycf5nkqdc9Hs143xpM5SrKFKnHIvLVicB6G3bGyzI 0Xf6dxErhYDlyXarBc9Ml3Fgnzpj6SZCoxlIbYNA/vDqUNH9Nn/YphGTn1BSDJrA Hcm10eQ8f5gYeBbydXBixYl/3fRIbGOtg8iAUfCrcxaBHH2VSOsZ2iBWCLcJPdxQ 0Z+88jYcdzKIWURWeqIOYNndmxYYtvU8gJ/yoiEWtKU5eTwpH9SXZvylaSNNRYki nfxXtmL+mBPm8ju3TUueVgtzYJSWynOmiBVd8jYAnjY+vltNB/KdOcOrp5CWWvtI ZQz5ieXhIBrUR8fE4B+JkF++WfshyBB3MsiqBTkzfwJ0+vSpqt4ejBCw3m4B1wq7 62eu+YZo173SmdMR1QzLhGp7PXviUqPBK306n+5qpZSRi3nSzvRn4RW2VS1ev1GD JxsDaypbkD/LrUi5uo5Trp8gaMw17GsaDI7XoXQw0V079LTfJ6cJubmOt/4606yL nxKamEc4EubGX9na2Sb8Iqoxl7u0OnTrCCoLs9DDr7Sc9dN6vMVCUiFuFSq2KXAU ow6Bvklx6s59xkookKX1scuXrjI30tclLaaKs/Q36LIuDEMiEoQ= =je1Y -----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 | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2022-02-16 20:56 +0100 |
| Message-ID | <sujkt1$sg9c$1@news1.tnib.de> |
| In reply to | #5135 |
Marco Moock <mo01@posteo.de> wrote: >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. Thankfully, three VERY big residential ISPs in Germany (Deutsche Telekom, O2, 1&1) assign a /56 and offer prefix delegation to support nearly arbitrary subnetting¹ on customer site. Greetings Marc ¹ there are no subnets in IPv6, but you get the idea -- -------------------------------------- !! 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 | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2022-02-16 21:18 +0100 |
| Message-ID | <20220216211849.5c24bcb4@ryz> |
| In reply to | #5138 |
Am Mittwoch, 16. Februar 2022, um 20:56:17 Uhr schrieb Marc Haber: > ¹ there are no subnets in IPv6, but you get the idea Why there are no subnets in Ipv6? I can do subnetting just like with IPv4.
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2022-02-17 11:06 +0100 |
| Message-ID | <sul6ma$v6so$1@news1.tnib.de> |
| In reply to | #5143 |
Marco Moock <mo01@posteo.de> wrote: >Am Mittwoch, 16. Februar 2022, um 20:56:17 Uhr schrieb Marc Haber: > >> ¹ there are no subnets in IPv6, but you get the idea > >Why there are no subnets in Ipv6? >I can do subnetting just like with IPv4. Subnetting is terminology from classful IPv4 addressing. For example, 172.16.24.0/24 is a subnet of the class B network 172.16.0.0. In classless IP networking, there are just networks. The subnetting expression is unkillable just like the "Class C" for a /24, even if it's 10.0.2.0/24. Thankfully, noone says supernet any more. 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:27 -0700 |
| Message-ID | <sum0if$6tq$1@tncsrv09.home.tnetconsulting.net> |
| In reply to | #5148 |
On 2/17/22 3:06 AM, Marc Haber wrote: > Subnetting is terminology from classful IPv4 addressing. Chuckle. > For example, 172.16.24.0/24 is a subnet of the class B network > 172.16.0.0. Technically accurate. Though not many, including networking people, understand, much less can explain, what you have just staed. > In classless IP networking, there are just networks. Yes and no. Now you verge into nomenclature. Subnet is both the sub-network as described above and the widely accepted name for the particular network that is being discussed. Perhaps this is perpetuated by poor UI design and / or consistency with historic design. Whatever the reason, many people will tell you that 10.0.0.0/24 is the subnet that their router uses by default. > The subnetting expression is unkillable just like the "Class C" > for a /24, even if it's 10.0.2.0/24. Thankfully, noone says supernet > any more. I've taken to saying "Class C /Sized/" network. There are only so many windmills that I'm capable of tilting at. I tend to prefer to tilt at windmills that I feel that I can change. -- Grant. . . . unix || die
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2022-02-18 08:26 +0100 |
| Message-ID | <sunhm8$138gs$1@news1.tnib.de> |
| In reply to | #5151 |
Grant Taylor <gtaylor@tnetconsulting.net> wrote: >On 2/17/22 3:06 AM, Marc Haber wrote: >> Subnetting is terminology from classful IPv4 addressing. > >Chuckle. > >> For example, 172.16.24.0/24 is a subnet of the class B network >> 172.16.0.0. > >Technically accurate. Though not many, including networking people, >understand, much less can explain, what you have just staed. Many people still learn that in school and are actually required to reproduce that knowledge in exams. And then they begin working with real networks and we have to make them forget. Correct way to teach IP networks is to begin with IPv6, and then gradully add IPv4 and explain the crutches that IPv4 needs to still work. That way, people would not learn those crutches as being essential part of the protocol like they do today. >Whatever the reason, many people will tell you that 10.0.0.0/24 is the >subnet that their router uses by default. But it still is the network on the internal interface of the router. >> The subnetting expression is unkillable just like the "Class C" >> for a /24, even if it's 10.0.2.0/24. Thankfully, noone says supernet >> any more. > >I've taken to saying "Class C /Sized/" network. That sounds acceptable to me. I will still try to say "slash vierundzwanzig". >There are only so many >windmills that I'm capable of tilting at. I tend to prefer to tilt at >windmills that I feel that I can change. Wise. 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 | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2022-02-18 12:05 +0100 |
| Message-ID | <20220218120507.5cf1e822@ryz> |
| In reply to | #5155 |
Am Freitag, 18. Februar 2022, um 08:26:00 Uhr schrieb Marc Haber: > Many people still learn that in school and are actually required to > reproduce that knowledge in exams. And then they begin working with > real networks and we have to make them forget. Fully agree. I also "learn" that in school at this time. But subnetting itself is still needed for IPv6 for knowing about routing tables etc. Also, if you have a /56 from your provider, you mostly need to use /64 for your client nets, so you still do a process like subnetting/supernetting (for routing). > Correct way to teach IP networks is to begin with IPv6, and then > gradully add IPv4 and explain the crutches that IPv4 needs to still > work. That way, people would not learn those crutches as being > essential part of the protocol like they do today. True, but there are too many people that say "IPv6 isn't needed", "IPv6 isn't supported by all devices", "IPv4 is enough", "I don't know about IPv6" and some more bullshit.
[toc] | [prev] | [next] | [standalone]
| From | Grant Taylor <gtaylor@tnetconsulting.net> |
|---|---|
| Date | 2022-02-18 10:41 -0700 |
| Message-ID | <suolo0$tlb$1@tncsrv09.home.tnetconsulting.net> |
| In reply to | #5158 |
On 2/18/22 4:05 AM, Marco Moock wrote: > Also, if you have a /56 from your provider, you mostly need to > use /64 for your client nets, so you still do a process like > subnetting/supernetting (for routing). Yep. Also, remember, that the /64 is a convention as much as it is anything else. It's entirely possible to use something other than /64 for end user networks. The only thing that suffers when not using /64 is SLAAC. DHCP for IPv6 and / or static configuration works perfectly fine with something other than SLAAC. N.B. Despite what the IPv6 zealots want to believe, there is a LOT that DHCP for IPv6 offers that can't be done dynamically with SLAAC et al. DHCP provides a LOT of configuration information that end user systems use, particularly in SMB or larger enterprise networks. > True, but there are too many people that say "IPv6 isn't needed", > "IPv6 isn't supported by all devices", "IPv4 is enough", "I don't > know about IPv6" and some more bullshit. I can't point to anything that I want to do today that requires me to use IPv6. What's more, is if I had the addresses, I could do everything I do today with globally routed IPv4 addresses. I don't knowingly have any devices that don't support IPv6. My ISP only provides IPv4, so it must be sufficient. Correct? I can't effectively help people who choose to be wantonly ignorant. -- Grant. . . . unix || die
[toc] | [prev] | [next] | [standalone]
| From | Grant Taylor <gtaylor@tnetconsulting.net> |
|---|---|
| Date | 2022-02-18 10:43 -0700 |
| Message-ID | <suolr7$tlb$2@tncsrv09.home.tnetconsulting.net> |
| In reply to | #5160 |
On 2/18/22 10:41 AM, Grant Taylor wrote: > I can't point to anything that I want to do today that requires me to > use IPv6. > > ... > > My ISP only provides IPv4, so it must be sufficient. Correct? There is also the negative thing wherein I have to actively disable IPv6 for specific services for various reasons. - One of the streaming services that we use dislikes / blocks Hurricane Electric. - Some administrators ... choose to actively be hostile towards connections from IPv6. This rears it's ugly head the most in the email / SMTP world. -- Grant. . . . unix || die
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2022-02-18 20:20 +0100 |
| Message-ID | <20220218202053.55973253@ryz> |
| In reply to | #5160 |
Am Freitag, 18. Februar 2022, um 10:41:35 Uhr schrieb Grant Taylor: > N.B. Despite what the IPv6 zealots want to believe, there is a LOT > that DHCP for IPv6 offers that can't be done dynamically with SLAAC > et al. DHCP provides a LOT of configuration information that end user > systems use, particularly in SMB or larger enterprise networks. I agree, I tried out stateful DHCPv6 in a test environment with ULA addresses. With Ubuntu it works perfectly. Some parts are a little bit strange (device gets /128 address regardless of net). If the router advertisement includes the prefix of the net without the A flag set, the routing table correctly includes the net and the traffic for the prefix isn't being sent to the router and the back to the same link. Such stuff is very confusing for people that only use IPv4 DHCP.
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2022-02-18 20:34 +0100 |
| Message-ID | <suosbo$15g6c$1@news1.tnib.de> |
| In reply to | #5160 |
Grant Taylor <gtaylor@tnetconsulting.net> wrote: >N.B. Despite what the IPv6 zealots want to believe, there is a LOT that >DHCP for IPv6 offers that can't be done dynamically with SLAAC et al. >DHCP provides a LOT of configuration information that end user systems >use, particularly in SMB or larger enterprise networks. DHCPv6 does perfectly coexist with SLAAC. SLAAC provides basic connectivity, allowing management access. And then DHCPv6 comes in and statelessly provides additional operational data. 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-18 13:46 -0700 |
| Message-ID | <sup0ij$mne$1@tncsrv09.home.tnetconsulting.net> |
| In reply to | #5164 |
On 2/18/22 12:34 PM, Marc Haber wrote: > DHCPv6 does perfectly coexist with SLAAC. Yes and no. Yes they perfectly co-exist in a /64, presuming there aren't conflicts. No, they don't mix well when something other than a /64 is used in conjunction with DHCP. > SLAAC provides basic connectivity, allowing management access. And then > DHCPv6 comes in and statelessly provides additional operational data. If we apply Occam's Razor (the simpler solution is usually better) and Parsimony (we only need one solution) to the two possible solutions DHCP or DHCP+SLAAC, we quickly see that SLAAC is not /strictly/ necessary. -- Grant. . . . unix || die
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2022-02-19 10:03 +0100 |
| Message-ID | <suqbor$182e5$1@news1.tnib.de> |
| In reply to | #5168 |
Grant Taylor <gtaylor@tnetconsulting.net> wrote: >On 2/18/22 12:34 PM, Marc Haber wrote: >> DHCPv6 does perfectly coexist with SLAAC. > >Yes and no. > >Yes they perfectly co-exist in a /64, presuming there aren't conflicts. What kind of Conflicts do you mean? SLAAC has its own part of the /64, so does privacy extensions. Just stay on your own turf with DHCP and do not conflict. >No, they don't mix well when something other than a /64 is used in >conjunction with DHCP. Using something other than a /64 is applying IPv4 practices to IPv6. That's a decidedly bad idea. >> SLAAC provides basic connectivity, allowing management access. And then >> DHCPv6 comes in and statelessly provides additional operational data. > >If we apply Occam's Razor (the simpler solution is usually better) and >Parsimony (we only need one solution) to the two possible solutions DHCP >or DHCP+SLAAC, we quickly see that SLAAC is not /strictly/ necessary. SLAAC adds complexity. Stateless DHCPv6 removes more complexity than SLAAC adds. -- -------------------------------------- !! 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-19 17:03 -0700 |
| Message-ID | <sus0gi$2g3$1@tncsrv09.home.tnetconsulting.net> |
| In reply to | #5170 |
On 2/19/22 2:03 AM, Marc Haber wrote: > What kind of Conflicts do you mean? Different /64 prefixes. }:-) > Using something other than a /64 is applying IPv4 practices to IPv6. And yet this very thread has talked about /56 or even /48 from providers. Those aren't /64. > That's a decidedly bad idea. Let's agree to disagree. > SLAAC adds complexity. Stateless DHCPv6 removes more complexity than > SLAAC adds. So why is SLAAC actually /needed/ in a DHCPv6 environment? -- Grant. . . . unix || die
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2022-02-20 07:39 +0100 |
| Message-ID | <susnni$1c40m$1@news1.tnib.de> |
| In reply to | #5174 |
Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>On 2/19/22 2:03 AM, Marc Haber wrote:
>> What kind of Conflicts do you mean?
>
>Different /64 prefixes. }:-)
That's peaceful and working and desired parallel existence, not a
conflict.
>> Using something other than a /64 is applying IPv4 practices to IPv6.
>
>And yet this very thread has talked about /56 or even /48 from
>providers. Those aren't /64.
A /56 is 256 /64 networks. Noone with basic understanding would
configure a /56 on a single broadcast domain outside of a lab setting
("let's see whether it works, and if not, which color will the smoke
have?").
>> SLAAC adds complexity. Stateless DHCPv6 removes more complexity than
>> SLAAC adds.
>
>So why is SLAAC actually /needed/ in a DHCPv6 environment?
If you want to do stateless DHCPv6, you'd better have SLAAC.
The idea of having DHCPv6 without SLAAC is usually either born out of
IPv4 thinking or from Corporate "Security".
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 | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2022-02-20 08:52 +0100 |
| Message-ID | <20220220085236.293ccd8b@ryz> |
| In reply to | #5178 |
Am Sonntag, 20. Februar 2022, um 07:39:46 Uhr schrieb Marc Haber: > The idea of having DHCPv6 without SLAAC is usually either born out of > IPv4 thinking or from Corporate "Security". Or if you like that a computer gets a "specific" address and not one that it generates via privacy extensions (default in most OSes).
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2022-02-20 14:05 +0100 |
| Message-ID | <suteai$1dbf4$1@news1.tnib.de> |
| In reply to | #5182 |
Marco Moock <mo01@posteo.de> wrote: >Am Sonntag, 20. Februar 2022, um 07:39:46 Uhr schrieb Marc Haber: >> The idea of having DHCPv6 without SLAAC is usually either born out of >> IPv4 thinking or from Corporate "Security". > >Or if you like that a computer gets a "specific" address and not one >that it generates via privacy extensions (default in most OSes). I regularly run SLAAC with preferred lifetime 0. The machine will then generate an address and set it as deprecated, which means that this address is only used if there is no alternative. The static IP address for the service is either locally configured or pushed in via stateless DHCPv6. That makes sure the machine is at least reachable (and thus fixable) even if DHCP is broken. systemd-networkd even has a feature that allows local configuration of "in either prefix you have learned on that interface, statically configure THIS interface ID", which will guide the machine seamlessly even through prefix changes. I honestly don't know how privacy extension addresses play in here, but I'd expect that a privacy extension address on a prefix announced with lifetime zero is either not generated at all or deprecated from the very beginning. 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 | Roger Blake <rogblake@iname.invalid> |
|---|---|
| Date | 2022-02-20 22:50 +0000 |
| Message-ID | <20220220174921@news.eternal-september.org> |
| In reply to | #5178 |
On 2022-02-20, Marc Haber <mh+usenetspam1118@zugschl.us> wrote: > The idea of having DHCPv6 without SLAAC is usually either born out of > IPv4 thinking or from Corporate "Security". IPv4 thinking is the only thinking that counts as far as I am concerned. No IPv6 here, not now, not ever. -- ------------------------------------------------------------------------------ 18 Reasons I won't be vaccinated -- https://tinyurl.com/ebty2dx3 Covid vaccines: experimental biology -- https://tinyurl.com/57mncfm5 The fraud of "Climate Change" -- https://RealClimateScience.com There is no "climate crisis" -- https://climatedepot.com Don't talk to cops! -- https://DontTalkToCops.com ------------------------------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | jrg <jeff.g.group@att.net> |
|---|---|
| Date | 2022-02-20 18:10 -0800 |
| Message-ID | <suusb9$d1l$1@gioia.aioe.org> |
| In reply to | #5184 |
On 2/20/22 14:50, Roger Blake wrote: > On 2022-02-20, Marc Haber <mh+usenetspam1118@zugschl.us> wrote: >> The idea of having DHCPv6 without SLAAC is usually either born out of >> IPv4 thinking or from Corporate "Security". > > IPv4 thinking is the only thinking that counts as far as I am concerned. > No IPv6 here, not now, not ever. > get off the trump/fox news kool-aid, moron, and go back to school - if you knew what you were talking about, you'd be dangerous. Just because you can puke up that sig doesn't make you anything but a ripe target for Darwin's Law. So sorry, can't cure stupid.
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2022-02-21 08:16 +0100 |
| Message-ID | <suve8t$1gp69$1@news1.tnib.de> |
| In reply to | #5185 |
jrg <jeff.g.group@att.net> wrote: >So sorry, can't cure stupid. This. Thanks for saying that. -- -------------------------------------- !! 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]
Page 7 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