Discussion:
Privacy Extensions sind defekt
(zu alt für eine Antwort)
Wuns Haerst
2022-07-22 04:05:24 UTC
Permalink
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
2022-07-22 08:38:46 UTC
Permalink
Post by 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
2022-07-22 11:45:30 UTC
Permalink
Post by Marco Moock
Post by 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.
Post by 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.
Marco Moock
2022-07-22 12:15:38 UTC
Permalink
Post by Wuns Haerst
Post by Marco Moock
Post by 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.
Post by Wuns Haerst
Post by 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.
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.
Juergen Ilse
2022-07-22 15:22:08 UTC
Permalink
Hallo,
Post by Marco Moock
Post by Wuns Haerst
Post by Marco Moock
Post by 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.
Post by Marco Moock
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 ...
Post by Marco Moock
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)
Marco Moock
2022-07-22 15:32:42 UTC
Permalink
Post by 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.
Juergen Ilse
2022-07-22 17:08:30 UTC
Permalink
Hallp,
Post by Marco Moock
Post by 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?
Post by Marco Moock
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 (***@usenet-verwaltung.de)
Marco Moock
2022-07-22 17:38:11 UTC
Permalink
Post by 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.
Juergen Ilse
2022-07-22 17:43:30 UTC
Permalink
Hallo,
Post by Marco Moock
Post by 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.
Post by Marco Moock
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).
Post by Marco Moock
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 (***@usenet-verwaltung.de)
Marco Moock
2022-07-22 18:39:09 UTC
Permalink
Post by Juergen Ilse
Post by Marco Moock
Post by 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.
Post by Juergen Ilse
Post by Marco Moock
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.
Juergen Ilse
2022-07-22 15:15:40 UTC
Permalink
Hallo,
Post by Wuns Haerst
Post by Marco Moock
Post by 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 (***@usenet-verwaltung.de)
Paul Muster
2022-07-22 16:12:25 UTC
Permalink
Post by Juergen Ilse
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
2022-07-22 17:27:32 UTC
Permalink
Hallo,
Post by Paul Muster
Post by Juergen Ilse
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?
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 (***@usenet-verwaltung.de)
Paul Muster
2022-07-22 20:26:53 UTC
Permalink
Post by Juergen Ilse
Post by Paul Muster
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....
Post by Juergen Ilse
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
Arno Welzel
2022-07-23 04:04:32 UTC
Permalink
[...]
Post by Wuns Haerst
Post by 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
Wuns Haerst
2022-07-23 13:21:33 UTC
Permalink
Post by Arno Welzel
[...]
Post by Wuns Haerst
Post by 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
2022-07-23 14:05:25 UTC
Permalink
Post by Wuns Haerst
Post by Arno Welzel
[...]
Post by Wuns Haerst
Post by 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.
Post by Wuns Haerst
Daher sollte man es einfach meiden.
Dich sollten wir meiden.
Post by Wuns Haerst
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
2022-07-23 14:37:15 UTC
Permalink
Post by Marco Moock
Post by Wuns Haerst
Post by Arno Welzel
[...]
Post by Wuns Haerst
Post by 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.
Post by Marco Moock
Post by Wuns Haerst
Daher sollte man es einfach meiden.
Dich sollten wir meiden.
Post by Wuns Haerst
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
2022-07-23 14:42:53 UTC
Permalink
Post by Wuns Haerst
Post by 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.
Post by Wuns Haerst
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.
Post by Wuns Haerst
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
2022-07-23 15:01:51 UTC
Permalink
Post by Marco Moock
Post by Wuns Haerst
Post by 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.
Post by Marco Moock
Post by Wuns Haerst
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.
Post by Marco Moock
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.
Post by Marco Moock
Post by Wuns Haerst
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.
Post by Marco Moock
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.
Juergen Ilse
2022-07-23 16:44:17 UTC
Permalink
Hallo,
Post by Wuns Haerst
Post by Marco Moock
Post by Wuns Haerst
Post by 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 ...
Post by Wuns Haerst
Post by Marco Moock
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 (***@usenet-verwaltung.de)
Wuns Haerst
2022-07-23 17:04:40 UTC
Permalink
Post by Juergen Ilse
Hallo,
Post by Wuns Haerst
Post by Marco Moock
Post by Wuns Haerst
Post by 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 ...
Post by Wuns Haerst
Post by Marco Moock
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.
Geht's auch mit Sachargumenten ?
Marco Moock
2022-07-23 18:28:28 UTC
Permalink
Post by Wuns Haerst
Geht's auch mit Sachargumenten ?
Nein, denn für die bist du nicht zugänglich.
Wuns Haerst
2022-07-23 18:36:03 UTC
Permalink
Post by Marco Moock
Post by Wuns Haerst
Geht's auch mit Sachargumenten ?
Nein, denn für die bist du nicht zugänglich.
Ja, ich bin zu doof, um aus Beleidigungen Sachargumente herauszulesen.
Marco Moock
2022-07-23 18:41:06 UTC
Permalink
Post by 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
2022-07-24 04:19:33 UTC
Permalink
Post by Marco Moock
Post by 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.
Post by Marco Moock
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.
Marco Moock
2022-07-24 05:50:38 UTC
Permalink
Post by 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
2022-07-23 18:28:09 UTC
Permalink
Post by 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. :-)
Wuns Haerst
2022-07-23 15:04:02 UTC
Permalink
Post by 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.
Marco Moock
2022-07-23 18:29:08 UTC
Permalink
Post by Wuns Haerst
Post by 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.
Wuns Haerst
2022-07-23 18:36:54 UTC
Permalink
Post by Marco Moock
Post by Wuns Haerst
Post by 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?
Wie willst Du denn aus einer absoluten Latenz die Zeit
für's Routen-Machting heraus-subtrahieren?
Marco Moock
2022-07-23 18:39:51 UTC
Permalink
Post by Wuns Haerst
Post by Marco Moock
Post by Wuns Haerst
Post by 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.
Post by Wuns Haerst
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
2022-07-23 18:41:50 UTC
Permalink
Post by Marco Moock
Post by Wuns Haerst
Post by Marco Moock
Post by Wuns Haerst
Post by 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.
Post by Wuns Haerst
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.
Das ist aber gelogen.
Marco Moock
2022-07-23 18:50:34 UTC
Permalink
Post by Wuns Haerst
Post by Marco Moock
Post by Wuns Haerst
Post by Marco Moock
Post by Wuns Haerst
Post by 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.
Post by Wuns Haerst
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.
Das ist aber gelogen.
Wenn der Hanswurst das meint. Interessiert halt Fachleute nicht die
Bohne.
Marlboro meint auch, dass Rauchen gut ist.
Arno Welzel
2022-07-23 16:26:41 UTC
Permalink
Wuns Haerst:

[...]
Post by 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.
Post by Wuns Haerst
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
https://arnowelzel.de
Wuns Haerst
2022-07-23 16:33:13 UTC
Permalink
Post by Arno Welzel
[...]
Post by 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.
Post by Arno Welzel
Post by Wuns Haerst
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.
Arno Welzel
2022-07-23 17:13:53 UTC
Permalink
Post by Wuns Haerst
Post by Arno Welzel
[...]
Post by 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.
Post by Wuns Haerst
Post by Arno Welzel
Post by Wuns Haerst
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?
--
Arno Welzel
https://arnowelzel.de
Wuns Haerst
2022-07-23 17:29:18 UTC
Permalink
Post by Arno Welzel
Post by Wuns Haerst
Post by Arno Welzel
[...]
Post by 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?
Post by Arno Welzel
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.
Post by Arno Welzel
Post by Wuns Haerst
Post by Arno Welzel
Post by Wuns Haerst
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.
- 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.
Post by Arno Welzel
Ja, es sind mehrere Server, die dafür im Einsatz sind.
Welche Anwendungen hattest Du denn so im Sinn?
Arno Welzel
2022-07-23 17:43:28 UTC
Permalink
Post by Wuns Haerst
Post by Arno Welzel
Post by Wuns Haerst
Post by Arno Welzel
[...]
Post by 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.
Post by Wuns Haerst
Post by Arno Welzel
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.
Post by 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.
Und alle weiteren Faktoren blendest Du einfach mal aus, schon klar.

[...]
Post by Wuns Haerst
Post by Arno Welzel
Post by Wuns Haerst
Interessante Echtzeit-Anwendungen die Du da schilderst.
- 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?
Post by Wuns Haerst
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
https://arnowelzel.de
Wuns Haerst
2022-07-23 17:49:45 UTC
Permalink
Post by Arno Welzel
Post by Wuns Haerst
Post by Arno Welzel
Post by Wuns Haerst
Post by Arno Welzel
[...]
Post by 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.
Post by Arno Welzel
Post by Wuns Haerst
Post by Arno Welzel
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 ?
Post by Arno Welzel
Soll ich es Dir live vorführen? Kannst gerne per Screen-Sharing
zuschauen. E-Mail-Adresse ist gültig.
Post by 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.
Und alle weiteren Faktoren blendest Du einfach mal aus, schon klar.
Weil weitere Faktoren anteilig keine Rolle spielen.
Post by Arno Welzel
[...]
Post by Wuns Haerst
Post by Arno Welzel
Post by Wuns Haerst
Interessante Echtzeit-Anwendungen die Du da schilderst.
- 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.
Post by Arno Welzel
Post by Wuns Haerst
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.
Marco Moock
2022-07-23 18:35:01 UTC
Permalink
Post by Wuns Haerst
Post by 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 ?
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.
Post by Wuns Haerst
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
Post by Wuns Haerst
Prinzipielle Überlegungen spielen da keine Rolle.
Es sind Praxiserfahrungen, die das bestätigen.
Post by Wuns Haerst
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
2022-07-23 18:38:10 UTC
Permalink
Post by Marco Moock
Post by Wuns Haerst
Post by 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 ?
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.
Post by Wuns Haerst
Weil weitere Faktoren anteilig keine Rolle spielen.
Falsch, das kann man sogar Live erleben, einfach mal die CPU-Last
abfragen.
https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption
Post by Wuns Haerst
Prinzipielle Überlegungen spielen da keine Rolle.
Es sind Praxiserfahrungen, die das bestätigen.
Post by Wuns Haerst
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.
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.
Arno Welzel
2022-07-23 18:45:44 UTC
Permalink
[...]
Post by Wuns Haerst
Post by 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
https://arnowelzel.de
Juergen Ilse
2022-07-24 02:32:35 UTC
Permalink
Hallo,
Post by 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.
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 (***@usenet-verwaltung.de)
Wuns Haerst
2022-07-24 04:13:43 UTC
Permalink
Post by Juergen Ilse
Hallo,
Post by 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.
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.
Post by Juergen Ilse
(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.
Post by Juergen Ilse
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,
Marco Moock
2022-07-24 05:51:35 UTC
Permalink
Post by 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.
Arno Welzel
2022-07-23 18:44:39 UTC
Permalink
[...]
Post by Wuns Haerst
Post by 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/>


Aber Du kannst sicher *fundiert* darlegen, wieso das alles falsch ist.
--
Arno Welzel
https://arnowelzel.de
Marco Moock
2022-07-23 18:31:53 UTC
Permalink
Post by 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?
Post by 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. Des Weiteren
könntest du ja mal Beispiele mit Messungen bringen, statt das einfach
nur so zu behaupten.
Wuns Haerst
2022-07-23 18:39:17 UTC
Permalink
Post by Marco Moock
Post by 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.
Post by Marco Moock
Post by 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.
Arno Welzel
2022-07-23 18:47:19 UTC
Permalink
[...]
Post by Wuns Haerst
Post by Marco Moock
Post by 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
https://arnowelzel.de
Bastian Blank
2022-07-23 18:07:56 UTC
Permalink
Post by Arno Welzel
Post by 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.
Post by Wuns Haerst
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
Marc Haber
2022-07-23 15:09:47 UTC
Permalink
Post by Marco Moock
Und daran merkt man mal wieder, dass du einfach NULL Ahnung hast
Das ist ein Troll! Warum verschwendest Du Deine Zeit mit ihm?
--
-------------------------------------- !! 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
Wuns Haerst
2022-07-23 16:15:25 UTC
Permalink
Post by Marc Haber
Post by Marco Moock
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
2022-07-23 16:29:39 UTC
Permalink
Post by Wuns Haerst
Post by Marc Haber
Post by Marco Moock
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.
Hmmm... <http://wurstfabrik.at>
--
Arno Welzel
https://arnowelzel.de
Marco Moock
2022-07-23 18:36:39 UTC
Permalink
Post by Arno Welzel
Hmmm... <http://wurstfabrik.at>
Ob der dazu in der Lage ist, nen Webserver zu betreiben?
Arno Welzel
2022-07-23 16:24:17 UTC
Permalink
Post by Wuns Haerst
Post by Arno Welzel
[...]
Post by Wuns Haerst
Post by 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
https://arnowelzel.de
Juergen Ilse
2022-07-23 16:36:33 UTC
Permalink
Hallo,
Post by Wuns Haerst
Post by Arno Welzel
[...]
Post by Wuns Haerst
Post by 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 ...
Post by Wuns Haerst
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 (***@usenet-verwaltung.de)
Wuns Haerst
2022-07-23 17:04:12 UTC
Permalink
Post by Juergen Ilse
Hallo,
Post by Wuns Haerst
Post by Arno Welzel
[...]
Post by Wuns Haerst
Post by 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.
Post by Juergen Ilse
Post by Wuns Haerst
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.
Arno Welzel
2022-07-23 17:07:29 UTC
Permalink
[...]
Post by Wuns Haerst
Post by 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
https://arnowelzel.de
Wuns Haerst
2022-07-23 17:30:41 UTC
Permalink
Post by Arno Welzel
[...]
Post by Wuns Haerst
Post by 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.
Arno Welzel
2022-07-23 17:44:45 UTC
Permalink
Post by Wuns Haerst
Post by Arno Welzel
[...]
Post by Wuns Haerst
Post by 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.
Post by Wuns Haerst
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?
--
Arno Welzel
https://arnowelzel.de
Wuns Haerst
2022-07-23 17:52:22 UTC
Permalink
Post by Arno Welzel
Post by Wuns Haerst
Post by Arno Welzel
[...]
Post by Wuns Haerst
Post by 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.
Post by Arno Welzel
Post by Wuns Haerst
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.
Marco Moock
2022-07-23 18:38:42 UTC
Permalink
Post by 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.
Wuns Haerst
2022-07-23 18:42:35 UTC
Permalink
Post by Marco Moock
Post by 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.
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
2022-07-23 18:49:17 UTC
Permalink
Post by Wuns Haerst
Post by Marco Moock
Post by 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.
Die Zeit für's NAT-Mapping fällt ggü. der Zeit für die Übertragung
auf der Leitung echt nicht ins Gewicht.
Doch, tut es.
--
Arno Welzel
https://arnowelzel.de
Wuns Haerst
2022-07-24 04:14:32 UTC
Permalink
Post by Arno Welzel
Post by Wuns Haerst
Post by Marco Moock
Post by 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.
Die Zeit für's NAT-Mapping fällt ggü. der Zeit für die Übertragung
auf der Leitung echt nicht ins Gewicht.
Doch, tut es.
Dann erklär mir mal was da algorithmisch passiert.
Marco Moock
2022-07-24 05:52:18 UTC
Permalink
Post by 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
2022-07-23 18:49:45 UTC
Permalink
Post by 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.
Wuns Haerst
2022-07-24 04:15:45 UTC
Permalink
Post by Marco Moock
Post by 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.
Post by Marco Moock
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
2022-07-24 05:53:25 UTC
Permalink
Post by 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.
Arno Welzel
2022-07-23 18:48:54 UTC
Permalink
Post by Wuns Haerst
Post by Arno Welzel
Post by Wuns Haerst
Post by Arno Welzel
[...]
Post by Wuns Haerst
Post by 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
https://arnowelzel.de
Marco Moock
2022-07-23 19:02:04 UTC
Permalink
Post by 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
2022-07-24 03:10:30 UTC
Permalink
Hallo,
Post by Wuns Haerst
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 (***@usenet-verwaltung.de)
Wuns Haerst
2022-07-24 04:16:45 UTC
Permalink
Post by Juergen Ilse
Hallo,
Post by Wuns Haerst
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?
20 vs. 40 Byte.
Juergen Ilse
2022-07-24 02:49:10 UTC
Permalink
Hallo,
Post by Wuns Haerst
Post by Arno Welzel
[...]
Post by Wuns Haerst
Post by 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 (***@usenet-verwaltung.de)
Wuns Haerst
2022-07-24 04:18:04 UTC
Permalink
Post by Juergen Ilse
Hallo,
Post by Wuns Haerst
Post by Arno Welzel
[...]
Post by Wuns Haerst
Post by 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.
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.
Marco Moock
2022-07-24 05:56:16 UTC
Permalink
Post by Wuns Haerst
Was soll man da messen?
Alle Einflüsse und nicht nur die, die dir gerade gefallen.
Post by Wuns Haerst
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.

Thomas Noll
2022-07-22 11:53:17 UTC
Permalink
Post by 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.
--
Dummheit und Gewissheit sind siamesische Zwillinge.
Ganz sicher!
Marco Moock
2022-07-22 12:17:50 UTC
Permalink
Post by Thomas Noll
Post by 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.
Paul Muster
2022-07-22 16:17:15 UTC
Permalink
Post by Marco Moock
Post by 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
Marco Moock
2022-07-22 17:41:45 UTC
Permalink
Post by 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
2022-07-22 18:02:56 UTC
Permalink
Hallo,
Post by Marco Moock
Post by 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.
Post by Marco Moock
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 ...
Post by Marco Moock
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 (***@usenet-verwaltung.de)
Marco Moock
2022-07-22 18:40:36 UTC
Permalink
Post by 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
2022-07-22 19:55:22 UTC
Permalink
Hallo,
Post by Marco Moock
Post by 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.
Genau das sollen die PE leisten, nur ohne die Erfordernis komplexer
ALGs, um aufwendigere Netzwerkprotokolle durch NAT durchzubekommen.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
Paul Muster
2022-07-22 20:22:16 UTC
Permalink
Post by Marco Moock
Post by 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
2022-07-22 21:29:44 UTC
Permalink
Hallo,
Post by Paul Muster
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 (***@usnet-verwaltung.de)
Marco Moock
2022-07-23 04:56:41 UTC
Permalink
Am Fri, 22 Jul 2022 22:22:16 +0200
Post by Paul Muster
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.
Juergen Ilse
2022-07-22 15:23:55 UTC
Permalink
Hallo,
Post by Thomas Noll
Post by 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 (***@usenet-verwaltung.de)
Paul Muster
2022-07-22 16:19:36 UTC
Permalink
Post by Marco Moock
Post by 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.
Post by Marco Moock
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?
Post by Marco Moock
Und wenn du bei IPv6 NAT machen willst, auch das ist
kein Problem.
Macht nur keiner. Auch keine Fritzbox etc.


mfG Paul
Marco Moock
2022-07-22 17:44:56 UTC
Permalink
Post by 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.
Post by Paul Muster
Post by Marco Moock
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
2022-07-22 18:05:02 UTC
Permalink
Post by Marco Moock
Post by 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 (***@usenet-verwaltung.de)
Marco Moock
2022-07-22 20:10:42 UTC
Permalink
Post by 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
2022-07-22 20:32:38 UTC
Permalink
Post by Marco Moock
Post by 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)?
Post by Marco Moock
Bei Apple iOS ist das glaub auch standardmäßig aktiv.
Nein. Es wurden meines Wissens nach nur per Default die privacy extensions
eingeschhhaltet.
Post by Marco Moock
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 (***@usenet-verwaltung.de)
Marc SCHAEFER
2022-07-22 20:41:16 UTC
Permalink
Post by Juergen Ilse
Post by Marco Moock
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).
Juergen Ilse
2022-07-22 21:34:40 UTC
Permalink
Hallo,
Post by Marc SCHAEFER
Post by Juergen Ilse
Post by Marco Moock
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)?
https://source.android.com/devices/tech/connect/wifi-mac-randomization-behavior
Es ist aber defaultmässig stateful (pro ESS).
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 (***@usenet-verwaltung.de)
Marc Haber
2022-07-23 07:16:57 UTC
Permalink
Post by Juergen Ilse
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?

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
Marco Moock
2022-07-23 05:02:34 UTC
Permalink
Am 22 Jul 2022 20:32:38 GMT
Post by Juergen Ilse
Post by Marco Moock
Post by 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.
Post by Juergen Ilse
Post by Marco Moock
Bei Apple iOS ist das glaub auch standardmäßig aktiv.
Nein. Es wurden meines Wissens nach nur per Default die privacy
extensions eingeschhhaltet.
Post by Marco Moock
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.
Post by Juergen Ilse
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
2022-07-23 07:15:50 UTC
Permalink
Post by Juergen Ilse
Post by Marco Moock
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
Thomas Klix
2022-07-22 15:06:04 UTC
Permalink
Post by 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.
Lass mich raten: 192.168.178.20?

Thomas
Christian Weisgerber
2022-07-22 14:53:57 UTC
Permalink
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 ***@mips.inka.de
Loading...