IPv6 Homeserver - feste IP ?

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo liebe Community
    Ich habe ein Raspberry Pi zu Hause stehen und möchte es gerne als Homeserver nutzen. Und zwar habe ich eine DS Lite Anbindung von Unitymedia und muss mein Raspberry Pi entsprechend über IPv6 von außen ansprechen. Gehen wir mal davon aus, dass folgendes funktioniert (noch nicht ausprobiert): https://forum.ubuntuusers.de/topic/ssh-und-ipv6/
    Ich hätte also eine funktionierende IPv6-Anbindung von außerhalb zu meinem Pi. Jetzt kommt der Teil, bei dem ich einfach zu wenig Ahnung von Netzwerken habe (bzw wie das Internet allgemein funktioniert... :denker: :(
    Kann ich mir eine feste IPv6-Adresse sichern ? Sodass ich mir die Adresse auf einen Zettel schreiben kann und dann immer zB ein ssh-Terminal zu dieser Adresse aufbauen kann, oder muss ich zwingend die Dienste eines Anbieters wie dynDNS in Anspruch nehmen, um somit einen festen Domainnamen (statt einer festen IP) zu erhalten ? Schön fände ich eine feste IP, weil ich mich dann um nichts kümmern müsste (ich weiß, dynDNS ist auch nur eine Mail im Monat) und ich sowieso der Einzige bin, der drauf zugreifen will und soll. (möchte Dienste wie ownCloud und git nutzen)

    Schonmal vielen Dank im voraus
    LG treecake


  • Kann ich mir eine feste IPv6-Adresse sichern ?

    Nein, denn bei Unitymedia gibt es keine feste IPv6-Adresse.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Kann ich mir eine feste IPv6-Adresse sichern ?


    Nur eine "halb-feste"..... was soviel bedeutet, dass sich Deine IP solange nicht ändert, wie Dein Router nicht neu gestartet wird. Die unter IPv4 obligatorische 24h-Trennung gibts üblicherweise bei IPv6 nicht mehr. Mit dem Neustart des Routers bekommst Du bzw. Dein PI allerdings dann ganz sicher ne neue IP. Aber mit IPv6 ist es wiederrum viel einfacher als zuvor, die am PI selber zu ermitteln und sie eben an ein Online-Postfach oder per ftp auf nen Speicher in der eigenen Homepage zu senden. Und schon ist das Problem relativ komfortabel gelöst und man kommt nach nem Stromausfall trotzdem an seine IP ran.

    Einmal editiert, zuletzt von WinterUnit16246 (9. November 2016 um 19:52)

  • Vielen dank für die Antworten. Der Beitrag von ThomasL bietet eine elegante Lösung, sodass ich jederzeit auch ohne DNS-Dienste auf mein Pi zugreifen kann, selbst ohne feste IP ! Das werde ich so umsetzen.
    LG
    treecake


  • Mit dem Neustart des Routers bekommst Du bzw. Dein PI allerdings dann ganz sicher ne neue IP.

    BTW: Bei UM gibt s i. d. R. beim Neustart des Routers durch den Kunden, keine neue IP. Siehe z. B. u. a. auch diesen Thread: http://www.unitymediaforum.de/viewtopic.php?f=90&t=34123

    Es ist kein beträchtlicher Unterschied zwischen IPv4 und IPv6, in der Ermittlung der externen/öffentlichen/globalen IP-Adresse(n) auf dem PI bzw. durch den PI. Z. B.:

    Code
    dig +short myip.opendns.com @208.67.222.222


    und

    Code
    curl -B6 http://checkip6.spdyn.de


    (oder gleichwertig)

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • BTW: Bei UM gibt s i. d. R. beim Neustart des Routers durch den Kunden, keine neue IP.


    Doch, Du bekommst in jedem Fall eine neue IP.... nur kann es eben sein, wenn Connect-Lost und Re-Connect zeitlich direkt aufeinander fallen, dass Du vielleicht die gleiche IP wie zuvor bekommst. Genau das war die Aussage, die ich im Gespräch mit der UM-Technik bekommen habe. Aus Sicht des Providers ist es eine neue IP, die zum Zeitpunkt des Connects gerade frei war. Es ist aber durchaus auch möglich, dass nach Connect-Lost genau in dem Moment vielleicht jemand anders diese IP bekommt, dann hat sich Deine IP geändert. Fazit: Keine Garantie für nix..... also ist es besser, so zu tun, als wäre jeder Re-Connect mit einer neuen IP verbunden.

    Code
    Es ist kein beträchtlicher Unterschied zwischen IPv4 und IPv6, in der Ermittlung der externen/öffentlichen/globalen


    Nur insofern, dass ich sie (mit Global Scope) jetzt stattdessen einfach vom NIC nehmen kann.

    Einmal editiert, zuletzt von WinterUnit16246 (9. November 2016 um 22:28)


  • Doch, Du bekommst in jedem Fall eine neue IP....

    Naja, wenn für dich die gleiche IP auch eine neue IP ist, ... was soll man dann mit dieser Aussage:

    Zitat


    Mit dem Neustart des Routers bekommst Du bzw. Dein PI allerdings dann ganz sicher ne neue IP.


    anfangen? Ganz sicher eine neue IP, aber die neue IP ist die alte IP bzw. keine andere IP? ;)



    Nur insofern, dass ich sie (mit Global Scope) jetzt stattdessen einfach vom NIC nehmen kann.

    Wie nimmst Du ohne größeren Aufwand, die externe IPv6-Adresse vom NIC?
    Denn "scope global" können auch die ULAs sein. Z. B.:

    Code
    inet6 fd00::feed:beef:cafe:deaf/64 scope global 
          valid_lft forever preferred_lft forever

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample


  • Es ist kein beträchtlicher Unterschied zwischen IPv4 und IPv6, in der Ermittlung der externen/öffentlichen/globalen IP-Adresse(n) auf dem PI bzw. durch den PI.


    Diese Aussage ist so nicht ganz richtig, denn es gibt tatsächlich ein paar gravierende Unterschiede. Ich kann zwar noch nicht viel über Konsequenzen und möglicherweise notwendige präventive Maßnahmen sagen, aber die Unterschiede kenne ich mittlerweile. Und ich bezweifel im Moment (noch), dass Deine Lösungsvorschläge der Fremdabfrage überhaupt noch funktionieren. Also... aus folgenden Gründen:

    • Unter IPv4 bekommst Du resp. Dein Router eine ISP-IPv4, unter der sich alle Clients Deines Netzes im Internet bewegen. NAT kümmert sich darum, dass jeder korrekt bedient wird.
    • Unter IPv6 bekommst Du gar keine ISP-Endgeräte-IP mehr, die nur der Router kennt, sondern vom Provider (mindestens) ein /54er Netz. Der Router generiert sich selber eine IPv6 fürs WWW und informiert die CLients über dieses /54-Netz, damit die das ebenfalls tun können.
    • Unter IPv6 generiert jeder Client selber seine WAN-IP im /54-Netz mit Global-Scope, und jeder Client ist heute -wie früher der Router- selber Client im Web.
    • Denkbar und vermutlich auch häufiger zutreffend ist es (z.B. bei langsamen JDL2-Connects), dass ein Client zeitgleich mit mehreren WAN-IPv6 offene Verbindungen zum Internet hat, von denen bis auf eine "gültige" mehrere einen Depricated"-Status haben.... aber das ist nur lokal erkennbar. Welche der aktiven IPv6 sollen denn dann Deine http-Requests zurückgeben?
    • Ich kann mir heute auf dem Client jederzeit via SLAAC eine neue IPv6 mit Global Scope generieren


    Im Moment weiss ich noch nicht, wie das mit Ports über den Router funktioniert... ob die Weiterleitung heute überhaupt noch notwendig ist, oder ob ich das schlichtweg direkt am Client via Iptables lösen kann. Ich warte noch auf die Umschaltung. Nicht mehr lange... dann werde ich wohl wissen, wie das alles funktioniert.


    Naja, wenn für dich die gleiche IP auch eine neue IP ist, ... was soll man dann mit dieser .... Aussage anfangen? Ganz sicher eine neue IP, aber die neue IP ist die alte IP bzw. keine andere IP?

    Du alte Buchhalterseele ... :D .... tu nicht so, als wären Dir die Konsequenzen beim Wegfall der 24h-Zwangstrennung nicht bewusst. Die heutige Zwangstrennung bedeutet an einem "Knotenpunkt" eine möglicherweise sehr hohe Fluktuation beim DHCP-Server und den dort vergebenen IPs. Je nach Tageszeit und angebundener Clients ist da vermutlich extrem viel Bewegung beim Hin- und Herbewegen von freigewordenen und neuzuvergebenen IPs. Das heisst, die Wahrscheinlichkeit ist sehr hoch, dass genau in dem Moment, in dem eine IPv4 getrennt und freigegeben wird, diese IP sofort wieder neu vergeben wird.
    Genau diese Fluktuation ist bei IPv6 nicht mehr gegeben..... zumal Du als Client sowieso KEINE Provider-Endgeräte-IP mehr bekommst. Das heisst, es sorgen nur noch die Kunden für Bewegung, die nach dem PC auch den Router abschalten. Bei jedem Kunden, der seinen Router durchlaufen lässt, kann das /54er Netz monatelang stabil sein. Und bei nem Neustart wäre es eher zufällig, dass Dir ein anderer Kunde gerade in diesem Moment die alte "IP" wegschnappt. Laut Aussage eines Technikers bei UM gibt es derzeit keine gezielt wirksame Logik, die dafür sorgt, dass Du nach dem Routerneustart das gleiche /54er Netz (s.o.) wiederbekommst. Rein ISP-Vergabelogisch betrachtet ist es eine neue IP bzw. Netz-Prefix, selbst wenn sie zufällig identisch mit der zuvorigen ist.

    Einmal editiert, zuletzt von WinterUnit16246 (10. November 2016 um 14:07)


  • Welche der aktiven IPv6 sollen denn dann Deine http-Requests zurückgeben?

    Das ist von der Konfiguration abhängig. Wenn ich mein Gerät per IPv6 (evtl. auch mit einer IPv6-Freigabe im Router) erreichen will, dann werde ich die Generierung der externen IPv6-Adresse (d. h. die mit dem Präfix) nicht so konfigurieren, dass dieses Gerät gleichzeitig bzw. evtl. nur temporär mit PEs, mehrere externe IPv6-Adressen (d. h. unterschiedliche Interface-IDs) hat. Das funktioniert ohne Probleme, denn ich habe einen PI an der FB6360-cable, der per IPv6 und per IPv4 erreichbar ist.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Ja, das ist auch der Ansatz, der mir im Kopf rumschwebt.... da würde ich mich gerne später noch mal mit Dir drüber unterhalten. Ich denke, ich kann da möglicherweise noch einiges dazulernen. Aber ich muss erst mal selber überblicken, welche Änderungen sich letzten Endes wirklich für mich ergeben.

  • Du brauchst keine feste IP. Nimm afraid.org als DynDNS-Provider und mach dir eine Adresse auf IPv6. Ist kostenlos. Dann macht du dir ein Updatescript auf den PI, dass bei afraid deine IPv6 des Pi bekannt gibt und fertig. Du kannst das auch über deine Fritzbox und Portforwarding machen, aber bei UM sind die IPv6-Adressen im Netzwerk öffentlich, so dass du für jeden eine DynDNS-Adresse bei afraid anlegen kannst. Lief bei mir 2 Jahre so, problemlos.

    Willst du einen Tag lang glücklich sein, dann saufe.

    Willst du ein Jahr lang glücklich sein, dann heirate.

    Willst du ein Leben lang glücklich sein, dann fahr Yamaha.

  • Hi rpi444

    Code
    dig +short myip.opendns.com @208.67.222.222
    curl -B6 http://checkip6.spdyn.de

    Ich hatte jetzt ein paar Tage Zeit und Gelegenheit, mich mal mit den Eigenheiten von IPv6 zu befassen. Und heute bin ich zu dem Fazit gekommen, dass die obige Methode der Abfrage bei solchen "request-my-ip"-Sites unter IPv6 eigentlich völlig untauglich ist. Unter IPv4 war das eine gute Lösung, unter IPv6 ist es m.M.n. fahrlässig ... oder auch leichtsinning. Hier bin ich noch unsicher, aber Fakt ist, dass diese von der Seite zurückgegebene IP eben auch die vom System für ausgehende Connects primär verwendete IPv6 ist und das man mit dieser Surf-IP überall Spuren hinterlässt. Ich hoffe, Du kannst mich widerlegen und mir meinen Irrtum aufzeigen.....

    Zuallererst ist also festzustellen, dass die hier gelieferte IP lediglich die eine ist, mit der der PC gerade in diesem Moment eine Verbindung zu dieser Site aufgenommen hat und die momentan als aktuell gültige IP vermutlich zum allgemeinen Surfen verwendet wird. Das zweite ist, wurde diese IPv6 nicht via PE generiert, bedeutet das, dass man wegen des Wegfalls der 24h-Trennung mit einer vermutlich längerwährend gültigen IP surft und gleichermaßen auf diese IP eine Freigabe und einen DynDNS eingerichtet hat. Sorry, das ist imho ein absolutes NoGo.

    Meiner Meinung nach ist diese IP zur Meldung an einen DynDNS völlig untauglich. Eigentlich müsste diese Alltags-IPv6 wirklich bei jedem Boot mit völlig neuem 'Interface Identifier' generiert werden, um mögliche Spuren bestmöglich zu verschleiern.

    Um dann letztendlich doch via DynDNS auf meine Maschine zu kommen, denke ich, ist zuallerst ein statischer 'Interface Identifier' erforderlich, der einfach mit dem aktuellen ISP-Prefix vervollständig wird. Und das funktioniert am besten, in dem man sich vom NIC eine ins Web geroutete Adresse nimmt, den Prefix extrahiert und seinen eigenen 'Static Internet Identifier' hinzufügt.

    Der Prefix ist einfach zu extrahieren, der I-I ist ja bekannt und wird hinzugefügt. Das wäre z.B. die Adresse, für die ich die Router-FW für bestimmte Ports öffnen würde und die ich an den DynDNS sende:

    Code
    ip a | grep -E 'global.*mngtmpaddr' | grep -v deprecated | awk -F ' ' '{ print $2 }' | cut -d':' -f1-4

    Dann denke ich noch darüber nach, mir die bei einer Prefix-Änderung einfach zumailen zu lassen - vielleicht nach einem Stromausfall. Das wäre auch allemal eine Lösung, da ich ja jederzeit am Handy auch meine Post sehen kann. Ich bin gespannt darauf, ob Du meinen Rückschlüssen zustimmst oder eher widersprichst.... und ich hoffe, Du nimmst Dir die Zeit dafür... :)

    Einmal editiert, zuletzt von WinterUnit16246 (16. November 2016 um 18:09)


  • Der Prefix ist einfach zu extrahieren, der I-I ist ja bekannt und wird hinzugefügt. Das wäre z.B. die Adresse, für die ich die Router-FW für bestimmte Ports öffnen würde und die ich an den DynDNS sende:

    Code
    ip a | grep -E 'global.*mngtmpaddr' | grep -v deprecated | awk -F ' ' '{ print $2 }' | cut -d':' -f1-4

    Dann denke ich noch darüber nach, mir die bei einer Prefix-Änderung einfach zumailen zu lassen - vielleicht nach einem Stromausfall. Das wäre auch allemal eine Lösung, da ich ja jederzeit am Handy auch meine Post sehen kann. Ich bin gespannt darauf, ob Du meinen Rückschlüssen zustimmst oder eher widersprichst.... und ich hoffe, Du nimmst Dir die Zeit dafür... :)

    Also zu den IPv6-Adressen mit den "richtigen" oder "falschen" PE's sage ich nichts, denn die interessieren mich nicht und sind in diesem Thread auch nicht gemeint.

    Es geht um die externe IPv6-Adresse (d. h. die mit dem ISP-Präfix) mit der festen Interface-ID, ... und da denke ich nicht daran solche Klimmzüge zu machen und diese IPv6-Adresse zu extrahieren bzw. sich per eMail zusenden zu lassen, wenn diese IPv6-Adresse ganz einfach per "curl -B6 http://checkip6.spdyn.de" ermittelt werden kann.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample


  • Also zu den IPv6-Adressen mit den "richtigen" oder "falschen" PE's sage ich nichts,
    :::::
    Es geht um die externe IPv6-Adresse (d. h. die mit dem ISP-Präfix) mit der festen Interface-ID ...

    Es gibt keine richtigen und falschen IPv6 mit ISP-Prefix. Sämtliche vorhandene IPv6s mit ISP-Prefix sind gleichermaßen gültige IP's, alle können eine feste Interface-ID haben oder auch eine nur bis zum nächsten Shutdown geltende Interface-ID. Aber nur eine hat die Mac als I-ID. In den Verwendungsmöglichkeiten gibt es keinen Unterschied. Allerdings wird nur eine bestimmte IPv6 als primäre für ausgehenden Verbindungen genutzt. Und genau die primäre oder die mit der MAC als DynDNS zu verwenden ist m.M.n. die schlechteste Wahl. Aber es ist völlig gleichgültig, welche IP Du auf den DynDNS hochlädtst, die Interface-ID kann ::1 sein, Dein Geburtsdatum oder die Maße Deiner Freundin... wichtig ist nur der Präfix und die Portweiterleitung im Router auf diese I-ID. Man kann sogar für einen Remote-Zugriff mehrere IPv6 mit jeweils eigenem I-ID für verschiedene Ports auf die gleiche Maschine verwenden und die dann bei Bedarf sogar im Paketfilter in der Input-Chain unterschiedlich handhaben.

    Natürlich verwende ich meinen DynDNS... das heisst doch aber nicht, dass ich mir den Prefix nicht noch zusätzlich auf meinen Web-Space hochladen kann oder ihn mir per Mail oder SMS zusenden lassen kann. Das macht mich dann zusätzlich noch völlig unabhängig vom DynDNS. Und die Maße meiner Frau oder mein Geburtsdatum habe ich im Kopf *fg* Der DynDNS ist nur der Komfort des "festen Namens" auf eine Variable.

    Ist aber auch nicht so wichtig.... jeder wie er mag. :denker:

    Einmal editiert, zuletzt von WinterUnit16246 (16. November 2016 um 23:43)


  • Es gibt keine richtigen und falschen IPv6 mit ISP-Prefix.

    Da stimme ich dir zu.

    Es gibt aber IPv6-Adressen, die von einem Kernel, der mit "CONFIG_IPV6_PRIVACY=y" kompiliert worden ist, generiert/erneuert/verändert/anonymisiert worden sind oder von einem Kernel, der ohne "CONFIG_IPV6_PRIVACY=y" kompiliert worden ist, generiert worden sind.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Es gibt aber IPv6-Adressen, die von einem Kernel, der mit "CONFIG_IPV6_PRIVACY=y" kompiliert worden ist, generiert/erneuert/verändert/anonymisiert worden sind oder von einem Kernel, der ohne "CONFIG_IPV6_PRIVACY=y" kompiliert worden ist, generiert worden sind.

    Nein, gibt es nicht. Die Adresse ist NICHT anonymisiert, sondern einfach nur nach dem Zufallsprinzip generiert. Der Kernel verwendet speziell diese Adresse zum Aufbau neuer Verbindungen ins Internet. Die Adresse selber ist in keinster Weise unterschiedlich in ihrer Funktionalität zu anderen Global-Unicast-IPs. Sie ist lediglich beim nächsten Reboot nicht mehr vorhanden. Das "verschleiert" allerdings die eigenen Spuren im Internet, hat aber überhaupt nichts mit einem Remote-Zugriff zu tun. Die kannst Du genauso nehmen, wie jede andere auch. Es ist völlig egal, ob die primäre IPv6 einen static-I-ID oder einen I-ID mit Lifetime-Limit hat... bei beiden halte ich es generell für einen Fehler, diese IP für einen Remote-Zugriff zu verwenden. Wie ich schon sagte, es ist sinnvoll eine zufällige IP für neue Connects zu verwenden, aber eine mit static I-ID für den Remotezugriff.... die sind aber unterschiedlich, wobei die zweite nicht extern abfragbar ist. Und definitiv würde ich für solche Zwecke keine IPv6 mit HWaddr verwenden.

    Und auch zu CONFIG_IPV6_PRIVACY bist Du im Irrtum, der Kernel 3.12 war der letzte in der Ahnenreihe, der diese Parameter überhaupt noch berücksichtigt.
    Es ist wohl alles gesagt.... und der Pudding bleibt eh nicht am Nagel an der Wand hängen... :danke_ATDE:

    Einmal editiert, zuletzt von WinterUnit16246 (17. November 2016 um 11:43)


  • Nein, gibt es nicht. Die Adresse ist NICHT anonymisiert, sondern einfach nur nach dem Zufallsprinzip generiert.

    OK, aber für mich ist das "anonymisiert".


    Die Adresse selber ist in keinster Weise unterschiedlich in ihrer Funktionalität zu anderen Global-Unicast-IPs.

    Das habe ich auch nicht behauptet.


    Sie ist lediglich beim nächsten Reboot nicht mehr vorhanden.

    Je nach Kernel und Konfiguration, kann sie auch ohne Reboot "schon nicht mehr vorhanden sein".


    ..., hat aber überhaupt nichts mit einem Remote-Zugriff zu tun. Die kannst Du genauso nehmen, wie jede andere auch. Es ist völlig egal, ob die primäre IPv6 einen static-I-ID oder einen I-ID mit Lifetime-Limit hat...

    Auch hier habe ich nicht das Gegenteil behauptet.


    Und auch zu CONFIG_IPV6_PRIVACY bist Du im Irrtum, der Kernel 3.12 war der letzte in der Ahnenreihe, der diese Parameter überhaupt noch berücksichtigt.

    Du meinst den Standard-Kernel bis 3.12 inkl. (... von Linux)? Denn niemand kann dich daran hindern, deinen eigenen Kernel mit der Option "CONFIG_IPV6_PRIVACY=y" zu kompilieren.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (17. November 2016 um 11:57)

  • OK, aber für mich ist das "anonymisiert".


    Alle IP sind erst mal anonym. Der Vorteil ist es "Häufungen" zu vermeiden, um ein Tracking zu erschweren. Und eine im Web "bekannte" IP mit hoher Static-Reproduzierbarkeit auf ne eigene Server-Freigabe umzulenken ist schon arg fahrlässig. Ist mir aber auch egal... jeder wie er mag.

    Du meinst den Standard-Kernel bis 3.12 inkl. (... von Linux)? Denn niemand kann dich daran hindern, deinen eigenen Kernel mit der Option "CONFIG_IPV6_PRIVACY=y" zu kompilieren.


    Nein, ich meine, dass es diese Option seit 3.13 NICHT mehr gibt... das ist seit 3.13 nicht mehr optional, sondern im Code von ipv6/addrconf.c fest implementiert. Du kannst es nur noch über use_tempaddr = 2 ein- oder ausschalten.

    Lass gut sein.... wir kommen so nicht weiter.

    Einmal editiert, zuletzt von WinterUnit16246 (17. November 2016 um 12:18)


  • Nein, ich meine, dass es diese Option seit 3.13 NICHT mehr gibt...

    Von wo hast Du diese Information, dass man seit dem Kernel 3.13, den Kernel nicht mehr mit der Option "CONFIG_IPV6_PRIVACY=y" kompilieren kann? Wo kann man das nachlesen?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!