Diskussion:IPv6

Dieser Artikel war am 30. Juli 2005 der Artikel des Tages.

Auf dieser Seite werden Abschnitte monatlich automatisch archiviert, wenn sie mit {{Erledigt|1=--~~~~}} markiert sind und ihr jüngster signierter Beitrag mehr als 14 Tage zurückliegt.

Auf dieser Seite werden Abschnitte monatlich automatisch archiviert, deren jüngster Beitrag mehr als 365 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 5 Abschnitte.

Archiv

ab 2007

Wie wird ein Archiv angelegt?

IPv4 Einleitungstext gehört verschoben

In "Gründe für neues Internet Protokoll" wird zuviel über IPv4 geschrieben. Ich will explizit etwas über IPv6 lesen, wenn ich den Beitrag auf Wikipedia besuche. Ich unterstelle: Es geht den Meisten Menschen so.

Deswegen erbitte ich dringend um Diskussion um die Frage: Soll ein Großteil der - weitestgehend negativen - Eigenschaften von IPv4 in den Hauptartikel von IPv4 hinein verschoben werden, um darauf dann hier nur noch zu verlinken? In meiner imaginären Idealvorstellung genügt hier ein klarer Hinweis auf gewisse Schwächen von v4, die aber ja eindeutig eher die Eigenschaften von v4 sind, als die von v6. (nicht signierter Beitrag von 2001:4DD7:6472:1A:F149:AEA0:532C:9456 (Diskussion | Beiträge) 22:21, 14. Jul 2016 (CEST))

Ich stimme insoweit zu, dass der Artikel primär darauf eingehen sollte, was IPv6 besser (bzw. anders) macht, und nicht welche Probleme IPv4 hat. Um die Motivation für IPv6 zu verstehen, muss man allerdings die Probleme von IPv4 verstehen. Daher: gerne kürzen und auf IPv4 für mehr Details verweisen (IPv4#Adressknappheit und IPv4#Adressfragmentierung sind ausbaufähig), aber nicht gänzlich streichen. --Matthäus Wander 15:59, 1. Feb. 2020 (CET)

Überschrift: Gründe für neues Internetprotokoll - Umbenennung

Vorschlag: Alt: "Gründe für ein neues Internet-Protokoll" Neu: "Gründe für die neue IP Version" (nicht signierter Beitrag von 2001:4DD7:6472:1A:F149:AEA0:532C:9456 (Diskussion | Beiträge) 22:21, 14. Jul 2016 (CEST))

ds-lite

ds-lite verlinkt auf diesen Artikel, hier kommt es aber nicht vor. Wer kennt sich da aus und kann das ergänzen?--91.20.181.199 20:33, 4. Sep. 2019 (CEST)

Es wird doch erklärt: IPv6#Dual-Stack_Lite_(DS-Lite) (auch schon im Sep. 2019). --Matthäus Wander 15:36, 1. Feb. 2020 (CET)

Grundlegender Fehler: Adresrlänge bet 2 hoch 512, nicht 2 hoch 128

Es tritt ein nahezu katastrophaler Fehler mehrmals (!) in diesem Artikel auf: Die Adresslänge des IPv6-Protokolls beträgt meiner Meinung nach 2 hoch 512 (gleichbedeutend mit 512 Bit)

Ausführlich: Die Adresslänge im IBv6 beträgt: 4 x 16 Bit (4 Hexadezimalzahlen) (multipliziert mit 8 [dargestellt durch die 8 Blöcke, die durch Doppelpunkte voneinander getrennt sind]) Ergebnis 512 Bit

Deshalb ist die Zahlengröße des IPv6 ungefähr 1,34 hoch 154 und nicht wie beschreiben ungefähr 3,40 hoch 38. Die Adresslänge ist also wesentlich länger!

Das müsste meines Erachtens schnellstmöglich korrigiert werden. (In der englischsprachigen Wikipedia ist das auch falsch.)

--Jörg Lietmeyer (Diskussion) 21:26, 20. Sep. 2019 (CEST)

 Info: Eine Hexadezimalzahl hat 4 Bit, nicht 16.

• Sie heißt Hexadezimalzahl, weil 0–9, A–F 16 diskrete Werte annehmen kann; nicht weil sie 16 Bit lang wäre.
• 2⁴=16

Du schreibst: „Die Adresslänge im IBv6 beträgt: 4 x 16 Bit (4 Hexadezimalzahlen)“ – nö, nicht ×16.

VG --PerfektesChaos 21:33, 20. Sep. 2019 (CEST)

Erklärung/'Berechnung' zu 8 (Grundlegender Fehler)

alter Standard (IPv4) 256.256.256.256 2ex8.2ex8.2ex8.2ex8 --> 4 x 8 Bit = 32 Bit gesamt

IPv6: 4 x 16 (x8) = 512 Bit

Kontrolle: 2ex4/2ex4/2ex4/2ex4 : 2ex4/2ex4/2ex4/2ex4 : 2ex4/2ex4/2ex4/2ex4 : 2ex4/2ex4/2ex4/2ex4 --> eine von 8 Notationen = 64 Bit Ergebnis: 4 x 4 Bit 4 x 4 Bit 4 x 4 Bit 4 x 4 Bit = 64 Bit

also:

       2ex4/2ex4/2ex4/2ex4 : 2ex4/2ex4/2ex4/2ex4 : 2ex4/2ex4/2ex4/2ex4 : 2ex4/2ex4/2ex4/2ex4	=	64 Bit
dann das ganze 8fach für die 8 Blöcke

------ ergibt: 512 Bit

Erklärung:

- ex	Exponent
- :	Schreibweise eines Viererblocks in der IPv6-Schreibweise

--Jörg Lietmeyer (Diskussion) 21:40, 20. Sep. 2019 (CEST)

Und nochmal, siehe einen Abschnitt drüber:

• Dein Fehler ist:
  4 x 16 (x8)
• Es gilt: 4 Hexadezimalziffern (von denen jede 4 Bit; Werte 0-9,A-F) mal 8 Gruppen.
• 4 × 4 × 8 = 128.

Eine Hexadezimalzahl hat 4 Bit und kann 16₁₀ unterschiedlche Werte einnehmen.

VG --PerfektesChaos 21:54, 20. Sep. 2019 (CEST)

2 hoch 128 IP-Adressen ist richtig

Entschuldigung an alle vielmals. Es ist richtig, 2-faches errechnen ergab wirklich 2 hoch 128 Adressen.--Jörg Lietmeyer (Diskussion) 00:16, 21. Sep. 2019 (CEST)

Datenschutz und Tracking

Der Abschnitt:

Da es so niemals zu einer Verknappung kommen kann, sind technische Vorrichtungen wie bei IPv4 überflüssig geworden, wodurch ein Internetnutzer teilweise alle paar Stunden eine andere IP-Adresse zugewiesen bekam. Bei IPv6 haben Privatpersonen praktisch eine feste IP-Adresse, die für Webtracking ein Segen ist. Jede IPv6-Adresse kann sehr zuverlässig einem Haushalt oder sogar Mobiltelefon zugeordnet werden. Dadurch kann z. B. eine Suchmaschine oder Onlineshop Personen identifizieren und Informationen über sie verknüpfen, ohne sich Zugriff auf fremde Rechnersysteme zu verschaffen. Dies erforderte ursprünglich so genannte „Tracking Cookies“. Mit genügend Verbreitung von IPv6-Adressen wird dieses Verfahren obsolet.

gehört entweder umgeschrieben, oder mit mehr Quellen unterlegt. Meiner Ansicht nach eignet sich eine IPv6 Adresse alleine nicht für Trackingzwecke, obwohl sie bei Statischer Vergabe (mit aktivierter Privacy Extension) einen Anschluss eindeutig identifiziert. Ich habe in der Vergangenheit mit Personen gesprochen die im Bereich des "Trackings" Arbeiten und die haben mir alle bestätigt, dass die IP Adressen aus den folgenden Gründen nicht für Tracking geeignet sind, nachrangig genutzt werden oder nicht genutzt werden:

• Kann keine Mobilen Geräte wie Notebooks, Smartphones, Tablets, ... eindeutig Identifizieren, also Geräte die die Möglichkeit haben sich von unterschiedlichen Standorten sich mit dem Internet zu verbinden.
• Es gibt einfachere Möglichkeiten, die nicht vom eigenen Load Balancer oder CDN "verschleiert" werden. Viele Webseiten und Webdienste provider nutzen ein CDN und hier geht die IP gerne mal "verloren", dadurch dass entweder die Anfrage durch Server des CDNs/LoadBalancers geleitet (und Überschrieben wird (außer es wird Direct Server return genutzt)) wird oder das CDN den Content mittels Caching server direkt zurück liefert und die Anfrage nie am eigentlichen Server ankommt.
• Ein sehr beliebtes Tracking mittel war "Schriftarten" die der Browser als installiert übermittelt. Prüfen kann man dies z.B. via https://amiunique.org/fp (nicht signierter Beitrag von Agowa (Diskussion | Beiträge) 00:16, 7. Jun. 2020 (CEST))

--Agowa (Diskussion) 00:22, 7. Jun. 2020 (CEST)

Einzelnachweis 52. Link ist ungültig ich denke folgende Adresse verweist auf den Artikel: https://www.heise.de/ct/artikel/IPv6-Privacy-Extensions-einschalten-1204783.html (nicht signierter Beitrag von 217.194.64.102 (Diskussion) 11:54, 1. Dez. 2020 (CET))

Den Satz "(RFC 4193 gibt jedoch keine konkrete Implementierung der Zuweisung von global eindeutigen Site-IDs an)"
halte ich für unsinnig:
Grundsätzlich wird die site ID vom assignee vergeben, niemals berechnet.
Warum?
RFC6177, RFC3177, RFC3587 definieren den letzten hex -Bolock des Netzwerkanteils als site oder Subnet ID. Damit ist klar, dass der Teil, der in diesen RFCs public, network number oder Global Routing Prefix genannt wird, keinesfalls in den scope von RFC4193 mit der Erzeugung einer eindeutigen pseudo-random Global ID fallen darf.
In der ursprünglichen IPv6 spec (RFC 3513) war es klar, dass nur /48 Adressen zugewiesen werden (was dann aufgeweicht wurde). Damit versteht sich von selbst, dass die Festlegung einer site oder Subnet ID im Netzwerkanteil, also dem Teil zwischen 48 und 64 (4 nibbles zu 4 bit also 16 bit oder 2 Byte), niemals jemand anderes als der "Inhaber" vornehmen kann und soll.
Deshalb ist der Satz in sich unsinnig. RFC 4193 darf da gar keine Festlegung treffen.
(nicht signierter Beitrag von 2A01:C23:6D39:DBFF:60E4:DB07:9717:F69F (Diskussion) 14:11, 27. Jun. 2022 (CEST))