Privacy Extensions sind defekt

[Wuns Haerst]

https://heise.de/-7186203

Da kann ich schon verstehen, wieso man so lange an IPv4 hängt.
Ich nutze hinter einem CGN noch zuätzlich ein NAT, da kommt so
leicht keiner an meine wirkliche IP-Adresse.

[Marco Moock]

Am Freitag, 22. Juli 2022, um 06:05:24 Uhr schrieb Wuns Haerst:

> Da kann ich schon verstehen, wieso man so lange an IPv4 hängt.
> Ich nutze hinter einem CGN noch zuätzlich ein NAT, da kommt so
> leicht keiner an meine wirkliche IP-Adresse.

Was kaum Relevanz hat, denn aufgrund von Proxyservern und NAT haben
sich Webmaster andere Möglichkeiten gesucht, z.B. Cookies.

Zudem hat das mit IPv6 nichts zu tun, denn das gleiche Problem besteht
auch mit IPv4. Und wenn du bei IPv6 NAT machen willst, auch das ist
kein Problem.

[Wuns Haerst]

Am 22.07.2022 um 10:38 schrieb Marco Moock:
> Am Freitag, 22. Juli 2022, um 06:05:24 Uhr schrieb Wuns Haerst:
>
>> Da kann ich schon verstehen, wieso man so lange an IPv4 hängt.
>> Ich nutze hinter einem CGN noch zuätzlich ein NAT, da kommt so
>> leicht keiner an meine wirkliche IP-Adresse.
>
> Was kaum Relevanz hat, denn aufgrund von Proxyservern und NAT haben
> sich Webmaster andere Möglichkeiten gesucht, z.B. Cookies.

Kaum Privat-Nutzer verwenden irgendwelche Proxy-Server. IPv6 ist
hier einfach das Problem bzw. an der Stelle halt ein mangelhaftes
Protokoll.

> Zudem hat das mit IPv6 nichts zu tun, denn das gleiche Problem

> besteht auch mit IPv4. ...

Ne, mit CGN bin ich da so gut wie auf der sicheren Seite.
Hab ich das mit IPv6 auch? Ne, also: => Tonne.

[Marco Moock]

Am Freitag, 22. Juli 2022, um 13:45:30 Uhr schrieb ein Dummschwätzer:

> Am 22.07.2022 um 10:38 schrieb Marco Moock:
> > Am Freitag, 22. Juli 2022, um 06:05:24 Uhr schrieb Wuns Haerst:
> >
> >> Da kann ich schon verstehen, wieso man so lange an IPv4 hängt.
> >> Ich nutze hinter einem CGN noch zuätzlich ein NAT, da kommt so
> >> leicht keiner an meine wirkliche IP-Adresse.
> >
> > Was kaum Relevanz hat, denn aufgrund von Proxyservern und NAT haben
> > sich Webmaster andere Möglichkeiten gesucht, z.B. Cookies.
>
> Kaum Privat-Nutzer verwenden irgendwelche Proxy-Server. IPv6 ist
> hier einfach das Problem bzw. an der Stelle halt ein mangelhaftes
> Protokoll.

Diese sind der einer der Gründe, warum eine IP eben nicht ausreicht, um
eine Person zu identifizieren. Einige Provider haben früher für die
Kunden solche betrieben bzw. tun das noch heute. In Unternehmensnetzen
sind Proxies auch normal.
Auch wenn du meinst, durch Wiederholung wird es richtiger, auch bei
IPv6 kann man NAT machen, wenn man will.
Das ist kein Mangel an IPv6. Zudem kann man die Autokonfiguration
einfach am Router abstellen, dann macht der Rechner die gar nicht erst.
Automatische Vergabe kann man dann mit DHCPv6 machen und alle paar
Minuten ne neue IP vergeben.

Ich kann sowas, bei dir weiß ich es nicht.

> > Zudem hat das mit IPv6 nichts zu tun, denn das gleiche Problem
> > besteht auch mit IPv4. ...
>
> Ne, mit CGN bin ich da so gut wie auf der sicheren Seite.
> Hab ich das mit IPv6 auch? Ne, also: => Tonne.

Und noch viel besser: Früher oder später kannst du viele Dienste nicht
mehr erreichen und uns nicht mehr vollmüllen.

Auch CG-NAT geht bei IPv6, aber kein Provider wird das machen, weil er
keine Lust auf den Aufwand hat.

[Marco Moock]

Am Freitag, 22. Juli 2022, um 11:53:17 Uhr schrieb Thomas Noll:

> Am Fri, 22 Jul 2022 10:38:46 +0200 schrieb Marco Moock:
>
>
> > Zudem hat das mit IPv6 nichts zu tun, denn das gleiche Problem
> > besteht auch mit IPv4.
>

> Nein. Bei IPv4 wird die komplette Adresse getauscht, du bist anhand
> der Adresse nicht von jemanden zu unterscheiden, der sie vorher hatte.
> Bei IPv6 wird im beschriebenen Szenar der neue Prefix über _einen_
> konstanten Interface-Indentifier mit dem alten verknüpft.

Das ist erwartetes, wenn man EUI-64 macht bzw. stabile Privatsphäre
zusätzlich zu den Privacy-Extensions aktiv hat.
Ist alles Einstellungssache. Dazu kommt, dass es bei HTTP noch viele
weitere Identifikationsmerkmale gibt und diese auch genutzt, ggf.sogar
präferiert werden.

Wer also im browser Cookies aktiv hat und nicht automatisch löschen
lässt ist weiterhin identifizierbar.

[Thomas Klix]

Lass mich raten: 192.168.178.20?

Thomas

[Juergen Ilse]

Hallo,

In de.comp.security.misc Wuns Haerst <Wuns....@wurstfabrik.at> wrote:
> Am 22.07.2022 um 10:38 schrieb Marco Moock:
>> Am Freitag, 22. Juli 2022, um 06:05:24 Uhr schrieb Wuns Haerst:
>>
>>> Da kann ich schon verstehen, wieso man so lange an IPv4 hängt.
>>> Ich nutze hinter einem CGN noch zuätzlich ein NAT, da kommt so
>>> leicht keiner an meine wirkliche IP-Adresse.
>>
>> Was kaum Relevanz hat, denn aufgrund von Proxyservern und NAT haben
>> sich Webmaster andere Möglichkeiten gesucht, z.B. Cookies.
>
> Kaum Privat-Nutzer verwenden irgendwelche Proxy-Server. IPv6 ist
> hier einfach das Problem bzw. an der Stelle halt ein mangelhaftes
> Protokoll.

Tut mir leid, aber ich verstehe nichht, inwiefern IPv6 ein mangelhaftes
Protokoll sein soll. Bei dnamisch vergebenen IPv6 Pefixen (bei Privat-
kunenanschluessen ueblich), muss mman als User doch nur die PPP-Verbindung
kurz kappen, und bekommt dann ein neues Prefix zugewiesen (wie man bei
Kabel ggfs. einen Prefix-Wechsel erzwingen kann, weiss ich nicht, aber
vermutlich gibt es da auch eine Moeglichkeit), und die privac extensions
sorgen dafuer, dass auch keine dauerhhafte Identifizierung ueber den
local part der IP-Adresse moeglich ist.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Juergen Ilse]

Hallo,

In de.comp.security.misc Marco Moock <mo...@posteo.de> wrote:
> Am Freitag, 22. Juli 2022, um 13:45:30 Uhr schrieb ein Dummschwätzer:
>
>> Am 22.07.2022 um 10:38 schrieb Marco Moock:
>> > Am Freitag, 22. Juli 2022, um 06:05:24 Uhr schrieb Wuns Haerst:
>> >
>> >> Da kann ich schon verstehen, wieso man so lange an IPv4 hängt.
>> >> Ich nutze hinter einem CGN noch zuätzlich ein NAT, da kommt so
>> >> leicht keiner an meine wirkliche IP-Adresse.
>> >
>> > Was kaum Relevanz hat, denn aufgrund von Proxyservern und NAT haben
>> > sich Webmaster andere Möglichkeiten gesucht, z.B. Cookies.
>>
>> Kaum Privat-Nutzer verwenden irgendwelche Proxy-Server. IPv6 ist
>> hier einfach das Problem bzw. an der Stelle halt ein mangelhaftes
>> Protokoll.
>
> Diese sind der einer der Gründe, warum eine IP eben nicht ausreicht, um
> eine Person zu identifizieren. Einige Provider haben früher für die
> Kunden solche betrieben bzw. tun das noch heute. In Unternehmensnetzen
> sind Proxies auch normal.

Stimmt.

> Auch wenn du meinst, durch Wiederholung wird es richtiger, auch bei
> IPv6 kann man NAT machen, wenn man will.

I.a. aber kein PAT, wie es ueblicherweise bei CGN und Masquerading auf
dem eigenen Router passiert ...

> Das ist kein Mangel an IPv6. Zudem kann man die Autokonfiguration
> einfach am Router abstellen, dann macht der Rechner die gar nicht erst.
> Automatische Vergabe kann man dann mit DHCPv6 machen und alle paar
> Minuten ne neue IP vergeben.

Wozu? Fuer regelmaessige Aenderung des locaalpart der Adresse fuer
ausgehende Verbindungen kann man mittels privacy extensions sorgen.
und die "feste" IPv6 Adresse ist praktisch unmoeglich zu erraten.
Scannen´ganzer Netzwerke ist bei IPv6 aufgrund der grossen Zahl der
Adressen in jedem Netz auch nicht praktikabel.

Tschuess,
Juergen Ilse (juergenqusenet-verwaltung.de)

[Juergen Ilse]

Hallo,

In de.comp.security.misc Thomas Noll <-_tn...@web.de> wrote:
> Am Fri, 22 Jul 2022 10:38:46 +0200 schrieb Marco Moock:
>
>

>> Zudem hat das mit IPv6 nichts zu tun, denn das gleiche Problem besteht
>> auch mit IPv4.
>

> Nein. Bei IPv4 wird die komplette Adresse getauscht, du bist anhand der
> Adresse nicht von jemanden zu unterscheiden, der sie vorher hatte.
> Bei IPv6 wird im beschriebenen Szenar der neue Prefix über _einen_
> konstanten Interface-Indentifier mit dem alten verknüpft.

Zur Verschleierung des local parts haben die Erfinder von IPv6 die
privac extensions erfunden.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Christian Weisgerber]

On 2022-07-22, Wuns Haerst <Wuns....@wurstfabrik.at> wrote:

> Subject: Privacy Extensions sind defekt

Aha.

> https://heise.de/-7186203

Der Artikel beschreibt das Gegenteil: Es ist die fehlende Verwendung
von temporären Adressen (oder den nicht erwähnten SOII-Adressen),
die eine Zuordnung von Endgeräten über Präfixwechsel hinweg erlaubt.

Das ist keine neue Erkenntnis: RFC 7217 (April 2014) beschreibt das
Problem schon am Rande. RFC 7721 (März 2016) widmet sich komplett
diesem Thema.

--
Christian "naddy" Weisgerber na...@mips.inka.de

[Marco Moock]

Am Freitag, 22. Juli 2022, um 15:22:08 Uhr schrieb Juergen Ilse:

> Wozu? Fuer regelmaessige Aenderung des locaalpart der Adresse fuer
> ausgehende Verbindungen kann man mittels privacy extensions sorgen.

Wobei das immer davon abhängt, was der Rechner macht. Die meisten
Systeme machen Privacy Extensions bei der Autokonfiguration.
Debian macht aber z.B. standardmäßig EUI-64. Schaltet man im
Router-Advertisement das A-Flag bei allen Präfixen ab und macht nur
DHCPv6, stellt man sicher, dass kein Gerät EUI-64 macht, sofern es sich
an die Standards hält.

[Paul Muster]

On 22.07.22 10:38, Marco Moock wrote:
> Am Freitag, 22. Juli 2022, um 06:05:24 Uhr schrieb Wuns Haerst:

>> Da kann ich schon verstehen, wieso man so lange an IPv4 hängt.
>> Ich nutze hinter einem CGN noch zuätzlich ein NAT, da kommt so
>> leicht keiner an meine wirkliche IP-Adresse.
>
> Was kaum Relevanz hat, denn aufgrund von Proxyservern und NAT haben
> sich Webmaster andere Möglichkeiten gesucht, z.B. Cookies.

Whataboutism.

> Zudem hat das mit IPv6 nichts zu tun, denn das gleiche Problem besteht
> auch mit IPv4.

Nein, besteht es nicht. Wie und wo wird über IPv4 die MAC-Adresse in die
große weite Welt transportiert? Hast du den Artikel gelesen und verstanden?

> Und wenn du bei IPv6 NAT machen willst, auch das ist
> kein Problem.

Macht nur keiner. Auch keine Fritzbox etc.


mfG Paul

[Paul Muster]

On 22.07.22 14:17, Marco Moock wrote:
> Am Freitag, 22. Juli 2022, um 11:53:17 Uhr schrieb Thomas Noll:

>> Nein. Bei IPv4 wird die komplette Adresse getauscht, du bist anhand
>> der Adresse nicht von jemanden zu unterscheiden, der sie vorher hatte.
>> Bei IPv6 wird im beschriebenen Szenar der neue Prefix über _einen_
>> konstanten Interface-Indentifier mit dem alten verknüpft.
>
> Das ist erwartetes, wenn man EUI-64 macht bzw. stabile Privatsphäre
> zusätzlich zu den Privacy-Extensions aktiv hat.
> Ist alles Einstellungssache.

"stabile Privatsphäre"?

Du hast schon verstanden, dass das Problem durch ein einziges, nicht
korrekt konfiguriertes oder gar nicht konfigurierbares Gerät im LAN
entsteht? Eines, das womöglich erst kürzlich unbemerkt durch ein autom.
Firmwareupdate (über IPv4) natives IPv6 bekommen hat, aber, weil die
Entwickler kleine Schritte machen, erstmal nur EUI-64 kann und Privacy
Extensions vielleicht irgendwann später mal.


mfG Paul

[Paul Muster]

On 22.07.22 17:15, Juergen Ilse wrote:

> Tut mir leid, aber ich verstehe nichht, inwiefern IPv6 ein mangelhaftes
> Protokoll sein soll. Bei dnamisch vergebenen IPv6 Pefixen (bei Privat-
> kunenanschluessen ueblich), muss mman als User doch nur die PPP-Verbindung
> kurz kappen, und bekommt dann ein neues Prefix zugewiesen (wie man bei
> Kabel ggfs. einen Prefix-Wechsel erzwingen kann, weiss ich nicht, aber
> vermutlich gibt es da auch eine Moeglichkeit), und die privac extensions
> sorgen dafuer, dass auch keine dauerhhafte Identifizierung ueber den
> local part der IP-Adresse moeglich ist.

Mal den Artikel lesen?


mfG Paul

[Juergen Ilse]

Hallp,

In de.comp.security.misc Marco Moock <mo...@posteo.de> wrote:

> Am Freitag, 22. Juli 2022, um 15:22:08 Uhr schrieb Juergen Ilse:
>
>> Wozu? Fuer regelmaessige Aenderung des locaalpart der Adresse fuer
>> ausgehende Verbindungen kann man mittels privacy extensions sorgen.
>
> Wobei das immer davon abhängt, was der Rechner macht. Die meisten
> Systeme machen Privacy Extensions bei der Autokonfiguration.
> Debian macht aber z.B. standardmäßig EUI-64.

Und das Setzen der sysctl Variablen "net.ipv6.conf.all.use_tempaddr" bzw.
der notwendigen "net.ipv6.conf.<interface>.use_tempaddr" ist zu kompliziert,
um privacy-extensions global oder nur auf bestimmten Interfaces anzu-
schalten?

> Schaltet man im Router-Advertisement das A-Flag bei allen Präfixen ab
> und macht nur DHCPv6, stellt man sicher, dass kein Gerät EUI-64 macht,
> sofern es sich an die Standards hält.

Warum so ein workaround, wenn doch das einschhalten von PE ausreicht?
Und ja, als Admin sollte man wissen, was das PE sind, und wie man sie
ggfs. aktiviert und/oder deaktiviert.

Tschuess,
Juergen ilse (jue...@usenet-verwaltung.de)

[Juergen Ilse]

Hallo,

Jetzt ja, und in meinen Augen strotzt der Artikel nur so von Halbwissen
und mangelndem Verstaendnis. Mit SAAC und PE werden i.d.R. *sowohl* EUI64
als auch temporaere IPv6 Adressen verwendet. Nur wird die EUI-64 Adresse
nicht fuer ausgehende Verbindungen verwechselt (sofern das Programm, das
die Verbindung oeffnet, explizit die EUI-64 Adresse bindet.

Es wird dort auch munter die Identifizierung des Prefix mit der Identifi-
zierung der IP-Adresse durchheinandergeworfen. In meinen Augen spricht
das weder gegen IPv6 noch gegen die Privac Extensions. Das man letztere
zur moeglichst weitgehenden Wahrung der Privatsphaere einschalten sollte,
duerfte unbestritten sein. Geraete, bei denen man das nichht kann, sollte
man in diesem Fall ggfs. vom Netz abklemmen. Die meisten neueren Geraete
haben die PE per Default aktiviert. Apple tat das bei den IPhones eine
zeit lang nichht 8bei aktuellen Geraeten sind AFAIK die PE per Default
aktiviert. Der Mangel besteht also weder im Protokoll noch in den PE
sondern in den Geraeten, die die passende Einstellung nichht zulassen.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Marco Moock]

Am Freitag, 22. Juli 2022, um 17:08:30 Uhr schrieb Juergen Ilse:

> Und das Setzen der sysctl Variablen "net.ipv6.conf.all.use_tempaddr"
> bzw. der notwendigen "net.ipv6.conf.<interface>.use_tempaddr" ist zu
> kompliziert, um privacy-extensions global oder nur auf bestimmten
> Interfaces anzu- schalten?

Das muss man dann überall machen (und darf es nicht vergessen) und
gerade bei IoT-Geräten oder Smart-TVs kommt man nicht an solche
Einstellungen ran.

[Marco Moock]

Am Freitag, 22. Juli 2022, um 18:17:15 Uhr schrieb Paul Muster:

> Du hast schon verstanden, dass das Problem durch ein einziges, nicht
> korrekt konfiguriertes oder gar nicht konfigurierbares Gerät im LAN
> entsteht? Eines, das womöglich erst kürzlich unbemerkt durch ein
> autom. Firmwareupdate (über IPv4) natives IPv6 bekommen hat, aber,
> weil die Entwickler kleine Schritte machen, erstmal nur EUI-64 kann
> und Privacy Extensions vielleicht irgendwann später mal.

Mir ist klar, dass dann durch das Präfix wiederum der Traffic der
anderen Nutzer identifizierbar wird.
Aber das ist wie gesagt erwartetes Verhalten. Ich vermute aber kaum,
dass das für die Identifizierung von Nutzern große Relevanz hat, da die
meisten Leute im browser Cookies aktiv haben und Telemetrie im
OS/Applikation an ist.

Und spezielle wenn Leute wie unser Troll "Hans" Windows nutzen, was
haufenweise Daten an den Hersteller sendet, mache ich mir über
Identifikation per IPv6-Adresse keine Gedanken.

[Juergen Ilse]

Hallo,

In de.comm.protocols.tcp-ip Marco Moock <mo...@posteo.de> wrote:
> Am Freitag, 22. Juli 2022, um 15:22:08 Uhr schrieb Juergen Ilse:
>> Wozu? Fuer regelmaessige Aenderung des locaalpart der Adresse fuer
>> ausgehende Verbindungen kann man mittels privacy extensions sorgen.
> Wobei das immer davon abhängt, was der Rechner macht. Die meisten
> Systeme machen Privacy Extensions bei der Autokonfiguration.

Nein. Die privacy extensions werden *niemals* fuer link local Adressen
verwendet (auf keinem System). Damit koennen die erst aktiv werden, wenn
ein IPv6 prefix festgelegt wurde (duch Konfiguration einer nicht
link local Adresse). Es ist dabei voellig wumpe, ob dies durch SLAAC,
DHCP6 oder manuelle Konfiguration passiert.

> Debian macht aber z.B. standardmäßig EUI-64.

Man formuliert das besser als "Debian hat per Default PE abgeschaltet".
Das laesst sich durch passendes setzen der entsprechenden "use_tempaddr"
SYSCTL Variablen aendern (wahlweise durch aendern der /etc/sysctl.conf,
was aber vermutlich ein Dist-Upgrade nichht ueberstehht, durch hinzu-
fuegen einer entsprechenden Datei in /etc/sysctl.d oder durch einen
passenden systctl Aufruf beim Systemstart).

> Schaltet man im
> Router-Advertisement das A-Flag bei allen Präfixen ab und macht nur
> DHCPv6, stellt man sicher, dass kein Gerät EUI-64 macht, sofern es sich
> an die Standards hält.

Das klingt eher nach "Holzhammer" als nach "Nutzung wie vorgesehen" ...

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Marco Moock]

Am Freitag, 22. Juli 2022, um 18:19:36 Uhr schrieb Paul Muster:

> Nein, besteht es nicht. Wie und wo wird über IPv4 die MAC-Adresse in
> die große weite Welt transportiert? Hast du den Artikel gelesen und
> verstanden?

Ja, aber wenn ich längere Zeit ne IPv4-Adresse (oder gar eine feste)
habe, brauche ich die MAC gar nicht erst. Zudem bieten einige Geräte
an, die MAC zufällig zu erzeugen.

> > Und wenn du bei IPv6 NAT machen willst, auch das ist
> > kein Problem.
>
> Macht nur keiner. Auch keine Fritzbox etc.

Das hat halt den Grund, dass NAT in der Netzwerktechnik einfach nur
nervt und man mit IPv6 ne Welt schaffen wollte, wo man es nicht
benötigt (aber nutzen kann). Sowas könnte man als
Hersteller implementieren und wenn man als Kunde solche Sonderwünsche
will muss man sich eben professionelle Hardware kaufen. Ne FritzBox
kann auch kein öffentliches IPv4-Netz ins interne Netz routen. VLAN
können die auch nicht. Es gibt unzählige Sachen, die SOHO-Geräte nicht
haben.

[Juergen Ilse]

Hallo,

In de.comp.security.misc Marco Moock <mo...@posteo.de> wrote:

> Am Freitag, 22. Juli 2022, um 18:17:15 Uhr schrieb Paul Muster:
>
>> Du hast schon verstanden, dass das Problem durch ein einziges, nicht
>> korrekt konfiguriertes oder gar nicht konfigurierbares Gerät im LAN
>> entsteht? Eines, das womöglich erst kürzlich unbemerkt durch ein
>> autom. Firmwareupdate (über IPv4) natives IPv6 bekommen hat, aber,
>> weil die Entwickler kleine Schritte machen, erstmal nur EUI-64 kann
>> und Privacy Extensions vielleicht irgendwann später mal.
>
> Mir ist klar, dass dann durch das Präfix wiederum der Traffic der
> anderen Nutzer identifizierbar wird.

Damit laesst sich ggfs. der Netzwerkprefix ermitteln. Wenn verschiedene
Geraete mit eingeschalteten PE im Netz vorhanden ist, kann man aus dem
Traffic dieses Netzwerks kein Traffic zu den Geraeten mit den enablten
PE genau dem Geraet zuordnen.

> Aber das ist wie gesagt erwartetes Verhalten. Ich vermute aber kaum,
> dass das für die Identifizierung von Nutzern große Relevanz hat, da die
> meisten Leute im browser Cookies aktiv haben und Telemetrie im
> OS/Applikation an ist.

Fuer die Identifizierung der User ist eine Kombination von Browser
Fingerprinting, Cookies, Flashcookies, ... i.a. einfacher und viel-
versprechender ...

> Und spezielle wenn Leute wie unser Troll "Hans" Windows nutzen, was
> haufenweise Daten an den Hersteller sendet, mache ich mir über
> Identifikation per IPv6-Adresse keine Gedanken.

... zumal in dem Artikel im wesentlichen nur die Identifikation des
Prefix beschrieben ist ...

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Juergen Ilse]

In de.comp.security.misc Marco Moock <mo...@posteo.de> wrote:

> Am Freitag, 22. Juli 2022, um 18:19:36 Uhr schrieb Paul Muster:
>
>> Nein, besteht es nicht. Wie und wo wird über IPv4 die MAC-Adresse in
>> die große weite Welt transportiert? Hast du den Artikel gelesen und
>> verstanden?
>
> Ja, aber wenn ich längere Zeit ne IPv4-Adresse (oder gar eine feste)
> habe, brauche ich die MAC gar nicht erst. Zudem bieten einige Geräte
> an, die MAC zufällig zu erzeugen.

Nicht die MAC sondern die Interface-ID (die auch zur Bildung der link local
Adresse verwendet wird).

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Marco Moock]

Am Freitag, 22. Juli 2022, um 17:43:30 Uhr schrieb Juergen Ilse:

> In de.comm.protocols.tcp-ip Marco Moock <mo...@posteo.de> wrote:
> > Am Freitag, 22. Juli 2022, um 15:22:08 Uhr schrieb Juergen Ilse:
> >> Wozu? Fuer regelmaessige Aenderung des locaalpart der Adresse fuer
> >> ausgehende Verbindungen kann man mittels privacy extensions
> >> sorgen.
> > Wobei das immer davon abhängt, was der Rechner macht. Die meisten
> > Systeme machen Privacy Extensions bei der Autokonfiguration.
>
> Nein. Die privacy extensions werden *niemals* fuer link local Adressen
> verwendet (auf keinem System). Damit koennen die erst aktiv werden,
> wenn ein IPv6 prefix festgelegt wurde (duch Konfiguration einer nicht
> link local Adresse). Es ist dabei voellig wumpe, ob dies durch SLAAC,
> DHCP6 oder manuelle Konfiguration passiert.

link-local habe ich jetzt hier absichtlich nicht erwähnt, weil diese eh
nicht geroutet werden und damit gegenüber dem Internet kein
Privatsphäreproblem darstellen.

> > Schaltet man im
> > Router-Advertisement das A-Flag bei allen Präfixen ab und macht nur
> > DHCPv6, stellt man sicher, dass kein Gerät EUI-64 macht, sofern es
> > sich an die Standards hält.
>
> Das klingt eher nach "Holzhammer" als nach "Nutzung wie vorgesehen"

Das stimmt.

[Marco Moock]

Am Freitag, 22. Juli 2022, um 18:02:56 Uhr schrieb Juergen Ilse:

> Damit laesst sich ggfs. der Netzwerkprefix ermitteln. Wenn
> verschiedene Geraete mit eingeschalteten PE im Netz vorhanden ist,
> kann man aus dem Traffic dieses Netzwerks kein Traffic zu den
> Geraeten mit den enablten PE genau dem Geraet zuordnen.

Genau, man hat dann einen ähnlichen Zustand wie bei IPv4-NAT.

[Juergen Ilse]

Hallo,

In de.comp.security.misc Marco Moock <mo...@posteo.de> wrote:

Genau das sollen die PE leisten, nur ohne die Erfordernis komplexer
ALGs, um aufwendigere Netzwerkprotokolle durch NAT durchzubekommen.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Marco Moock]

Am Freitag, 22. Juli 2022, um 18:05:02 Uhr schrieb Juergen Ilse:

> Nicht die MAC sondern die Interface-ID (die auch zur Bildung der link
> local Adresse verwendet wird).

Auch für die MAC-Adresse gibt es die Möglichkeit, diese automatisiert
zu generieren statt die zu nehmen, die in der Netzwerkkarte steht.
Bei Apple iOS ist das glaub auch standardmäßig aktiv.

Nutzt man dann EUI-64 steht da nicht die echte, sondern die generierte
MAC drin.

[Juergen Ilse]

In de.comp.security.misc Marco Moock <mo...@posteo.de> wrote:

> Am Freitag, 22. Juli 2022, um 18:05:02 Uhr schrieb Juergen Ilse:
>
>> Nicht die MAC sondern die Interface-ID (die auch zur Bildung der link
>> local Adresse verwendet wird).
>
> Auch für die MAC-Adresse gibt es die Möglichkeit, diese automatisiert
> zu generieren statt die zu nehmen, die in der Netzwerkkarte steht.

Das wird i.d.R. nicht gemacht. Wenn man es machhen wuerde, wuerde man
ueblicherweise den "private MAC Adress Range" dafuer verwenden, aber
wozu? Damit, wenn man das auf verschihedenen Geraeten im selben Netz
macht, die Gefahr einer MAC-Adress Kollision besteht (die dann zu
beliebig schwer zu diagnostierenden Problemen fuehren kann)?

> Bei Apple iOS ist das glaub auch standardmäßig aktiv.

Nein. Es wurden meines Wissens nach nur per Default die privacy extensions
eingeschhhaltet.

> Nutzt man dann EUI-64 steht da nicht die echte, sondern die generierte
> MAC drin.

Es ist voellig wumpe, ob der local part die MAC-Adresse enthaelt oder nicht,
wenn fuer ausgehhende Verbindungen immer nur eine temporaere IPv6 Adresse
verwendet wird, und somit i.d.R. der urspruengliche Interface-Identifier
nie nach draussen drringt ...

Hat denn niemand verstanden, dass bei Verwendung von SLAAC die PE nicht
*anstelle* von EUI-64 sondern *zusaetzlichh* zu EUI-64 verwendet werden?

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Marc SCHAEFER]

In de.comm.protocols.tcp-ip Juergen Ilse <ne...@usenet-verwaltung.de> wrote:
>> Auch für die MAC-Adresse gibt es die Möglichkeit, diese automatisiert
>> zu generieren statt die zu nehmen, die in der Netzwerkkarte steht.
>
> Das wird i.d.R. nicht gemacht. Wenn man es machhen wuerde, wuerde man
> ueblicherweise den "private MAC Adress Range" dafuer verwenden, aber
> wozu? Damit, wenn man das auf verschihedenen Geraeten im selben Netz
> macht, die Gefahr einer MAC-Adress Kollision besteht (die dann zu
> beliebig schwer zu diagnostierenden Problemen fuehren kann)?

Android macht es:

https://source.android.com/devices/tech/connect/wifi-mac-randomization-behavior

Es ist aber defaultmässig stateful (pro ESS).

[Paul Muster]

On 22.07.22 19:27, Juergen Ilse wrote:
> In de.comp.security.misc Paul Muster <exp-3...@news.muster.net> wrote:

>> Mal den Artikel lesen?
>
> Jetzt ja,

Gut. Ist eigentlich wie im Heise-Forum: Wenn man den Artikel nicht
liest, um den es geht, ihr aber trotzdem (negativ) kommentiert, blamiert
man sich mit recht hoher Wahrscheinlichkeit.

Dann jetzt bitte nochmal sorgfältig formulieren und vor dem Abschicken
korrekturlesen, denn....

> und in meinen Augen strotzt der Artikel nur so von Halbwissen
> und mangelndem Verstaendnis. Mit SAAC und PE werden i.d.R. *sowohl* EUI64
> als auch temporaere IPv6 Adressen verwendet. Nur wird die EUI-64 Adresse
> nicht fuer ausgehende Verbindungen verwechselt (sofern das Programm, das
> die Verbindung oeffnet, explizit die EUI-64 Adresse bindet.

...ich habe keine Ahnung, was von all den Fehlern in diesem Absatz nun
Tippfehler sind, was Schreibfehler und was Missverständnisse.


mfG Paul

[Paul Muster]

On 22.07.22 19:41, Marco Moock wrote:
> Am Freitag, 22. Juli 2022, um 18:17:15 Uhr schrieb Paul Muster:

>> Du hast schon verstanden, dass das Problem durch ein einziges, nicht
>> korrekt konfiguriertes oder gar nicht konfigurierbares Gerät im LAN
>> entsteht? Eines, das womöglich erst kürzlich unbemerkt durch ein
>> autom. Firmwareupdate (über IPv4) natives IPv6 bekommen hat, aber,
>> weil die Entwickler kleine Schritte machen, erstmal nur EUI-64 kann
>> und Privacy Extensions vielleicht irgendwann später mal.
>
> Mir ist klar, dass dann durch das Präfix wiederum der Traffic der
> anderen Nutzer identifizierbar wird.
> Aber das ist wie gesagt erwartetes Verhalten.

An diese Identifikation über Bande hättest du selbst (und ich auch)
*nie* *im* *Leben* gedacht, hätte man das Verfahren bzw. die Problematik
nicht in diesem Artikel beschrieben.


mfG Paul

[Juergen Ilse]

Hallo,

In de.comm.protocols.tcp-ip Paul Muster <exp-3...@news.muster.net> wrote:
> An diese Identifikation über Bande hättest du selbst (und ich auch)
> *nie* *im* *Leben* gedacht, hätte man das Verfahren bzw. die Problematik
> nicht in diesem Artikel beschrieben.

Die "Identifikation ueber Bande" existiert ja auch in der Form nicht.
Was moeglich ist, wenn ein IPv6 Device im Netz Traffic mit seiner SLAAC
Adresse´ins Internet generiert, ist die Identifikation des Netzwerkprefix.
Nicht mehhr und nichht weniger. Das entsprichht bei IPv4 mit NAT auf dem
heimischen Router und einer public WAN IP des eigenen Routers der Identi-
fikation dieser public WAN IP des Routers, nichht mehr und nicht weniger.
Wenn auf allen anderen Geraeten PE eingeschaltet sind, ermoeglicht das dort
beschriebene keineswegs die Identifikation der anderen Geraete im Netz.
Welche Sicherheitsluecken werden dadurch deiner Meinung nach aufgerissen?

Tschuess,
Juergen Ilse (jue...@usnet-verwaltung.de)

[Juergen Ilse]

Hallo,

Bei WLAN blaest man ohneihn viel mehr Informationen raus, als man aus der
Identifikation des IPv6 Prefix allein jemals ermitteln koennte (innerhhlb
der Reichweite des WLANs).

Tscuhess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Arno Welzel]

Wuns Haerst:

> Am 22.07.2022 um 10:38 schrieb Marco Moock:

[...]

>> Zudem hat das mit IPv6 nichts zu tun, denn das gleiche Problem

>> besteht auch mit IPv4. ...
>
> Ne, mit CGN bin ich da so gut wie auf der sicheren Seite.
> Hab ich das mit IPv6 auch? Ne, also: => Tonne.

Du hast den Artikel offenbar nicht wirklich gelesen.

--
Arno Welzel
https://arnowelzel.de

[Marco Moock]

Am Fri, 22 Jul 2022 22:22:16 +0200
schrieb Paul Muster <exp-3...@news.muster.net>:

> An diese Identifikation über Bande hättest du selbst (und ich auch)
> *nie* *im* *Leben* gedacht, hätte man das Verfahren bzw. die
> Problematik nicht in diesem Artikel beschrieben.

Dass bei IPv6 anhand des Präfixes (bei dem man /64 annehmen kann) alle
Teilnehmer eines Netzes identifiziert werden können, ist mir nicht neu.
Wenn einer davon durch irgendwelche Merkmale (EUI-64, Cookies, Login)
einen Rückschluss auf eine Person zulässt, ist natürlich auch der Rest,
der sich mit Privacy-Extensions oder NAT bei IPv4 schützt, diesem Netz
zuzuordnen und man kann schließen, dass die aus dem selben Haushalt
kommen. So wie bei IPv4-NAT auch. Wer Anonymität und Privatsphäre will,
muss sich um wesentlich mehr kümmern.

[Marco Moock]

Am 22 Jul 2022 20:32:38 GMT
schrieb Juergen Ilse <ne...@usenet-verwaltung.de>:

> In de.comp.security.misc Marco Moock <mo...@posteo.de> wrote:
> > Am Freitag, 22. Juli 2022, um 18:05:02 Uhr schrieb Juergen Ilse:
> >
> >> Nicht die MAC sondern die Interface-ID (die auch zur Bildung der
> >> link local Adresse verwendet wird).
> >
> > Auch für die MAC-Adresse gibt es die Möglichkeit, diese
> > automatisiert zu generieren statt die zu nehmen, die in der
> > Netzwerkkarte steht.
>
> Das wird i.d.R. nicht gemacht. Wenn man es machhen wuerde, wuerde man
> ueblicherweise den "private MAC Adress Range" dafuer verwenden, aber
> wozu? Damit, wenn man das auf verschihedenen Geraeten im selben Netz
> macht, die Gefahr einer MAC-Adress Kollision besteht (die dann zu
> beliebig schwer zu diagnostierenden Problemen fuehren kann)?

Da wird der private MAC-Bereich (nicht global eindeutig) genutzt.
Gefahr von Kollision gibt es. Wenn man aber VMs mit virtuellen Karten
hat, gibt es die auch.

> > Bei Apple iOS ist das glaub auch standardmäßig aktiv.
>
> Nein. Es wurden meines Wissens nach nur per Default die privacy
> extensions eingeschhhaltet.
>
> > Nutzt man dann EUI-64 steht da nicht die echte, sondern die
> > generierte MAC drin.
>
> Es ist voellig wumpe, ob der local part die MAC-Adresse enthaelt oder
> nicht, wenn fuer ausgehhende Verbindungen immer nur eine temporaere
> IPv6 Adresse verwendet wird, und somit i.d.R. der urspruengliche
> Interface-Identifier nie nach draussen drringt ...

Alles richtig, aber so können Logs von unterschiedlichen Netzen
zusammengeführt werden und anhand der MAC wieder Zusammenhänge erkannt
werden. Dazu müssen natürlich die Admins der Netze mitmachen.

> Hat denn niemand verstanden, dass bei Verwendung von SLAAC die PE
> nicht *anstelle* von EUI-64 sondern *zusaetzlichh* zu EUI-64
> verwendet werden?

Kommt drauf an. Im NetworkManager kann man das alles einstellen.
Statt EUI-64 kann ich da auch die stabile Privatsphäre wählen. Dann
wird der Interface-Identifier für ein Präfix einmal generiert und immer
dieser genutzt, es ist aber halt nicht die echte MAC-Adresse drin.

[Marc Haber]

Juergen Ilse <ne...@usenet-verwaltung.de> wrote:
>In de.comp.security.misc Marco Moock <mo...@posteo.de> wrote:
>> Nutzt man dann EUI-64 steht da nicht die echte, sondern die generierte
>> MAC drin.
>
>Es ist voellig wumpe, ob der local part die MAC-Adresse enthaelt oder nicht,
>wenn fuer ausgehhende Verbindungen immer nur eine temporaere IPv6 Adresse
>verwendet wird, und somit i.d.R. der urspruengliche Interface-Identifier
>nie nach draussen drringt ...

Die ausgehenden Ethernetframes enthalten die eigene MAC-Adresse, damit
ist man z.B. für den Betreiber eines WLAN Hotspots identifizierbar.
Auf diese Weise sind schon Leute verhaftet worden, weil über die Logs
der Hotspots identifizierbar.

Network Manager kann aus diesem Grund z.B. für jedes identifizierte
Netzwerk eine eigene MAC-Adresse würfeln.

Grüße
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

[Marc Haber]

Juergen Ilse <ne...@usenet-verwaltung.de> wrote:
>Bei WLAN blaest man ohneihn viel mehr Informationen raus, als man aus der
>Identifikation des IPv6 Prefix allein jemals ermitteln koennte (innerhhlb
>der Reichweite des WLANs).

Was denn, was über die aktuell gültige MAC-Adresse und die
konfigurierten WLANs mit hidden SSID hinausgeht?

[Wuns Haerst]

Am 23.07.2022 um 06:04 schrieb Arno Welzel:
> Wuns Haerst:
>
>> Am 22.07.2022 um 10:38 schrieb Marco Moock:
> [...]
>>> Zudem hat das mit IPv6 nichts zu tun, denn das gleiche Problem
>>> besteht auch mit IPv4. ...
>>
>> Ne, mit CGN bin ich da so gut wie auf der sicheren Seite.
>> Hab ich das mit IPv6 auch? Ne, also: => Tonne.
>
> Du hast den Artikel offenbar nicht wirklich gelesen.

Da steht sinngemäß, dass IPv6 für den Privatanwender im Endeffekt
unsicher ist. Daher sollte man es einfach meiden. Mein Provider
(Vodafone) hat mich mal auf DS-Lite zwangs-umgestellt, aber an
dem Punkt war mir das zu viel und ich habe interveniert und ich
habe nur noch eine IPv4-Adresse.
Außerdem hat IPv6 eh die höhere Latenz wg. der langen Adressen.
Ist also zum Spielen auch schlechter geeignet.

[Marco Moock]

Am Samstag, 23. Juli 2022, um 15:21:33 Uhr schrieb Wuns Haerst:

> Am 23.07.2022 um 06:04 schrieb Arno Welzel:
> > Wuns Haerst:
> >
> >> Am 22.07.2022 um 10:38 schrieb Marco Moock:
> > [...]
> >>> Zudem hat das mit IPv6 nichts zu tun, denn das gleiche Problem
> >>> besteht auch mit IPv4. ...
> >>
> >> Ne, mit CGN bin ich da so gut wie auf der sicheren Seite.
> >> Hab ich das mit IPv6 auch? Ne, also: => Tonne.
> >
> > Du hast den Artikel offenbar nicht wirklich gelesen.
>
> Da steht sinngemäß, dass IPv6 für den Privatanwender im Endeffekt
> unsicher ist.

Da steht, dass es Systeme gibt, die das nicht so implementieren, dass
es für maximale Privatsphäre ausgelegt ist. Das ist kein problem des
Protokolls, sondern der Umsetzung.

> Daher sollte man es einfach meiden.

Dich sollten wir meiden.

> Mein Provider (Vodafone) hat mich mal auf DS-Lite zwangs-umgestellt, aber an
> dem Punkt war mir das zu viel und ich habe interveniert und ich
> habe nur noch eine IPv4-Adresse.
> Außerdem hat IPv6 eh die höhere Latenz wg. der langen Adressen.
> Ist also zum Spielen auch schlechter geeignet.

Und daran merkt man mal wieder, dass du einfach NULL Ahnung hast. Bei
IPv6 ist kein NAT erforderlich und die Routingtabellen sind kleiner,
was für geringere Latenzen sorgt. Kann man bei einer entsprechend
großen NAT/PAT-Tabelle auch selbst erleben.

[Wuns Haerst]

Am 23.07.2022 um 16:05 schrieb Marco Moock:
> Am Samstag, 23. Juli 2022, um 15:21:33 Uhr schrieb Wuns Haerst:
>
>> Am 23.07.2022 um 06:04 schrieb Arno Welzel:
>>> Wuns Haerst:
>>>
>>>> Am 22.07.2022 um 10:38 schrieb Marco Moock:
>>> [...]
>>>>> Zudem hat das mit IPv6 nichts zu tun, denn das gleiche Problem
>>>>> besteht auch mit IPv4. ...
>>>>
>>>> Ne, mit CGN bin ich da so gut wie auf der sicheren Seite.
>>>> Hab ich das mit IPv6 auch? Ne, also: => Tonne.
>>>
>>> Du hast den Artikel offenbar nicht wirklich gelesen.
>>
>> Da steht sinngemäß, dass IPv6 für den Privatanwender im Endeffekt
>> unsicher ist.
>
> Da steht, dass es Systeme gibt, die das nicht so implementieren, dass
> es für maximale Privatsphäre ausgelegt ist. Das ist kein problem des
> Protokolls, sondern der Umsetzung.

Quark, das ist nach RFC so definiert, also generell Murks.

>
>> Daher sollte man es einfach meiden.
>
> Dich sollten wir meiden.
>
>> Mein Provider (Vodafone) hat mich mal auf DS-Lite zwangs-umgestellt, aber an
>> dem Punkt war mir das zu viel und ich habe interveniert und ich
>> habe nur noch eine IPv4-Adresse.
>> Außerdem hat IPv6 eh die höhere Latenz wg. der langen Adressen.
>> Ist also zum Spielen auch schlechter geeignet.
>
> Und daran merkt man mal wieder, dass du einfach NULL Ahnung hast. Bei
> IPv6 ist kein NAT erforderlich und die Routingtabellen sind kleiner,
> was für geringere Latenzen sorgt. Kann man bei einer entsprechend
> großen NAT/PAT-Tabelle auch selbst erleben.

Wo hab ich gesagt, dass IPv6 bei DS-Lite NAT braucht ?
Das Routen-Mapping ist von der Latenz her komplett egal, was dauert
ist die Latenz in den Sende-Queues und auf der Leitung, und da ist
IPv6 einfach schlechter für Echtzeit-Anwendungen geeignet.

[Marco Moock]

Am Samstag, 23. Juli 2022, um 16:37:15 Uhr schrieb ein Dummschätzer:

> Am 23.07.2022 um 16:05 schrieb Marco Moock:
> > Da steht, dass es Systeme gibt, die das nicht so implementieren,
> > dass es für maximale Privatsphäre ausgelegt ist. Das ist kein
> > problem des Protokolls, sondern der Umsetzung.
>
> Quark, das ist nach RFC so definiert, also generell Murks.

Und die Privacy-Extensions sind auch in nem RFC definiert. Wenn die der
Rechner nicht nutzt - nicht mein Problem.

> Wo hab ich gesagt, dass IPv6 bei DS-Lite NAT braucht ?

Gar nicht, das habe ich dir auch nicht vorgeworfen. Wieder zu viel
gekifft, Christian?
Bei IPv4 braucht es das aber und das ist nicht nur messbar, sondern bei
vielen Verbindungen auch spürbar.

> Das Routen-Mapping ist von der Latenz her komplett egal, was dauert
> ist die Latenz in den Sende-Queues und auf der Leitung, und da ist
> IPv6 einfach schlechter für Echtzeit-Anwendungen geeignet.

Das Routing ist eben nicht egal, weil alle Einträge geprüft werden
müssen und dann der mit der größten Übereinstimmung genommen wird. Mehr
Einträge --> mehr Aufwand. Das sind aber Grundlagen, wenn du so auf
superschlau tust, solltest du sowas wissen.

[Wuns Haerst]

Am 23.07.2022 um 16:42 schrieb Marco Moock:
> Am Samstag, 23. Juli 2022, um 16:37:15 Uhr schrieb ein Dummschätzer:
>
>> Am 23.07.2022 um 16:05 schrieb Marco Moock:
>>> Da steht, dass es Systeme gibt, die das nicht so implementieren,
>>> dass es für maximale Privatsphäre ausgelegt ist. Das ist kein
>>> problem des Protokolls, sondern der Umsetzung.
>>
>> Quark, das ist nach RFC so definiert, also generell Murks.
>
> Und die Privacy-Extensions sind auch in nem RFC definiert. Wenn die der
> Rechner nicht nutzt - nicht mein Problem.

Ja, dann ist's ja noch schlimmer.

>
>> Wo hab ich gesagt, dass IPv6 bei DS-Lite NAT braucht ?
>
> Gar nicht, das habe ich dir auch nicht vorgeworfen. Wieder zu viel
> gekifft, Christian?

Wer auch immer das ist.

> Bei IPv4 braucht es das aber und das ist nicht nur messbar, sondern bei
> vielen Verbindungen auch spürbar.

Du kennst dich vielleicht mit Software oberflächlich aus,
aber nicht mit Informatik.

>
>> Das Routen-Mapping ist von der Latenz her komplett egal, was dauert
>> ist die Latenz in den Sende-Queues und auf der Leitung, und da ist
>> IPv6 einfach schlechter für Echtzeit-Anwendungen geeignet.
>
> Das Routing ist eben nicht egal, weil alle Einträge geprüft werden
> müssen und dann der mit der größten Übereinstimmung genommen wird.

Das geht bei Routen-Matching per Hardware praktisch sofort, da alle
Präfixe gleichzeitig durch einen Assoziativ-Speicher als ASIC gecheckt
werden. Was dauert ist das Warten in der Sende-Queue und die Übertra-
gungs-Zeit ansich, der Rest ist vernachlässigar.
An der Stelle ist einfach IPv6 für Echteit-Anwendungen komplett
ungeeignet.

> Mehr Einträge --> mehr Aufwand. ...

Nicht in Hardware, da testet der Assoziativ-Speicher ein Präfix
genauso schnell wie eine Million, der Unterschied ist nur der
Stromverbrauch.

[Wuns Haerst]

Am 23.07.2022 um 16:42 schrieb Marco Moock:

> Das Routing ist eben nicht egal, weil alle Einträge geprüft werden
> müssen und dann der mit der größten Übereinstimmung genommen wird.

> Mehr Einträge --> mehr Aufwand. ...

Achja, das stimmt nichtmal in Software weil da der Aufwand konstant
bzw. logarithmisch zu der Anzahl der gematchten Präfix-Bits ist.

[Marc Haber]

Marco Moock <mo...@posteo.de> wrote:
>Und daran merkt man mal wieder, dass du einfach NULL Ahnung hast

Das ist ein Troll! Warum verschwendest Du Deine Zeit mit ihm?

[Wuns Haerst]

Am 23.07.2022 um 17:09 schrieb Marc Haber:
> Marco Moock <mo...@posteo.de> wrote:
>> Und daran merkt man mal wieder, dass du einfach NULL Ahnung hast
>
> Das ist ein Troll! Warum verschwendest Du Deine Zeit mit ihm?

Ich bin ein honoriger Diskutant und ganz sicher kein Troll.

[Arno Welzel]

Wuns Haerst:

> Am 23.07.2022 um 06:04 schrieb Arno Welzel:
>> Wuns Haerst:
>>
>>> Am 22.07.2022 um 10:38 schrieb Marco Moock:
>> [...]
>>>> Zudem hat das mit IPv6 nichts zu tun, denn das gleiche Problem
>>>> besteht auch mit IPv4. ...
>>>
>>> Ne, mit CGN bin ich da so gut wie auf der sicheren Seite.
>>> Hab ich das mit IPv6 auch? Ne, also: => Tonne.
>>
>> Du hast den Artikel offenbar nicht wirklich gelesen.
>
> Da steht sinngemäß, dass IPv6 für den Privatanwender im Endeffekt
> unsicher ist. Daher sollte man es einfach meiden. Mein Provider

[...]

Ähm - nein.

In <https://heise.de/-7186203> steht konkret:

"Laut einer Studie läuft jeder fünfte Kunde eines großen europäischen
Internetanbieters Gefahr, dass die Datenschutzvorkehrungen für IPv6
ausgehebelt werden."

Also schon mal nicht jeder Privatanwender, sondern nur ein Teil davon,
etwa 19% aller beobachteten Adressen in der Studie. Konkret nur da, wo
Geräte EUI-64 nutzen, wie Tablets oder Smart-TVs etc..

[Arno Welzel]

Wuns Haerst:

[...]

> Das Routen-Mapping ist von der Latenz her komplett egal, was dauert

Nein. Bei IPv4 herrscht eine heftige Fragmentierung und das führt zu
erheblichem Aufwand. Das fällt bei IPv6 komplett weg.

> ist die Latenz in den Sende-Queues und auf der Leitung, und da ist
> IPv6 einfach schlechter für Echtzeit-Anwendungen geeignet.

Davon merke ich hier nichts. Mit IPv6 erreiche über einen
VDSL2-Anschluss Latenzen von unter 10ms - das reicht für Echtzeit
vollkommen aus.

[Arno Welzel]

Wuns Haerst:

Hmmm... <http://wurstfabrik.at>

[Wuns Haerst]

Am 23.07.2022 um 18:26 schrieb Arno Welzel:
> Wuns Haerst:
>
> [...]
>> Das Routen-Mapping ist von der Latenz her komplett egal, was dauert
>
> Nein. Bei IPv4 herrscht eine heftige Fragmentierung und das führt zu
> erheblichem Aufwand. Das fällt bei IPv6 komplett weg.

Der Aufwand ist beim Matching in Hardware konstant, egal wie divers die
Präfixe verteilt sind und egal wieviele Präfixe Du hast. Die müssen halt
nur alle in das ASIC passen, was in der Regel gegeben ist.

>
>> ist die Latenz in den Sende-Queues und auf der Leitung, und da ist
>> IPv6 einfach schlechter für Echtzeit-Anwendungen geeignet.
>
> Davon merke ich hier nichts. Mit IPv6 erreiche über einen
> VDSL2-Anschluss Latenzen von unter 10ms - das reicht für
> Echtzeit vollkommen aus.

Interessante Echtzeit-Anwendungen die Du da schilderst.

[Juergen Ilse]

Hallo,

In de.comp.security.misc Wuns Haerst <Wuns....@wurstfabrik.at> wrote:
> Am 23.07.2022 um 06:04 schrieb Arno Welzel:
>> Wuns Haerst:
>>
>>> Am 22.07.2022 um 10:38 schrieb Marco Moock:
>> [...]
>>>> Zudem hat das mit IPv6 nichts zu tun, denn das gleiche Problem
>>>> besteht auch mit IPv4. ...
>>>
>>> Ne, mit CGN bin ich da so gut wie auf der sicheren Seite.
>>> Hab ich das mit IPv6 auch? Ne, also: => Tonne.
>>
>> Du hast den Artikel offenbar nicht wirklich gelesen.
>
> Da steht sinngemäß, dass IPv6 für den Privatanwender im Endeffekt

> unsicher ist.i

Nein, das stehht da *nicht*.

Es genuegt offenbar nicht, keine Ahnung zu hhaben, man muss mit seiner
Unwissenheit dann auch noch angeben ...

> Außerdem hat IPv6 eh die höhere Latenz wg. der langen Adressen.

Unfug. Warum sollte sichh aus laengeren Adressen eine hoehhere latenz
ergeben? Wenn sich fuer manche Ziele bei IPv6 eine hoehere atenz er-
gibt, hat das mit der Adresslaenge sichher nichts zu tun.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Juergen Ilse]

Hallo,

In de.comp.security.misc Wuns Haerst <Wuns....@wurstfabrik.at> wrote:

> Am 23.07.2022 um 16:42 schrieb Marco Moock:
>> Am Samstag, 23. Juli 2022, um 16:37:15 Uhr schrieb ein Dummschätzer:
>>
>>> Am 23.07.2022 um 16:05 schrieb Marco Moock:
>>>> Da steht, dass es Systeme gibt, die das nicht so implementieren,
>>>> dass es für maximale Privatsphäre ausgelegt ist. Das ist kein
>>>> problem des Protokolls, sondern der Umsetzung.
>>>
>>> Quark, das ist nach RFC so definiert, also generell Murks.
>>
>> Und die Privacy-Extensions sind auch in nem RFC definiert. Wenn die der
>> Rechner nicht nutzt - nicht mein Problem.
>
> Ja, dann ist's ja noch schlimmer.

Nein. Schlimm ist hohechstens dein halbverstandenes Viertelwissen, mit
dem du meinst, hier hhausieren gehen zu muessen ...

>> Bei IPv4 braucht es das aber und das ist nicht nur messbar, sondern bei
>> vielen Verbindungen auch spürbar.
>
> Du kennst dich vielleicht mit Software oberflächlich aus,
> aber nicht mit Informatik.

Du hast von networking nichht ganz genug Ahnung, um ein Fischernetz
von einem IP Netz zu unterscheiden. Zumindest machhst du hhier einen
solchen Eindruck.

Tschuhess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Wuns Haerst]

Am 23.07.2022 um 18:36 schrieb Juergen Ilse:
> Hallo,
>
> In de.comp.security.misc Wuns Haerst <Wuns....@wurstfabrik.at> wrote:
>> Am 23.07.2022 um 06:04 schrieb Arno Welzel:
>>> Wuns Haerst:
>>>
>>>> Am 22.07.2022 um 10:38 schrieb Marco Moock:
>>> [...]
>>>>> Zudem hat das mit IPv6 nichts zu tun, denn das gleiche Problem
>>>>> besteht auch mit IPv4. ...
>>>>
>>>> Ne, mit CGN bin ich da so gut wie auf der sicheren Seite.
>>>> Hab ich das mit IPv6 auch? Ne, also: => Tonne.
>>>
>>> Du hast den Artikel offenbar nicht wirklich gelesen.
>>
>> Da steht sinngemäß, dass IPv6 für den Privatanwender im Endeffekt
>> unsicher ist.i
>
> Nein, das stehht da *nicht*.
>
> Es genuegt offenbar nicht, keine Ahnung zu hhaben, man muss mit seiner
> Unwissenheit dann auch noch angeben ...

Du argumentierst ohne Sach-Argumente.

>
>> Außerdem hat IPv6 eh die höhere Latenz wg. der langen Adressen.
>
> Unfug. Warum sollte sichh aus laengeren Adressen eine hoehhere latenz
> ergeben? Wenn sich fuer manche Ziele bei IPv6 eine hoehere atenz er-
> gibt, hat das mit der Adresslaenge sichher nichts zu tun.

Doch, sicher, weil die Pakete ja größer werden.

[Wuns Haerst]

Geht's auch mit Sachargumenten ?

[Arno Welzel]

Wuns Haerst:

> Am 23.07.2022 um 18:36 schrieb Juergen Ilse:

[...]

>> Unfug. Warum sollte sichh aus laengeren Adressen eine hoehhere latenz
>> ergeben? Wenn sich fuer manche Ziele bei IPv6 eine hoehere atenz er-
>> gibt, hat das mit der Adresslaenge sichher nichts zu tun.
>
> Doch, sicher, weil die Pakete ja größer werden.

Du kannst sicher konkret vorrechnen, wie sich der längere Header bei
IPv6 konkret auf die Latenz auswirkt.

[Arno Welzel]

Wuns Haerst:

> Am 23.07.2022 um 18:26 schrieb Arno Welzel:
>> Wuns Haerst:
>>
>> [...]
>>> Das Routen-Mapping ist von der Latenz her komplett egal, was dauert
>>
>> Nein. Bei IPv4 herrscht eine heftige Fragmentierung und das führt zu
>> erheblichem Aufwand. Das fällt bei IPv6 komplett weg.
>
> Der Aufwand ist beim Matching in Hardware konstant, egal wie divers die
> Präfixe verteilt sind und egal wieviele Präfixe Du hast. Die müssen halt
> nur alle in das ASIC passen, was in der Regel gegeben ist.

Aber nicht die Anzahl der Hops, die anfallen.

Wenn ich einen Host der sowohl IPv4 wie auch IPv6 erreichen kann, mit
IPv4 anpinge ist die Latenz hier nachweislich 2-3ms höher, als über IPv6.

>>> ist die Latenz in den Sende-Queues und auf der Leitung, und da ist
>>> IPv6 einfach schlechter für Echtzeit-Anwendungen geeignet.
>>
>> Davon merke ich hier nichts. Mit IPv6 erreiche über einen
>> VDSL2-Anschluss Latenzen von unter 10ms - das reicht für
>> Echtzeit vollkommen aus.
>
> Interessante Echtzeit-Anwendungen die Du da schilderst.

Hier derzeit im Einsatz:

- Jitsi Meet (in der Regel so um die 4-8 Leute)

- Nextcloud Talk mit Highperformane Backend (in der Regel um die 20-25
Teilnehmer

- Ant Media Server, der hier durchgehen mit einem Live-Video-Stream über
diesen VDSL2-Anschluss getunnelt durch IPSec gefüttert wird

Ja, es sind mehrere Server, die dafür im Einsatz sind.

Welche Anwendungen hattest Du denn so im Sinn?

[Wuns Haerst]

Am 23.07.2022 um 19:13 schrieb Arno Welzel:
> Wuns Haerst:
>
>> Am 23.07.2022 um 18:26 schrieb Arno Welzel:
>>> Wuns Haerst:
>>>
>>> [...]
>>>> Das Routen-Mapping ist von der Latenz her komplett egal, was dauert
>>>
>>> Nein. Bei IPv4 herrscht eine heftige Fragmentierung und das führt zu
>>> erheblichem Aufwand. Das fällt bei IPv6 komplett weg.
>>
>> Der Aufwand ist beim Matching in Hardware konstant, egal wie divers die
>> Präfixe verteilt sind und egal wieviele Präfixe Du hast. Die müssen halt
>> nur alle in das ASIC passen, was in der Regel gegeben ist.
>
> Aber nicht die Anzahl der Hops, die anfallen.

Was hat das mit der vorangegangenen Aussage zu tun?

> Wenn ich einen Host der sowohl IPv4 wie auch IPv6 erreichen kann, mit
> IPv4 anpinge ist die Latenz hier nachweislich 2-3ms höher, als über IPv6.

Ja, sischaaaaaaaa.
Die Latenz ergibt sich aus dem Füllgrad der Sende-Queue und aus der
Übertragungszeit auf dem Kabel. Beides ist bei IPv6 eben höher, da
beißt die Maus keinen Faden ab.

>
>>>> ist die Latenz in den Sende-Queues und auf der Leitung, und da ist
>>>> IPv6 einfach schlechter für Echtzeit-Anwendungen geeignet.
>>>
>>> Davon merke ich hier nichts. Mit IPv6 erreiche über einen
>>> VDSL2-Anschluss Latenzen von unter 10ms - das reicht für
>>> Echtzeit vollkommen aus.
>>
>> Interessante Echtzeit-Anwendungen die Du da schilderst.
>
> Hier derzeit im Einsatz:
>
> - Jitsi Meet (in der Regel so um die 4-8 Leute)
>
> - Nextcloud Talk mit Highperformane Backend (in der Regel um die 20-25
> Teilnehmer
>
> - Ant Media Server, der hier durchgehen mit einem Live-Video-Stream über
> diesen VDSL2-Anschluss getunnelt durch IPSec gefüttert wird

Dann spiel mal, das geht über IPv6 schlechter.
Daher nutzen Leute die sich auch irgendwelche x-100-Hz-Monitore
kaufen eben auch IPv4.

[Wuns Haerst]

Am 23.07.2022 um 19:07 schrieb Arno Welzel:

Da muss ich nix vorrechnen, das kannste selbst.
Wenn ich einen 10GBit-Link habe, dann ist das ne Milchmädchen-Rechnung
zu ermitteln, wieviel zusätzliche 3 * 32 Bit an Übertragung dauern.

[Arno Welzel]

Wuns Haerst:

> Am 23.07.2022 um 19:13 schrieb Arno Welzel:
>> Wuns Haerst:
>>
>>> Am 23.07.2022 um 18:26 schrieb Arno Welzel:
>>>> Wuns Haerst:
>>>>
>>>> [...]
>>>>> Das Routen-Mapping ist von der Latenz her komplett egal, was dauert
>>>>
>>>> Nein. Bei IPv4 herrscht eine heftige Fragmentierung und das führt zu
>>>> erheblichem Aufwand. Das fällt bei IPv6 komplett weg.
>>>
>>> Der Aufwand ist beim Matching in Hardware konstant, egal wie divers die
>>> Präfixe verteilt sind und egal wieviele Präfixe Du hast. Die müssen halt
>>> nur alle in das ASIC passen, was in der Regel gegeben ist.
>>
>> Aber nicht die Anzahl der Hops, die anfallen.
>
> Was hat das mit der vorangegangenen Aussage zu tun?

Es hat damit zu tun, wie hoch Latenzen werden können.

>> Wenn ich einen Host der sowohl IPv4 wie auch IPv6 erreichen kann, mit
>> IPv4 anpinge ist die Latenz hier nachweislich 2-3ms höher, als über IPv6.
>
> Ja, sischaaaaaaaa.

Ja.

Von mir aus zu google.de über IPv4: 19-22 ms
Von mir aus zu google.de über IPv6: 17-19 ms

Soll ich es Dir live vorführen? Kannst gerne per Screen-Sharing
zuschauen. E-Mail-Adresse ist gültig.

> Die Latenz ergibt sich aus dem Füllgrad der Sende-Queue und aus der
> Übertragungszeit auf dem Kabel. Beides ist bei IPv6 eben höher, da
> beißt die Maus keinen Faden ab.

Und alle weiteren Faktoren blendest Du einfach mal aus, schon klar.

[...]

>>> Interessante Echtzeit-Anwendungen die Du da schilderst.
>>
>> Hier derzeit im Einsatz:
>>
>> - Jitsi Meet (in der Regel so um die 4-8 Leute)
>>
>> - Nextcloud Talk mit Highperformane Backend (in der Regel um die 20-25
>> Teilnehmer
>>
>> - Ant Media Server, der hier durchgehen mit einem Live-Video-Stream über
>> diesen VDSL2-Anschluss getunnelt durch IPSec gefüttert wird
>
>
> Dann spiel mal, das geht über IPv6 schlechter.

Aha. Wie passt das damit zusammen, dass hier Latenzen über IPv6 kaum
über 5-10 ms liegen?

> Daher nutzen Leute die sich auch irgendwelche x-100-Hz-Monitore
> kaufen eben auch IPv4.

Das hätte ich aber mitbekommen. Mein Bruder ist in einem
semi-professionellen iRacing-Team unterwegs. Da wurde noch nie
dergleichen berichtet.

[Arno Welzel]

Wuns Haerst:

> Am 23.07.2022 um 19:07 schrieb Arno Welzel:
>> Wuns Haerst:
>>
>>> Am 23.07.2022 um 18:36 schrieb Juergen Ilse:
>> [...]
>>>> Unfug. Warum sollte sichh aus laengeren Adressen eine hoehhere latenz
>>>> ergeben? Wenn sich fuer manche Ziele bei IPv6 eine hoehere atenz er-
>>>> gibt, hat das mit der Adresslaenge sichher nichts zu tun.
>>>
>>> Doch, sicher, weil die Pakete ja größer werden.
>>
>> Du kannst sicher konkret vorrechnen, wie sich der längere Header bei
>> IPv6 konkret auf die Latenz auswirkt.
>
> Da muss ich nix vorrechnen, das kannste selbst.

Wieso sollte ich? Du hast etwas behauptet, also belege es auch.

> Wenn ich einen 10GBit-Link habe, dann ist das ne Milchmädchen-Rechnung
> zu ermitteln, wieviel zusätzliche 3 * 32 Bit an Übertragung dauern.

Hast Du einen 10 GBit-Link? Wenn ja, warum stört Dich dann IPv6?

[Wuns Haerst]

Am 23.07.2022 um 19:43 schrieb Arno Welzel:
> Wuns Haerst:
>
>> Am 23.07.2022 um 19:13 schrieb Arno Welzel:
>>> Wuns Haerst:
>>>
>>>> Am 23.07.2022 um 18:26 schrieb Arno Welzel:
>>>>> Wuns Haerst:
>>>>>
>>>>> [...]
>>>>>> Das Routen-Mapping ist von der Latenz her komplett egal, was dauert
>>>>>
>>>>> Nein. Bei IPv4 herrscht eine heftige Fragmentierung und das führt zu
>>>>> erheblichem Aufwand. Das fällt bei IPv6 komplett weg.
>>>>
>>>> Der Aufwand ist beim Matching in Hardware konstant, egal wie divers die
>>>> Präfixe verteilt sind und egal wieviele Präfixe Du hast. Die müssen halt
>>>> nur alle in das ASIC passen, was in der Regel gegeben ist.
>>>
>>> Aber nicht die Anzahl der Hops, die anfallen.
>>
>> Was hat das mit der vorangegangenen Aussage zu tun?
>
> Es hat damit zu tun, wie hoch Latenzen werden können.

Anteilig so minimal, dass das wirklich zu vernachlässigen ist,
selbst wenn man das Matching in Software macht.

>>> Wenn ich einen Host der sowohl IPv4 wie auch IPv6 erreichen kann, mit
>>> IPv4 anpinge ist die Latenz hier nachweislich 2-3ms höher, als über IPv6.
>>
>> Ja, sischaaaaaaaa.
>
> Ja.
>
> Von mir aus zu google.de über IPv4: 19-22 ms
> Von mir aus zu google.de über IPv6: 17-19 ms

Ganz sicher auch über die selbe Route, ne ?

> Soll ich es Dir live vorführen? Kannst gerne per Screen-Sharing
> zuschauen. E-Mail-Adresse ist gültig.
>
>> Die Latenz ergibt sich aus dem Füllgrad der Sende-Queue und aus der
>> Übertragungszeit auf dem Kabel. Beides ist bei IPv6 eben höher, da
>> beißt die Maus keinen Faden ab.
>
> Und alle weiteren Faktoren blendest Du einfach mal aus, schon klar.

Weil weitere Faktoren anteilig keine Rolle spielen.

> [...]
>>>> Interessante Echtzeit-Anwendungen die Du da schilderst.
>>>
>>> Hier derzeit im Einsatz:
>>>
>>> - Jitsi Meet (in der Regel so um die 4-8 Leute)
>>>
>>> - Nextcloud Talk mit Highperformane Backend (in der Regel um die 20-25
>>> Teilnehmer
>>>
>>> - Ant Media Server, der hier durchgehen mit einem Live-Video-Stream über
>>> diesen VDSL2-Anschluss getunnelt durch IPSec gefüttert wird
>>
>>
>> Dann spiel mal, das geht über IPv6 schlechter.
>
> Aha. Wie passt das damit zusammen, dass hier Latenzen über IPv6 kaum
> über 5-10 ms liegen?

Hrhr.
Ja, sicher, das garantiert dir IPv6.
Prinzipielle Überlegungen spielen da keine Rolle.
Trottel.

>> Daher nutzen Leute die sich auch irgendwelche x-100-Hz-Monitore
>> kaufen eben auch IPv4.
>
> Das hätte ich aber mitbekommen. Mein Bruder ist in einem
> semi-professionellen iRacing-Team unterwegs. Da wurde noch nie
> dergleichen berichtet.

Ich glaub Du hattest noch nie einen solchen Bruder.

[Wuns Haerst]

Am 23.07.2022 um 19:44 schrieb Arno Welzel:
> Wuns Haerst:
>
>> Am 23.07.2022 um 19:07 schrieb Arno Welzel:
>>> Wuns Haerst:
>>>
>>>> Am 23.07.2022 um 18:36 schrieb Juergen Ilse:
>>> [...]
>>>>> Unfug. Warum sollte sichh aus laengeren Adressen eine hoehhere latenz
>>>>> ergeben? Wenn sich fuer manche Ziele bei IPv6 eine hoehere atenz er-
>>>>> gibt, hat das mit der Adresslaenge sichher nichts zu tun.
>>>>
>>>> Doch, sicher, weil die Pakete ja größer werden.
>>>
>>> Du kannst sicher konkret vorrechnen, wie sich der längere Header bei
>>> IPv6 konkret auf die Latenz auswirkt.
>>
>> Da muss ich nix vorrechnen, das kannste selbst.
>
> Wieso sollte ich? Du hast etwas behauptet, also belege es auch.

Nimm einen kleinen Block, wie das bei Echtzeit-Daten für Spiele üblich
ist, der hat dann sagen wir mal 100 Byte. Wenn Du dann noch 2 * 3 * 32
Bit draufrechnest, dann sinds halt 124 Byte. Ich glaub zwar nicht, dass
Du ermitteln kannst wieviel 124 / 100 sind, aber andere werden das
sicher verstehen.

>> Wenn ich einen 10GBit-Link habe, dann ist das ne Milchmädchen-Rechnung
>> zu ermitteln, wieviel zusätzliche 3 * 32 Bit an Übertragung dauern.
>
> Hast Du einen 10 GBit-Link? Wenn ja, warum stört Dich dann IPv6?

Nein, hab ich nicht, aber bei manchen Echtzeit-Anwendungen ist das
eben relevant.

[Bastian Blank]

Arno Welzel wrote:
> Wuns Haerst:

>> Das Routen-Mapping ist von der Latenz her komplett egal, was dauert
> Nein. Bei IPv4 herrscht eine heftige Fragmentierung und das führt zu
> erheblichem Aufwand. Das fällt bei IPv6 komplett weg.
>> ist die Latenz in den Sende-Queues und auf der Leitung, und da ist
>> IPv6 einfach schlechter für Echtzeit-Anwendungen geeignet.
> Davon merke ich hier nichts. Mit IPv6 erreiche über einen
> VDSL2-Anschluss Latenzen von unter 10ms - das reicht für Echtzeit
> vollkommen aus.

Die Latenzen werden sogar geringer. Google erfasst solche Zahlen und
zeigt in Ländern mit großer IPv6-Verteilung teils die Reduktion von
20ms.[1] Leider finde ich die Zahlen nicht in ordentlicher Form.

Bastian

[1]: https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption

[Marco Moock]

Am Samstag, 23. Juli 2022, um 16:44:17 Uhr schrieb Juergen Ilse:

> Du hast von networking nichht ganz genug Ahnung, um ein Fischernetz
> von einem IP Netz zu unterscheiden. Zumindest machhst du hhier einen
> solchen Eindruck.

Dem kann ich nur zustimmen. :-)

[Marco Moock]

Am Samstag, 23. Juli 2022, um 19:04:40 Uhr schrieb Wuns Haerst:

> Geht's auch mit Sachargumenten ?

Nein, denn für die bist du nicht zugänglich.

[Marco Moock]

Falsch, sonst würde das ja bei der Messung der Latenz und der
CPU-Auslastung nicht auffallen.

[Marco Moock]

Am Samstag, 23. Juli 2022, um 19:29:18 Uhr schrieb Wuns Haerst:

> Die Latenz ergibt sich aus dem Füllgrad der Sende-Queue und aus der
> Übertragungszeit auf dem Kabel. Beides ist bei IPv6 eben höher, da
> beißt die Maus keinen Faden ab.

Dazu kommt, dass du eben bei NAT die Tabellen prüfen musst und die
Header umschreiben musst. Also ein Mehraufwand. ist denn stateful NAT
so schwer zu verstehen?

> Dann spiel mal, das geht über IPv6 schlechter.
> Daher nutzen Leute die sich auch irgendwelche x-100-Hz-Monitore
> kaufen eben auch IPv4.

Die wenigsten Spieler machen sich darüber Gedanken. Des Weiteren
könntest du ja mal Beispiele mit Messungen bringen, statt das einfach
nur so zu behaupten.

[Marco Moock]

Am Samstag, 23. Juli 2022, um 19:49:45 Uhr schrieb Wuns Haerst:

> > Von mir aus zu google.de über IPv4: 19-22 ms
> > Von mir aus zu google.de über IPv6: 17-19 ms
>
> Ganz sicher auch über die selbe Route, ne ?

Teste es doch selbst und prüfe dann, ob es die gleichen Router sind,
z.B. anhand der Hostnamen, sollten diese im PTR gesetzt sein.

> Weil weitere Faktoren anteilig keine Rolle spielen.

Falsch, das kann man sogar Live erleben, einfach mal die CPU-Last
abfragen.

Zudem dokumentiert Google diese Messungen:
https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption

> Prinzipielle Überlegungen spielen da keine Rolle.

Es sind Praxiserfahrungen, die das bestätigen.

> Trottel.

So würde ich dich nichtmal nennen, wäre schon vom Niveau her unpassend,
denn nichtmal ein Trottel würde so blödes Zeug schreiben wie du.

[Wuns Haerst]

Ja, ich bin zu doof, um aus Beleidigungen Sachargumente herauszulesen.

[Wuns Haerst]

Wie blöd ist das denn?
Wie willst Du denn aus einer absoluten Latenz die Zeit
für's Routen-Machting heraus-subtrahieren?

[Marco Moock]

Am Samstag, 23. Juli 2022, um 18:29:39 Uhr schrieb Arno Welzel:

> Hmmm... <http://wurstfabrik.at>

Ob der dazu in der Lage ist, nen Webserver zu betreiben?

[Wuns Haerst]

Da brauch ich gar nix zu testen, das versteht jeder, dass die
Übertragung von mehr Daten auf dem selben Link länger dauert.
Und wenn das länger dauert, dann stapeln sich in der Sende
-Queue auch mehr Daten an.

[Wuns Haerst]

Am 23.07.2022 um 20:31 schrieb Marco Moock:
> Am Samstag, 23. Juli 2022, um 19:29:18 Uhr schrieb Wuns Haerst:
>
>> Die Latenz ergibt sich aus dem Füllgrad der Sende-Queue und aus der
>> Übertragungszeit auf dem Kabel. Beides ist bei IPv6 eben höher, da
>> beißt die Maus keinen Faden ab.
>
> Dazu kommt, dass du eben bei NAT die Tabellen prüfen musst und die
> Header umschreiben musst. Also ein Mehraufwand. ist denn stateful NAT
> so schwer zu verstehen?

Das dauert im Gegensatz zur Übertragung auf der Leitung nahezu Null.

>> Dann spiel mal, das geht über IPv6 schlechter.
>> Daher nutzen Leute die sich auch irgendwelche x-100-Hz-Monitore
>> kaufen eben auch IPv4.

> Die wenigsten Spieler machen sich darüber Gedanken. ...

Die besagten die auch beim Bildschirm auf die letzten Optimierungen
achten schon.

[Marco Moock]

Am Samstag, 23. Juli 2022, um 19:52:22 Uhr schrieb Wuns Haerst:

> Nein, hab ich nicht, aber bei manchen Echtzeit-Anwendungen ist das
> eben relevant.

Nur diese nutzen dann ganz sicher kein IPV4-NAT. Oder gar CG-NAT mit
DS-Lite. Da kommt noch mehr Aufwand für das Tunneln dazu + noch
Overhead.

[Marco Moock]

Am Samstag, 23. Juli 2022, um 20:36:54 Uhr schrieb Wuns Haerst:

> Am 23.07.2022 um 20:29 schrieb Marco Moock:
> > Am Samstag, 23. Juli 2022, um 17:04:02 Uhr schrieb Wuns Haerst:
> >
> >> Am 23.07.2022 um 16:42 schrieb Marco Moock:
> >>
> >>> Das Routing ist eben nicht egal, weil alle Einträge geprüft werden
> >>> müssen und dann der mit der größten Übereinstimmung genommen wird.
> >>> Mehr Einträge --> mehr Aufwand. ...
> >>
> >> Achja, das stimmt nichtmal in Software weil da der Aufwand konstant
> >> bzw. logarithmisch zu der Anzahl der gematchten Präfix-Bits ist.
> >
> > Falsch, sonst würde das ja bei der Messung der Latenz und der
> > CPU-Auslastung nicht auffallen.
> >
>
> Wie blöd ist das denn?

Nicht blöder als du.

> Wie willst Du denn aus einer absoluten Latenz die Zeit
> für's Routen-Machting heraus-subtrahieren?

Das direkt geht nicht, aber der Umstand, dass IPv4 mit NAT für massiv
höhere CPU-Last sorgt, sollte bereits ausreichen, um den Zusammenhang
zu verstehen, zumindest für Leute wie mich, die sich damit auskennen.

[Wuns Haerst]

Das ist aber gelogen.

[Marco Moock]

Am Samstag, 23. Juli 2022, um 20:36:03 Uhr schrieb Wuns Haerst:

> Ja, ich bin zu doof, um aus Beleidigungen Sachargumente herauszulesen.

Nein, du bist nicht intelligent genug, technische Zusammenhänge zu
verstehen, auch wenn man es dir 100x erklärt. Ist wie bei Religionen.
Die glauben einfach ohne zu wissen und wenn man Ihnen sagt, dass es
Blödsinn ist, flippen sie aus. Gehe bitte zu deiner Sekte, da gehörst
du hin - hier nicht.

[Wuns Haerst]

Die Zeit für's NAT-Mapping fällt ggü. der Zeit für die Übertragung
auf der Leitung echt nicht ins Gewicht.

[Arno Welzel]

Wuns Haerst:

> Am 23.07.2022 um 19:43 schrieb Arno Welzel:
[...]

>> Von mir aus zu google.de über IPv4: 19-22 ms
>> Von mir aus zu google.de über IPv6: 17-19 ms
>
> Ganz sicher auch über die selbe Route, ne ?

Weil Du mir nicht glaubst, vielleicht Anderen:

<https://www.retevia.net/fast/>
<https://www.arin.net/blog/2019/06/25/why-is-ipv6-faster/>
<https://www.youtube.com/watch?v=JFPQ5e52-vg>

Aber Du kannst sicher *fundiert* darlegen, wieso das alles falsch ist.

[Arno Welzel]

Wuns Haerst:

> Am 23.07.2022 um 20:35 schrieb Marco Moock:

[...]

>> So würde ich dich nichtmal nennen, wäre schon vom Niveau her unpassend,
>> denn nichtmal ein Trottel würde so blödes Zeug schreiben wie du.
>
> Da brauch ich gar nix zu testen, das versteht jeder, dass die
> Übertragung von mehr Daten auf dem selben Link länger dauert.
> Und wenn das länger dauert, dann stapeln sich in der Sende
> -Queue auch mehr Daten an.

Ja, wenn man von der Materie keine Ahnung hat, mag man das so sehen.

[Arno Welzel]

Wuns Haerst:

> Am 23.07.2022 um 20:31 schrieb Marco Moock:
>> Am Samstag, 23. Juli 2022, um 19:29:18 Uhr schrieb Wuns Haerst:

[...]

>>> Dann spiel mal, das geht über IPv6 schlechter.
>>> Daher nutzen Leute die sich auch irgendwelche x-100-Hz-Monitore
>>> kaufen eben auch IPv4.
>
>> Die wenigsten Spieler machen sich darüber Gedanken. ...
>
> Die besagten die auch beim Bildschirm auf die letzten Optimierungen
> achten schon.

Nein, nur Du ganz allein. Und Du glaubst, dass deine
Hobby-Bastel-Erfahrungen relevant wären. Es ist nicht schlimm, wenn man
nicht alles weiß - man sollte nur auch irgendwann aufhören so zu tun,
als wäre das nicht so.

[Arno Welzel]

Wuns Haerst:

> Am 23.07.2022 um 19:44 schrieb Arno Welzel:
>> Wuns Haerst:
>>
>>> Am 23.07.2022 um 19:07 schrieb Arno Welzel:
>>>> Wuns Haerst:
>>>>
>>>>> Am 23.07.2022 um 18:36 schrieb Juergen Ilse:
>>>> [...]
>>>>>> Unfug. Warum sollte sichh aus laengeren Adressen eine hoehhere latenz
>>>>>> ergeben? Wenn sich fuer manche Ziele bei IPv6 eine hoehere atenz er-
>>>>>> gibt, hat das mit der Adresslaenge sichher nichts zu tun.
>>>>>
>>>>> Doch, sicher, weil die Pakete ja größer werden.
>>>>
>>>> Du kannst sicher konkret vorrechnen, wie sich der längere Header bei
>>>> IPv6 konkret auf die Latenz auswirkt.
>>>
>>> Da muss ich nix vorrechnen, das kannste selbst.
>>
>> Wieso sollte ich? Du hast etwas behauptet, also belege es auch.
>
> Nimm einen kleinen Block, wie das bei Echtzeit-Daten für Spiele üblich
> ist, der hat dann sagen wir mal 100 Byte. Wenn Du dann noch 2 * 3 * 32
> Bit draufrechnest, dann sinds halt 124 Byte. Ich glaub zwar nicht, dass
> Du ermitteln kannst wieviel 124 / 100 sind, aber andere werden das
> sicher verstehen.

Das ist kein Beleg. Irgendwelche Grundschul-Rechnungen kann ich auch
anführen.

[Arno Welzel]

Wuns Haerst:

Doch, tut es.

[Marco Moock]

Am Samstag, 23. Juli 2022, um 20:42:35 Uhr schrieb Wuns Haerst:

> Die Zeit für's NAT-Mapping fällt ggü. der Zeit für die Übertragung
> auf der Leitung echt nicht ins Gewicht.

Stelle das doch mal quantitativ gegenüber. Solltest du im Studium
gelernt haben.
Meine Praxis sagt mir: IPv6 ist performanter.
Widerlege daher mal bitte meine These durch einen Gegenbeweis.

Falls du das nicht kannst, fasse ich das so auf, dass du sowas halt
nicht kannst. Pech für dich.

[Marco Moock]

Wenn der Hanswurst das meint. Interessiert halt Fachleute nicht die
Bohne.
Marlboro meint auch, dass Rauchen gut ist.

[Marco Moock]

Am Samstag, 23. Juli 2022, um 20:48:54 Uhr schrieb Arno Welzel:

> Das ist kein Beleg. Irgendwelche Grundschul-Rechnungen kann ich auch
> anführen.

Die zudem unvollständig sind, weil eben nur ein Teil betrachtet wird.

[Juergen Ilse]

Hallo,

In de.comp.security.misc Wuns Haerst <Wuns....@wurstfabrik.at> wrote:
> Da brauch ich gar nix zu testen, das versteht jeder, dass die
> Übertragung von mehr Daten auf dem selben Link länger dauert.

Ist denn in der Praxis IPv6 Pakete groesser als IPv4 Pakete der *selben*
(Echtzeit-) Anwendung? Zeig doch mal die Hheader des mitgesnifften Traffics
in beiden Faellen her, damit wir vergleichen koennen. Auch die Struktur der
Header hat sich bei IPv6 geaendert. Ein direkter Vergleichh ist daher nur
moeglichh, wenn man direkt den IPv4 und IPv6 Traffic der *selben* Anwendung
vergleicht. Und nein, die Laengen der Adressen sind nicht unbedingt der
einzig relevante Punkt.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Juergen Ilse]

Hallo,

In de.comp.security.misc Wuns Haerst <Wuns....@wurstfabrik.at> wrote:

> Am 23.07.2022 um 19:07 schrieb Arno Welzel:

>> Wuns Haerst:
>>

>>> Am 23.07.2022 um 18:36 schrieb Juergen Ilse:
>> [...]
>>>> Unfug. Warum sollte sichh aus laengeren Adressen eine hoehhere latenz
>>>> ergeben? Wenn sich fuer manche Ziele bei IPv6 eine hoehere atenz er-
>>>> gibt, hat das mit der Adresslaenge sichher nichts zu tun.
>>>
>>> Doch, sicher, weil die Pakete ja größer werden.
>>
>> Du kannst sicher konkret vorrechnen, wie sich der längere Header bei
>> IPv6 konkret auf die Latenz auswirkt.
>
> Da muss ich nix vorrechnen, das kannste selbst.

> Wenn ich einen 10GBit-Link habe, dann ist das ne Milchmädchen-Rechnung
> zu ermitteln, wieviel zusätzliche 3 * 32 Bit an Übertragung dauern.

Zeig bitte konkrete Messungen statt dummen Geschwafel.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Juergen Ilse]

Hallo,

In de.comp.security.misc Wuns Haerst <Wuns....@wurstfabrik.at> wrote:

> Nimm einen kleinen Block, wie das bei Echtzeit-Daten für Spiele üblich
> ist, der hat dann sagen wir mal 100 Byte. Wenn Du dann noch 2 * 3 * 32
> Bit draufrechnest, dann sinds halt 124 Byte. Ich glaub zwar nicht, dass
> Du ermitteln kannst wieviel 124 / 100 sind, aber andere werden das
> sicher verstehen.

Erzaehl doch mal: wie lang ist ein IPv4 Hheader mindestens? Wie lang ist
ein IPv4 Header hoechstens? Wie lang ist der fixed IPv6 Header?

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Wuns Haerst]

Am 24.07.2022 um 04:32 schrieb Juergen Ilse:
> Hallo,
>
> In de.comp.security.misc Wuns Haerst <Wuns....@wurstfabrik.at> wrote:
>> Da brauch ich gar nix zu testen, das versteht jeder, dass die
>> Übertragung von mehr Daten auf dem selben Link länger dauert.
>
> Ist denn in der Praxis IPv6 Pakete groesser als IPv4 Pakete der *selben*

> (Echtzeit-) Anwendung? ...

Wenn ich volle MTUs habe macht das anteilig nicht viel aus.
Aber bei Spielen haste irgendwelche Positions und Bewegungs-Daten
von minimalem Umfang, und da fallen die zusätzlichen 24 Byte pro
Paket schon ins Gewicht.

> (Echtzeit-) Anwendung? Zeig doch mal die Hheader des mitgesnifften Traffics
> in beiden Faellen her, damit wir vergleichen koennen.

Ehrlich gesagt hab ich da von dir was andres erwartest, denn
gerade Du solltest die Unterschiede in der Header-Größe kennen.

[Wuns Haerst]

Dann erklär mir mal was da algorithmisch passiert.

[Wuns Haerst]

Am 23.07.2022 um 20:49 schrieb Marco Moock:
> Am Samstag, 23. Juli 2022, um 20:42:35 Uhr schrieb Wuns Haerst:
>
>> Die Zeit für's NAT-Mapping fällt ggü. der Zeit für die Übertragung
>> auf der Leitung echt nicht ins Gewicht.
>
> Stelle das doch mal quantitativ gegenüber. Solltest du im Studium
> gelernt haben.

Du kannst auf der billigst heute gängigen CPU auf einem Kern ohne
SMT und mit nur mit einem Speicher-Kanal sicher locker 10 Mio Pakete
pro Sekunde mappen.

[Wuns Haerst]

20 vs. 40 Byte.

[Wuns Haerst]

Was soll man da messen?
Wenn ich da 120 statt 100 Byte übertragen muss, dann kann
man sich das in 30s ausrechnen wenn man den Link kennt.

[Wuns Haerst]

Am 23.07.2022 um 20:41 schrieb Marco Moock:
> Am Samstag, 23. Juli 2022, um 20:36:03 Uhr schrieb Wuns Haerst:
>
>> Ja, ich bin zu doof, um aus Beleidigungen Sachargumente herauszulesen.
>
> Nein, du bist nicht intelligent genug, technische Zusammenhänge zu
> verstehen, auch wenn man es dir 100x erklärt. Ist wie bei Religionen.

Wenn Du meinst so intelligent zu sein, dann erkläre mir mal welche
Datenstruktur und welcher Algorithmus beim Mappen von NAT angeblich
den Durchsatz limitiert. Wenn man das sagen können will, dann muss
man genau das wissen.

[Marco Moock]

Am Sonntag, 24. Juli 2022, um 06:19:33 Uhr schrieb Wuns Haerst:

> Wenn Du meinst so intelligent zu sein, dann erkläre mir mal welche
> Datenstruktur und welcher Algorithmus beim Mappen von NAT angeblich
> den Durchsatz limitiert. Wenn man das sagen können will, dann muss
> man genau das wissen.

Hatten wir schon 10 mal.
Da gibt ne Tabelle mit Zuordnungen und gegen diese muss die Adresse
geprüft werden. Einfacher Vergleich. Ist übrigens Thema in jeder
Fachinformatiker-Ausbildung.

[Marco Moock]

Am Sonntag, 24. Juli 2022, um 06:13:43 Uhr schrieb Wuns Haerst:

> Ehrlich gesagt hab ich da von dir was andres erwartest, denn
> gerade Du solltest die Unterschiede in der Header-Größe kennen.

Kennt er doch. Du bist jetzt aber im Zugzwang, weil du uns nicht die
Mitschnitte lieferst, die mit IPv4 schneller sein sollen.

[Marco Moock]

Am Sonntag, 24. Juli 2022, um 06:14:32 Uhr schrieb Wuns Haerst:

> Dann erklär mir mal was da algorithmisch passiert.

Einfache Vergleiche. Kapiert jeder Schüler, der auch 2+3=5 versteht.

[Marco Moock]

Am Sonntag, 24. Juli 2022, um 06:15:45 Uhr schrieb Wuns Haerst:

> Du kannst auf der billigst heute gängigen CPU auf einem Kern ohne
> SMT und mit nur mit einem Speicher-Kanal sicher locker 10 Mio Pakete
> pro Sekunde mappen.

Nur hat so ein Router sowas nicht und der soll auch nicht wie ein PC
100 Watt verbrauchen, damit du vermeintlich Recht haben kannst. Es hat
Gründe, warum Provider, die CG-NAT bieten, auch IPv6 bieten. Dann haben
die nämlich diesen Traffic schon aus dem Übersetzer raus.

[Marco Moock]

Am Sonntag, 24. Juli 2022, um 06:18:04 Uhr schrieb Wuns Haerst:

> Was soll man da messen?

Alle Einflüsse und nicht nur die, die dir gerade gefallen.

> Wenn ich da 120 statt 100 Byte übertragen muss, dann kann
> man sich das in 30s ausrechnen wenn man den Link kennt.

Dann lässt du einige Sachen einfach weg. Ist ungefähr so dämlich wie
wenn du sagst, dass Autofahren doch kostenlos ist, weil man während der
Fahrt nicht zahlen muss, aber du ignorierst dabei komplett, dass du
auch Treibstoff kaufen musst. Auf diesem Niveau argumentierst du hier
und hältst dich für toll. Nur kann das jedes Kindergartenkind
wesentlich besser.

[Juergen Ilse]

Er hat ja noch ichht einmal meine Frage zu den Headergoessen bei IPv4
und IPv6 beantwortet. Nein der Unterschied betraegt nicht genau 24 Bte ...

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)