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 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2022-02-10 19:15 +0000 |
| Message-ID | <slrnt0ap4h.5ru.dan@djph.net> |
| In reply to | #5033 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Grant Taylor wrote: > Remember, port forwarding -- which is a thing in IPv6 -- is at it's > roots NAT. There are definitely uses for port forwarding in IPv6. Although you need neither port-forwarding nor NAT on v6... -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmIFZJEACgkQbWVw5Uzn KGA8BhAAhvn+i4wCFJYSUUcL3N+xW7WGGpFP0+ve3OGIjK84zg+JIXg8Oz9KnBgh hvt+9crO/AjXNOfHBZtR9DYmjYMv3PO+LADRojX6u1kcqco61XTuBsamATswbnCq VIzu4aoX4rtWKHN0b2SuTzZnHUCvsQHWfCoHJIW3hzX6jItmAApyVjPvt3WSdG+1 AGPja425+3LDhpDYeUsw591jjXMSmvFaxHJdPlBrymc5oLRlQfPNsJEbz4hx7x27 lW1EhQ1QmY38312NfpjyF0fI6NogC8EiVZwrWVjb5ClMstyZN7uZTo7qZ3OG/TTI Sq3Af/NxMwLVAOEPijbcPX4G9cHYDdcekhneQxBstJxM13qBho1+Vcc4t9wB2gwj J2muZKdaOvlNx1Sl0437QL7L0vU57oFt1Vrctzhcs63ckY7haZQvy9aT9IGV99W3 Vo95UA1GudmJtNsFDe5GcE/k91WIgGhGz0P1bm+q/w3r9ynv/NpOej4sU2YsqOaR /4/S4j5ibUTyh2Xqkcy6ZDzvzqTO8rwrMKgTwHGiVkC2xCQwzjNuIaXP9lQKYxgw Qn7KByJgd8E/8JzZjnOK24LVaziSO2TkcPdcVpgnSCnAEVgqrXIi0norm+jibblU S469k/79rAgGQZ9NUTFDcDoPOFRbMcmdF4q4jlFeqVNiGvrclN4= =5ndj -----END PGP SIGNATURE----- -- |_|O|_| Github: https://github.com/dpurgert |_|_|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860 |O|O|O|
[toc] | [prev] | [next] | [standalone]
| From | Grant Taylor <gtaylor@tnetconsulting.net> |
|---|---|
| Date | 2022-02-10 12:44 -0700 |
| Message-ID | <su3pvb$3r2$1@tncsrv09.home.tnetconsulting.net> |
| In reply to | #5037 |
On 2/10/22 12:15 PM, Dan Purgert wrote: > Although you need neither port-forwarding nor NAT on v6... Maybe. Maybe not. It depends on the network topology and other layers of the stack, including layers 8 (politics) and 9 (money) influence this. -- Grant. . . . unix || die
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2022-02-10 21:34 +0100 |
| Message-ID | <20220210213434.61aa8729@ryz> |
| In reply to | #5039 |
Am Donnerstag, 10. Februar 2022, um 12:44:56 Uhr schrieb Grant Taylor: > On 2/10/22 12:15 PM, Dan Purgert wrote: > > Although you need neither port-forwarding nor NAT on v6... > > Maybe. Maybe not. > > It depends on the network topology and other layers of the stack, > including layers 8 (politics) and 9 (money) influence this. If you like to have more work (NAT is annoying if using DNS names inside and outside of the NAT net), then you can set up NAT for IPv6. I like the easy way that means no NAT at all whenever possible. Network is one of the things that last very long, so I don't like nasty stuff like NAT there.
[toc] | [prev] | [next] | [standalone]
| From | Grant Taylor <gtaylor@tnetconsulting.net> |
|---|---|
| Date | 2022-02-10 14:01 -0700 |
| Message-ID | <su3ue0$gm5$1@tncsrv09.home.tnetconsulting.net> |
| In reply to | #5042 |
On 2/10/22 1:34 PM, Marco Moock wrote: > If you like to have more work (NAT is annoying if using DNS names > inside and outside of the NAT net), then you can set up NAT for IPv6. I don't agree that NAT for IPv6 is itself, nor causes, more work. But we've likely had different use cases. > I like the easy way that means no NAT at all whenever possible. > > Network is one of the things that last very long, so I don't like > nasty stuff like NAT there. Fair enough. To each their own. I personally think that NAT can be ~> is a useful tool. However, the tool MUST be used appropriately. Any and all tools can be abused in ways that make life more difficult. -- Grant. . . . unix || die
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2022-02-11 14:22 +0100 |
| Message-ID | <su5nu5$47b4$1@news1.tnib.de> |
| In reply to | #5045 |
Grant Taylor <gtaylor@tnetconsulting.net> wrote: >On 2/10/22 1:34 PM, Marco Moock wrote: >> If you like to have more work (NAT is annoying if using DNS names >> inside and outside of the NAT net), then you can set up NAT for IPv6. > >I don't agree that NAT for IPv6 is itself, nor causes, more work. But >we've likely had different use cases. I agree with Marco. Probably you have become so intimate with NAT and the other crutches we need to keep v4 alive that you're dearly missing them when they're not needed. Such people do exist. >I personally think that NAT can be ~> is a useful tool. For v4, yes. IPv6 was carefully crafted not to need it. 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-11 11:27 -0700 |
| Message-ID | <su69pt$haj$1@tncsrv09.home.tnetconsulting.net> |
| In reply to | #5060 |
On 2/11/22 6:22 AM, Marc Haber wrote: > Probably you have become so intimate with NAT and the other crutches > we need to keep v4 alive that you're dearly missing them when they're > not needed. I don't think so. > For v4, yes. IPv6 was carefully crafted not to need it. The thing that IPv6 has over IPv4 is the number of IP addresses. But /utilizing/ those IP addresses brings inherent problems, not the least of which is additional routing burden. Consider the use case of what I call the "Customer Interface Router". Picture any business wherein each location is locally owned while having some loose affiliation with a corporate entity with different owners. A very good example is car dealerships affiliated with a major brand or service company. Wherein each individual location administers their network with complete autonomy and corporate administers it's network with complete autonomy. With that large topology in mind, consider the potential, nay likely, complications with needing to establish bi-directional communications between every single location and the corporate entity such that systems at corporate can print to the networked printer in the parts department. The C.I.R. functions as an integration between each individual location and corporate. NAT makes this trivial to do. Corproate sends traffic to the C.I.R. which translates what's necessary for each individual site's local network. Similarly each local site sends traffic to the C.I.R. which translates what's necessary to interface with corporate. Corporate doesn't have to worry about (de)conflicting subnets across multiple sites. Local stores don't need to worry about (de)conflicting subnets with coroprate, much less other stores. Neither corporate nor local stores need to propagate route information for each other's networks. Corporate sends traffic to 192.0.<site #>.<printer #> to print orders in the aprts department. The local manager connects to 198.51.100.<server #> to access corproate's vehicle inventory system. The NAT on the C.I.R. acts as an abstraction alyer allowing each side to operate with almost complete autonomy from each other. I asy almost because nominally each side can't have the /same/ subnet. However, even taht can be accomodated by using two C.I.R.s back to back to do double translation. I have written this email using IPv4 addresses because they are simpler / shorter to type (and more mussle memory). But the exact same concept applies to IPv6 as it does to IPv4. The underlying issue is only compounded if you try to add another entity to this scenario, say an external financing company or insurance company. Each additional entity that needs to be integrated adds complexity to /routed/ IP addresses at an exponential rate. Conversely NATing C.I.R.s scale linearly. The Customer Interface Router is only one scenario. I've run into other more exhotic scenarios wherein I needed (as in didn't have a choice) to have the same subnet in two different locations that couldn't actually sahre the subnet (TL;DR: D.R. environment replicating part of corporate) where each saw the other side as different subnets so that the could have routed communications. Linux's net-map IPTables target (prefix translation) made this ... possible. Backups of servers from one side could be restored on the other side without readdressing or any other changes and they could still communicate with what they needed to communicate with. Aside: I'd say the IP part was trivial, but the other parts of the stack were anything but trivial. So ... Network Address Translation is a /valuable/ tool to have in the tool box and it has far more uses than what most people think of. Just because the most common use is to allow private IPv4 addresses to share a single public IPv4 address doesn't mean that it's the /only/ use. To directly reply to your opening comment: > Probably you have become so intimate with NAT and the other crutches > we need to keep v4 alive that you're dearly missing them when they're > not needed. Nope. NAT actually *SIGNIFICANTLY* simplifies many of the different networks that I've helped administer over the last 20 years. The C.I.R. is one of the simpler examples. Getting Microsoft's Active Directory Domain Controllers to be happy thinking that each is in the same subnet when they are not, for DR purposes, is another use case for NAT (prefix translation). These are things that can't easily be done with actual routed IP addresses, irrespective of if they are IPv4 or IPv6. Aside: The reason for the DR configuration was so that there could be a production Active Directory Domain Controller in the D.R. environment that was always online and replicating with the production corporate network. The D.R. side /needed/ to have the same IP addresses as the production side so that production (member) servers could be restored without modification and /just/ /work/. But the D.R. and production networks couldn't be connected as a L2 environment for many reasons. Not the least of which is that production had to be online at the same time various D.R. tests were happening. The simplest solution was to let each side think that it was the network it was configured for and to lie to it about what the other side's network was. Thus each side would send traffic to the other side's fake IP address, NAT would happen in the middle to actually estabish the communications. It worked wonderfuly well. Further Aside: I challange you to explain to me how routed addresses, IPv4 or IPv6, can work as well as NAT does in either the C.I.R. or D.R. environment. -- Grant. . . . unix || die
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2022-02-12 10:49 +0100 |
| Message-ID | <su7vr5$82it$1@news1.tnib.de> |
| In reply to | #5063 |
Grant Taylor <gtaylor@tnetconsulting.net> wrote: >On 2/11/22 6:22 AM, Marc Haber wrote: >> For v4, yes. IPv6 was carefully crafted not to need it. > >The thing that IPv6 has over IPv4 is the number of IP addresses. But >/utilizing/ those IP addresses brings inherent problems, not the least >of which is additional routing burden. This is utter B.S. Routing Tables with IPv6 are significantly shorter than with IPv4 in all but the most basic setups. The way greater address space allows for smart address planning and much better aggregation of routes. You get rid of all crutches the v4 needs to be still usable. Since all LAN segments have a /64 prefix, you stop having to worry about prefix length. >Picture any business wherein each location is locally owned while having >some loose affiliation with a corporate entity with different owners. A >very good example is car dealerships affiliated with a major brand or >service company. Wherein each individual location administers their >network with complete autonomy and corporate administers it's network >with complete autonomy. With that large topology in mind, consider the >potential, nay likely, complications with needing to establish >bi-directional communications between every single location and the >corporate entity such that systems at corporate can print to the >networked printer in the parts department. The C.I.R. functions as an >integration between each individual location and corporate. You'd have two address spaces in each LAN segment at the car dealerships. One prefix for Internet access with local breakout, the other assigned by the brand. Applications can choose which address to use, leaving the rest of the burden to the network components. That's WAY easier than with IPv4. What makes those things complicated is people clinging to their IPv4-based procedures. >NAT makes this trivial to do. quod erat demonstrandum. >Corporate doesn't have to worry about (de)conflicting subnets across >multiple sites. They don't, because with IPv6 there are no conflicting subnets. >The NAT on the C.I.R. acts as an abstraction alyer allowing each side to >operate with almost complete autonomy from each other. That works differently with IPv6. One needs to learn that and let go of IPv4 mechanisms. >I have written this email using IPv4 addresses because they are simpler >/ shorter to type (and more mussle memory). How many IP address do you have to type when sending mail? Btw, this is not mail. > But the exact same concept >applies to IPv6 as it does to IPv4. No, it isn't. The concepts are very different. And when one rejects IPv6 because it isn't IPv4 one will have to pay a price. rest deleted, it's not worth spending time with one who clearly lives in the past and refuses to adapt. -- -------------------------------------- !! 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 | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2022-02-13 19:43 +0000 |
| Message-ID | <slrnt0inq7.1rfm.grahn+nntp@frailea.sa.invalid> |
| In reply to | #5042 |
On Thu, 2022-02-10, Marco Moock wrote: > Am Donnerstag, 10. Februar 2022, um 12:44:56 Uhr schrieb Grant Taylor: > >> On 2/10/22 12:15 PM, Dan Purgert wrote: >> > Although you need neither port-forwarding nor NAT on v6... >> >> Maybe. Maybe not. >> >> It depends on the network topology and other layers of the stack, >> including layers 8 (politics) and 9 (money) influence this. > > If you like to have more work (NAT is annoying if using DNS names > inside and outside of the NAT net), then you can set up NAT for IPv6. NAT tends to be not only more work but also worse functionality. I'm mainly thinking of how NAT keeps state in the routers, and that home routers tend to drop the state after a while so that e.g. long-lived TCP sessions tend to silently stop working. > I like the easy way that means no NAT at all whenever possible. > > Network is one of the things that last very long, so I don't like nasty > stuff like NAT there. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2022-02-13 21:14 +0100 |
| Message-ID | <20220213211414.48e14334@ryz> |
| In reply to | #5094 |
Am Sonntag, 13. Februar 2022, um 19:43:03 Uhr schrieb Jorgen Grahn: > NAT tends to be not only more work but also worse functionality. I'm > mainly thinking of how NAT keeps state in the routers, and that home > routers tend to drop the state after a while so that e.g. long-lived > TCP sessions tend to silently stop working. Full ack. That is the reason for unnecessary "keep-alive" packages many applications send.
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2022-02-14 08:47 +0100 |
| Message-ID | <sud1en$h6kr$1@news1.tnib.de> |
| In reply to | #5095 |
Marco Moock <mo01@posteo.de> wrote: >Am Sonntag, 13. Februar 2022, um 19:43:03 Uhr schrieb Jorgen Grahn: > >> NAT tends to be not only more work but also worse functionality. I'm >> mainly thinking of how NAT keeps state in the routers, and that home >> routers tend to drop the state after a while so that e.g. long-lived >> TCP sessions tend to silently stop working. > >Full ack. >That is the reason for unnecessary "keep-alive" packages many >applications send. And then there are the application that need constant pampering and additional crutches to work through nat, and probably still lose significant parts of their functionality even if all crutches are properly in place. Those are such unimportant protocols like ftp and SIP/RTP. Heck, who wants telephony anyway?!? Greetings Marc, currently cursed with an unreliable telephone because of NAT -- -------------------------------------- !! 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-15 11:48 -0700 |
| Message-ID | <sugshg$73a$1@tncsrv09.home.tnetconsulting.net> |
| In reply to | #5094 |
On 2/13/22 12:43 PM, Jorgen Grahn wrote: > NAT tends to be not only more work but also worse functionality. > I'm mainly thinking of how NAT keeps state in the routers, and > that home routers tend to drop the state after a while so that > e.g. long-lived TCP sessions tend to silently stop working. That's /stateful/ NAT. There is also the older /stateless/ NAT that does not have this problem. -- Grant. . . . unix || die
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2022-02-15 20:08 +0100 |
| Message-ID | <20220215200846.54434d76@ryz> |
| In reply to | #5109 |
Am Dienstag, 15. Februar 2022, um 11:48:30 Uhr schrieb Grant Taylor: > That's /stateful/ NAT. There is also the older /stateless/ NAT that > does not have this problem. I know and stateless NAT64 is a nice feature to make servers reachable via IPv6 without configuring the entire network, e.g. when implementing IPv6 is difficult in the current network infrastructure. It think it will also be used in future for making IPv6-only servers reachable via IPv4.
[toc] | [prev] | [next] | [standalone]
| From | Grant Taylor <gtaylor@tnetconsulting.net> |
|---|---|
| Date | 2022-02-15 12:19 -0700 |
| Message-ID | <sugub1$ia2$3@tncsrv09.home.tnetconsulting.net> |
| In reply to | #5113 |
On 2/15/22 12:08 PM, Marco Moock wrote: > I know and stateless NAT64 I was referring to stateless NAT44. E.g. prefix translation; 192.0.2.x/24 <=> 198.51.100.x/24 -- Grant. . . . unix || die
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2022-02-15 21:09 +0100 |
| Message-ID | <20220215210950.3ba8891c@ryz> |
| In reply to | #5118 |
Am Dienstag, 15. Februar 2022, um 12:19:12 Uhr schrieb Grant Taylor: > On 2/15/22 12:08 PM, Marco Moock wrote: > > I know and stateless NAT64 > > I was referring to stateless NAT44. E.g. prefix translation; > 192.0.2.x/24 <=> 198.51.100.x/24 I know it exists, but what is the purpose of that? I have never seen that in productive networks yet.
[toc] | [prev] | [next] | [standalone]
| From | Grant Taylor <gtaylor@tnetconsulting.net> |
|---|---|
| Date | 2022-02-15 18:09 -0700 |
| Message-ID | <suhirp$5d1$1@tncsrv09.home.tnetconsulting.net> |
| In reply to | #5120 |
On 2/15/22 1:09 PM, Marco Moock wrote: > I know it exists, but what is the purpose of that? It does exactly what it says on the name-plate. There are some cases where you need to change the network prefix but not the last octet of an IP address. I used this for the scenario I described in the D.R. / MS AD / DNS comments. It's an uncommon, but not unheard of use case. It allows you to collapse many SNAT / DNAT rules down to two prefix translation rules. > I have never seen that in productive networks yet. I have a few times. -- Grant. . . . unix || die
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2022-02-10 20:43 +0000 |
| Message-ID | <slrnt0au84.5ru.dan@djph.net> |
| In reply to | #5039 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Grant Taylor wrote: > On 2/10/22 12:15 PM, Dan Purgert wrote: >> Although you need neither port-forwarding nor NAT on v6... > > Maybe. Maybe not. > > It depends on the network topology and other layers of the stack, > including layers 8 (politics) and 9 (money) influence this. To rephrase slightly -- The sheer number of available addresses is such that NAT is not an inherent requirement of setting up a new IPv6 network that is intended to communicate with the wider internet. This is in contrast to an IPv4 network, wherein the vast majority of devices will be configured for an address contained within RFC1918 space, and will therefore require NAT to communicate to the wider internet. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmIFeQQACgkQbWVw5Uzn KGCtpg/+Ndka5Mbyz3dyOLbJTtBp8ix5uFa6VURP1hU14B4yJY1ke1cdd2q8wHnE I6qvXekTaM4vixQ7r/jiDOR5LOAQHVDKGaXFNoEJbLq+KVN0hI6OKkVjEKdVjngq bgrjF67Unaj+C26+Nmu/jw7LbVj/muz+aLeqVS9EB/anhDE+vfbVmCzUazpXi+or SdXF3kmLAiOtc2FHLNcFarJe+hLZ7aN86MzI4k0e5WnJKzHPIKu6g6Al2mL9B/8z IW3b2DJQVjWNmud0+R7hSkIKbPo5FdN3fcrKc5ZGYyrROGNbfUeS29MovvLFuDpF WxAAEPScmyGOC2drTiY+5VhHpMCMmBvpXASzVtIuzbGx6rfKRNaG9ihDFcIEt36a 6xxCB97GQMz9P0luD+m7oKkoQIZyGtefPgVkgSmMZSP+I/zfwqItfB93KVdo6KDt Ucd3TiY+gbb/27068rI78oWn5Yc1x3X5eWNsObQfWe/GzG8ake5J7kVbZ7nwf1wQ yGMSIGYzUurRVAVRfK+rLsRyg6Vqyl5SYuShr1XtULCo26b7b+DVNLimvgCKfQeA PbezGqYnOvKxSvD5wIZb5YsOlbRYm8x0GTpnakZGz923eZbjTtR1MX6r4oK5mLiL 6g6eHEBKE7WlUX+lInLUkcZJT0Tsl7GrpuM7IrVjRWbs26iH+iY= =GC+X -----END PGP SIGNATURE----- -- |_|O|_| Github: https://github.com/dpurgert |_|_|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860 |O|O|O|
[toc] | [prev] | [next] | [standalone]
| From | Grant Taylor <gtaylor@tnetconsulting.net> |
|---|---|
| Date | 2022-02-10 14:06 -0700 |
| Message-ID | <su3unv$th6$1@tncsrv09.home.tnetconsulting.net> |
| In reply to | #5043 |
On 2/10/22 1:43 PM, Dan Purgert wrote: > To rephrase slightly -- ;-) Clarifying points are a good thing for discussions. :-D > The sheer number of available addresses is such that NAT is not an > inherent requirement of setting up a new IPv6 network that is intended > to communicate with the wider internet. I absolutely agree. I have considerably more uses for NAT than /just/ the number of globally routed IP addresses I have at my disposal. > This is in contrast to an IPv4 network, wherein the vast majority of > devices will be configured for an address contained within RFC1918 > space, and will therefore require NAT to communicate to the wider > internet. /me chuckles menacingly to himself. RFC 1918. There are a LOT of other non-globally routed addresses that can be used. Then there are the globally routed IP addresses that can be stomped on. }:-) -- Grant. . . . unix || die
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2022-02-10 21:54 +0000 |
| Message-ID | <slrnt0b2e4.5ru.dan@djph.net> |
| In reply to | #5046 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Grant Taylor wrote: > On 2/10/22 1:43 PM, Dan Purgert wrote: >> [...] >> This is in contrast to an IPv4 network, wherein the vast majority of >> devices will be configured for an address contained within RFC1918 >> space, and will therefore require NAT to communicate to the wider >> internet. > > /me chuckles menacingly to himself. RFC 1918. There are a LOT of other > non-globally routed addresses that can be used. Then there are the > globally routed IP addresses that can be stomped on. }:-) Sure, but you understand the point I'm making with the ipv4 'private' networks here. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmIFicQACgkQbWVw5Uzn KGBuGRAAhvOUbDu2+TXKQahR7AApClfbrSMO8+OKqZf7utlR7us6tMRWVnSkWjMs EYP62Jz6KeLfLvyHFm921V5CEyAwhZhlbszUp3MgdByM5x5EMUBDaOCd2oYMykd6 rr8gvPo+AByE6t95VMgHzKWbVOjxfOVT/IibyQhS9TRcd3G2SSeVH1zFKTnbxJw4 kCrfRQI3UmLmD4B/V0pFD4xT4k6Rcy45YjvBD3G/pO78SBzUAzdcVDFDpmYFmdzs B6kTg3mdLkOZoADRXB5EBZkI6t1NwNxTscHz+ULRIQS1onO2yG7QUSMkMYKGU9ZQ 0bIuWB2H8BFceSvdn7iKJtEwrEN6RAZcZuYDRiOrnWucew5Wm8yHuTCgd5HIg5X/ GDtJy4jZhcNx1c0xuGtjvCrEcWIUNIoys3UDT9eIVeJ8nNiregmIsVYXLpDrNxfa /iLZGN/yMrbZVNfZotdpSJD15BhegtAXTeq2CSPlrThuoc30hH7NfFR2zI3uFlah 4xJzI5c1NVgtO/hbPBuqfpTgZFL9ISiOes/PDc/M9wtISwX/yEqMWkowJwgsDv3I UPDeZIm7AbRWibp3yJSXBnobZ4Xu/JGczd5dZgV390hZ4GY+ZlASIkXvKkkgJujt I2QAS/D6VEHtPn8xNrKoTbZUIWuNapqNtS2O6HWDw8PwC39GupM= =Hg+s -----END PGP SIGNATURE----- -- |_|O|_| Github: https://github.com/dpurgert |_|_|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860 |O|O|O|
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2022-02-11 14:22 +0100 |
| Message-ID | <su5nuu$47ba$1@news1.tnib.de> |
| In reply to | #5046 |
Grant Taylor <gtaylor@tnetconsulting.net> wrote: >There are a LOT of other >non-globally routed addresses that can be used. Which ones, for example? 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-11 14:34 +0100 |
| Message-ID | <20220211143446.4134c032@ryz> |
| In reply to | #5061 |
Am Freitag, 11. Februar 2022, um 14:22:38 Uhr schrieb Marc Haber: > Grant Taylor <gtaylor@tnetconsulting.net> wrote: > >There are a LOT of other > >non-globally routed addresses that can be used. > > Which ones, for example? IPv6 ULA IPv6 site-local (but deprecated) IPv6 link-local (no routing at all) IPv4 link-local (used for APIPA, no routing, 169.254.0.0/16) All not intended for connecting to other sites, only for internal stuff.
[toc] | [prev] | [next] | [standalone]
Page 2 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