Diskussion:IPv6/Archiv/1

message: Diese Kandidatur läuft vom 22. Februar bis 14. März 2007
Ich habe schon unter Portal Diskussion:Informatik#IPv6 noch exzellent? vergeblich versucht, jemanden kompetenten zu finden der den Artikel überarbeiten würde.  Wenn ich zum Beispiel sehe dass im englischen Wikipedia-Artikel Jumbograms als Vorteil angesprochen werden (welche eines der Probleme von IPV4 beseitigen) und im deutschen Artikel nichts dazu steht, dann ist das meiner Ansicht nach nicht ein nach heutigen Kriterien exzellenter Artikel. Ein Review bringt meiner Ansicht nach ohne kompetenten Autor nichts - Kritikpunkte finde ich selber genug wenn ich mir die Diskussionsseite und den Artikel in der englischsprachigen wikipedia ansehe - mir fehlt nur die Fachkompetenz um den Artikel grundlegend zu überarbeiten.  Adrian Bunk 18:02, 22. Feb. 2007 (CET)
thread_title:  Wiederwahl-Diskussion 

message: "Im Rahmen des Mobile IPv6 Technology Preview-Programms sind entsprechende Erweiterungen verfügbar; man kann mit einer „serienmäßigen“ Unterstützung mit einem der nächsten Service Packs rechnen "
:Wie steht es denn mit der Unterstützung durch das XP SP3, hat sich da was verändert?--EaPoe 17:58, 18. Okt. 2008 (CEST)
thread_title:  Windows XP SP3 

message: Soweit ich weiss, soll IP6 durch zusaetzliche Header auch sicherer sein als IPv4 (wobei ich jetzt evtl. neue  Sicherheitsluecken von IPv6 nicht beruecksichtige). Jedoch wird das im Artikel nicht erwaehnt.  Es wird nur erwaehnt, dass IPSec nun "serienmaessig" an Bord ist.  Ich faende es gut, wenn der Artikel um einen entsprechenden Punkt ergaenzt wird oder gibt es einen bestimmten Grund weshalb dies nicht angesprochen wird? --Grb 11:52, 4. Nov. 2008 (CEST)
replies: text: Was versteht du unter sicherer? Weder IPv4 noch IPv6 umfassen irgendwelche großen Verfahren zur Herstellung von Integrität oder gar Authentizität. IPv6 wälzt sogar die Übertragungssicherheit etwas mehr an die darunterliegen Schichten ab, weil die Berechnung der Prüfsumme wegfällt (bei IPv4 wurde sie von den meisten Router einfach ignoriert). -- Merlissimo 12:24, 4. Nov. 2008 (CET)
replies: text:  Was ich meine ist, dass klargestellt werden sollte, dass es ein Designziel von IPv6 ist, Sicherheitsmechanismen auf IP-Ebene mit Hilfe von IPSec zu implementieren, da im Gegensatz zu IPv4 der Einsatz von IPSec nicht optional (da im Zuge von IPv6 entwickelt) ist und IPSec Integrität und Authentizitaet von IP-Paketen gewaehrleistet.  Ich will aber nicht behaupten, dass IPv6 deswegen sicherer ist, das war vielleicht etwas missverstaendlich.  --Grb 14:21, 4. Nov. 2008 (CEST)
replies: text:  Der Unterschied zwischen IPv4 und IPv6 in bezug auf IPsec ist, dass RFC 4294 einer IPv6-Implementation vorschreibt, auch IPsec zu können; für IPv4-Knoten gib es das nicht. Das ist dann aber auch schon alles. --ben g 15:25, 4. Nov. 2008 (CET)
replies: text:  Ich weiss, ich finde nur das sollte auch so erwaehnt werden, da dies aus dem Aritkel nicht hervorgeht.  Ich habe diese Info von http://www.ipv6.com/articles/security/IPsec.htm beziehen muessen.  Aber das ist ja nur ein Vorschlag. --Grb 16:23, 4. Nov. 2008 (CEST)
replies: text:  Dann schreibs rein. (BTW, wie traurig ist es denn, dass die IPv6-Anbindung von ipv6.com nicht funkioniert?) --ben g 16:44, 4. Nov. 2008 (CET)
thread_title:  Sicherheit 

message: Mir fiel gerade diese Änderung der IP auf, die für mich als IPv6-Anfänger kaum zu belegen ist. Kann das jemand mit Quellen bestätigen oder widerlegen? --Uncle Pain 02:37, 13. Feb. 2009 (CET)
replies: text: Der Edit ist korrekt, vgl hierzu Cisco, diese Beschreibung oder als Primärquelle RFC 2460, Abschnitt 3 ("Length of the IPv6 payload, i.e., the rest of the packet following this IPv6 header, in octets"). Damit ergibt sich eine maximale Länge des gesamten IPv6-Pakets von 40 Byte (Header) plus 65.535 Byte (Payload). -- Sigkill 05:48, 13. Feb. 2009 (CET)
thread_title:  IP-Edit legitim? 

message: Ich hatte neulich den Abschnitt über Paketfilter überarbeitet. Einen Paketfilter muss man nicht(!) erheblich anpassen, es sei denn andere IP-Adressen eintragen ist eine erhebliche Anpassung. Außerdem durfte ICMP noch nie pauschal gefiltert werden, wenn man funktionierendes Internet haben wollte, z.B. blockiert man erfolgreich die Kommunikation zu Leuten, die PPPoE machen (in der Regel ADSL-Anschlüsse), wenn man ICMP filtert auf den Servern oder den Firewalls vor den Servern (Stichwort PMTUD). Sicherheitstechnisch ist es zudem mindestens fraglich, eher unsinnig sowas zu tun.
D.h. wenn es eine erhebliche Änderung im Paketfilter zu machen gibt, dann nur in Paketfiltern, die vollkommen falsch konfiguriert sind - diese aber als Referenz zu nehmen, halte ich nicht für sinnvoll. Der Abschnitt sollte daher nur empfehlen speziell darauf hinzuweisen, dass ICMPv6 essentiell ist für das Funktionieren von IPv6 und daher nur Ausnahmefällen gefiltert werden sollte (übrigens gilt das ebenso für ICMPv4, aber das gehört nicht in diesen Artikel).
In Bezug auf NAT fehlt der Hinweis im NAT-Artikel selbst, dass NAT kein(!) Sicherheits-Feature ist, siehe z.B. das RfC zum Thema NAT, in dem das AUSDRÜCKLICH beschrieben ist. Es gibt genügend NAT-Implementierungen, die Pakete einfach mal an irgendeinen Rechner im LAN zustellen, wenn sie vom Internet herkommen, genau weil es kein Sicherheits-Feature ist, sondern NAT Netze VERBINDEN soll, möglichst gut sogar. 
Wenn man Netze TRENNEN will, dann nimmt man bitte etwas, was dafür konzipiert ist, das nennt sich z.B. Paketfilter. Gerade diese Paketfilter sind es, die auf den üblichen NAT-Boxen die Netztrennung machen, nicht das NAT.
Oliver Schad (nicht signierter Beitrag von 95.128.32.140 (Diskussion | Beiträge) 16:10, 31. Aug. 2009 (CEST)
replies: text: Wer NAT für ein Sicherheitsfeature hält, ist ein Trottel, klar. Ist das die Zielgruppe von Wikipedia? --ben g 03:09, 2. Sep. 2009 (CEST)
replies: text: Teilweise ja - und sehr viele denken das NAT per se Sicherheit bringt - viele kennen nichtmal den Unterschied zwischen routen und natten. -- Mifritscher 19:03, 29. Sep. 2009 (CEST)
replies: text:  Ich halte es dennoch für Overkill, Leuten in einem IPv6-Artikel zu erklären, dass sie IPv4 schon nicht verstanden haben. Der Artikel soll eben eine enzyklopädische Abhandlung des Themas sein und nicht ein Handbuch für weniger begabte Administratoren. --ben g 19:32, 29. Sep. 2009 (CEST)

text: Mein Punkt war, warum man denn bitte einen Paketfilter erheblich umbauen muss, wenn er IPv6 machen soll? Ich schreibe dafür jede Regel einmal ab und ersetze anschließend IPv4-Adressen durch IPv6-Adressen. Ist das eine erhebliche Anpassung? mfg Oli (nicht signierter Beitrag von 212.25.27.74 (Diskussion | Beiträge) 23:07, 17. Okt. 2009 (CEST)
replies: text:  Das ist eine etwas naive Sicht auf Paketfilterregeln. Selbst wenn man nicht der ignorante "ICMP ist böse!11!!"-Typ ist, hat sich ICMP von v4 auf v6 auch in etwas subtileren Formen geändert -- man beachte z.B. den semantischen Unterschied zwischen "Host unreachable" und "Address unreachable". --ben g 03:39, 18. Okt. 2009 (CEST)
replies: text:  Kannst du bitte konkretisieren, wo denn die erheblichen Umbauten in Paketfiltern jetzt notwendig werden? Die meisten Paketfilter filtern zustandsbasiert - dort wird ICMP automatisch erschlagen. mfg, Oli (nicht signierter Beitrag von 212.25.27.74 (Diskussion | Beiträge) 18:05, 20. Okt. 2009 (CEST)
replies: text:  Nicht wenige Setups werden mit Fast-1-zu-1-Kopien von Paketfilterregeln auskommen, sicher. Darum geht es hier meiner Ansicht nach aber gar nicht. Worum es mir geht, ist, ob man im Artikel noch Leute darüber belehren sollte, dass NAT häufig falsch verstanden wird. (Eine Heise-Foren-Postingsvermeisungsklausel sozusagen.) Ich finde, das Thema ist durch den Verweis auf RFC 4864 ausreichend und neutral abgehandelt. Dass die Formulierung bezüglich der Änderung der Paketfilter zurzeit zu stark gewählt ist, ist sicher wahr. Das werde ich gleich mal umbauen. --ben g 01:33, 21. Okt. 2009 (CEST)
replies: text:  Cool. :-) mfg, Oli 
OK, man soll den Leuten nicht zu viel Angst vor IPv6 machen, und es gab ja auch schon Stimmen die sagten, dass sich der Artikel zu sehr am Vorgängerprotokoll orientiert. Ich denke jedoch, dass das nicht zu verhindern und der Verständlichkeit nur zuträglich ist. Später wird bestimmt viel von den IPv4-Bezügen herausgestrichen werden können.
Zu den Paketfiltern gebe ich zu bedenken, dass die Filterung von ICMPv6 stark abweicht: Protokoll 58 statt 1, andere Typen- und Code-Ordnung, andere "Dienste", z.B. NDP - möchte man wirklich jedem Rechner im lokalen Netz erlauben sich als Router aufzuspielen? - ein neues Problem, das durch die Autokonfiguration entsteht und auch mit Filtern zu tun hat. Verhält es sich mit der Fragmentierung wirklich bei IPv6 genauso wie bei IPv4? Meistens fragmentieren doch die Router bei IPv4 derzeit, was erlaubt ist, so kann man auf PMTUD jenseits des heimischen PPPoE verzichten, nur wird das mit IPv6 nicht mehr möglich sein.
Geht man von dem SOHO-Router Szenario weg, so wird NAT oft verwendet, um auf Adressbereiche zu übersetzen, die in Filtern an einem anderen Ort erlaubt sind, das wird sich mit Ende-zu-Ende wohl ändern. Auch ist es mindestens legal anzunehmen, dass Adressbereiche, die nicht öffentlich geroutet werden dürfen weniger streng zu filtern sind, ich will da niemandem etwas vorschreiben, dies ist weit verbreitete Praxis, ein Administrator der das macht ist nicht etwa unfähig, "normal" gibt es nicht im Internet, nur muss man dann bei IPv6 etwas anders machen, das betrifft sehr viele Leute.
Mit den öffentlichen Adressen überall ergeben sich auch neue Möglichkeiten, so könnte man einzelne PCs in einer Firma zu einzelnen anderen PCs in einer anderen Firma freischalten, eigentlich ein Haupt-Pluspunkt von Ende-zu-Ende. Wir haben uns schon sehr an die Kommunikation "NAT-PC greift auf Server zu" gewöhnt, sicher kann man ähnliche Filter erzeugen wie für IPv4, muss man aber nicht, das kam in der bisherigen Formulierung sicher zu kurz.
Ich persönlich hatte auf Juniper ein Problem mit Filtern, da diese gar nicht auf das nach Fragmentierung reassemblierte Paket angewandt wurden, sondern auf jedes einzelne Paket, und das hatte in seinem Next-Header eben nur "fragment-extension-header" stehen. Gruß -- Rischmueller 18:35, 23. Okt. 2009 (CEST)

text: Naja, Du hast tatsächlich eine Wortmeldung des Kollegen Rischmueller sinnentstellend "verhackstückt" (wahrscheinlich unabsichtlich?). Man kann es hier sehen: . Was hätte man denn da tun sollen? Hätte man das Gemisch aus deinem und Rischmuellers Diskussionsbeitrag so kaputt wie es ist stehen lassen sollen? Mit dem gleichen Recht wie Du könnte dann Rischmueller sagen: "Ich schreib hier was in eine Diskussion, irgendeiner pfuscht darin herum, und jetzt steht etwas ganz anderes da als ich sagen wollte. Skandal!" --Echoray 13:15, 30. Okt. 2009 (CET)
replies: text: Hallo Oli, ich habe Deine Anmerkungen in der Historie jetzt gelesen, kenne mich auch nicht so mit Etiketten bei Wikipedia aus, zur Sache: Es scheint hier Konsens zu sein, dass bei Filtern ungefähr ein Szenario betrachtet wird, wie es in Heimanwendungen in Bezug auf das Internet vorkommt und da kann man das so stehen lassen. Man kann mit IP natürlich viel mehr machen, nicht nur Internet. Ich bin mir auch nicht sicher, ob sich die Lösung mit den zustandsbasierten Filtern für IPv6 durchsetzt. Ich wollte nur anregen, dass die größten potentiellen Veränderungen in diesem Abschnitt genannt werden und das sind: Alle Filter unabhängig von IPv4 neu, mehr öffentliche Adressen im Umlauf, weniger oder kein NAT, anderes, wichtigeres ICMPv6 (NDP, PMTUD). Zugegeben, die Filter müssen nicht völlig anders aussehen, wie das meine ursprüngliche Formulierung nahelegte, aber sollen wir ICMPv6 hier nicht noch mal nennen?  Gruß -- Rischmueller 18:52, 30. Okt. 2009 (CET)
thread_title:  Abschnitt NAT/Paketfilter 

message: "Der Gebrauch von ICMPv6 (Protokolltyp 58) beschränkt sich bei IPv6 nicht auf den Erreichbarkeitstest mittels Echo-Request und Echo-Reply (z. B. mit ping), sondern stellt unverzichtbare Funktionen zur Verfügung. Das Verbieten aller ICMPv6-Pakete in einem IPv6-Netzwerk durch Filter ist daher im Normalfall nicht durchführbar."
Dies impliziert für mich durch den Wortlaut dass a) sich der Einsatz bei IPv4 auf Pings beschränken würde, b) ICMP bei IPv4 keine unverzichtbaren Funktionen zur Verfügung stellt (PMTUD, Fragmentation required) und c) man bei IPv4 ICMP komplett verbieten könnte. Bzw. man kann es zwar, dies wird aber gemeinhin als "criminally braindead" bezeichnet :) (nicht signierter Beitrag von 78.42.204.165 (Diskussion | Beiträge) 15:14, 11. Nov. 2009 (CET)
replies: text: Du würdest staunen, wo der Kompetenzdurchschnitt bei Netzwerkadmins liegt... Die Formulierung in Bezug auf IPv4 habe ich angepasst. --ben g 18:08, 11. Nov. 2009 (CET)
thread_title:  Abschnitt ICMP 

message: Dieses im Prüfungsstil geschriebene Kapitel riecht irgendwie nach Urheberrechtsverletzung. Ich könnte schwören, das Beispiel ist aus Unterlagen für irgendwelche Microsoft-Zertifikatslehrgänge entnommen. --Echoray 13:58, 23. Jan. 2010 (CET)
replies: text: Und zudem augenkrebserregendverbesserungsfähig formatiert, ein grammatikalischer Frevel und der bisher erste und einzige Beitrag des Nutzers. Traut sich jemand dran, den Abschnitt zu korrigieren? --Sigkill 14:48, 23. Jan. 2010 (CET)

text: Hinfort damit. --ben g 15:36, 23. Jan. 2010 (CET)
thread_title:  Kapitel Subnetting 

message: Im Artikel wird imho nur angedeutet (in Adressaufbau von IPv6) wie die Vergabe der Adressen funktioniert. Dort steht, dass minimal ein /64 zugewiesen wird. Das bezieht sich doch auf einen Rechner soweit ich das weiß. Wieso bekommt bei IPv6 plötzlich ein Rechner 2^64 Adressen? Hat das nur den Grund der Autokonfiguration? Hat man damit vielleicht auch an virtualisierung gedacht? Sowas in den Artikel zu schrieben wäre imho schon sinnvoll.
Wie sieht es aus mit einem /56 - sofern ich Rechnen kann sind das ca. 256 Netze die einem dann bereitstehen. Dadurch das es kein NAT o.ä. mehr geben soll, heißt das doch, der Provider kann einem genau vorschreiben wieviele Rechner man am Anschluß betreiben darf. Z.b. wäre es vorstellbar bei Einwahl über UMTS nur ein /64 zu bekommen und dann keine Chance mehr zu haben das UMTS im Netzwerk zu verteilen (außer eben über sowas wie NAT).
Ist das soweit richtig oder sehe ich da was grob falsch? --empi 16:18, 28. Mär. 2010 (CEST)
replies: text: Grob falsch ;-( Das /64 Netz bezieht sich nämlich nicht auf einen Rechner. Ich bekomme vom Provider mein /64 Präfix mitgeteilt und darf dann die darin enthaltenen 18 Fantastilliarden Adressen nach meiner Schnauze in meinem Netzwerk auf die Geräte verteilen. Dabei ist es dann auch egal, ob diese Geräte physisch vorhanden sind oder virtualisiert sind. --Echoray 17:47, 28. Mär. 2010 (CEST)
replies: text:  Danke für deine Antwort, Echoray. Aber wieso ist es dann vorgesehen dass man pro "Site" einen /48 bzw. /56 Präfix bekommt?  Das /64 dürfte doch dann für eine "site" beliebiger größe reichen und würde sich auch prinzipiell noch weiter aufsplitten lassen. --empi 18:46, 28. Mär. 2010 (CEST)
replies: text:  /64 ist die minimale Größe, die für die Autokonfiguration zwingend vonnöten ist, das reicht genau für einen Link. Eine Site hat in der Regel mehr als einen Link, höchstens Privatleute (und da bei weitem nicht alle) kämen mit einem einzelnen /64 aus. --ben g 20:11, 28. Mär. 2010 (CEST)
replies: text:  kannst du site und link vielleicht noch etwas genauer fassen? danke! --empi 21:03, 28. Mär. 2010 (CEST)
replies: text:  Der "Link" ist in diesem Zusammenhang derjenige, auf den sich die Bezeichnung "Link layer" bezieht. Es geht um ein einzelnes Netzwerksegment, auf dem nicht geroutet wird. Jedes dieser Segmente hat natürlich eigenen Adressraum, und für funktionierende Autokonfiguration muss der mindestens 64 Bit breit sein. --ben g 21:14, 28. Mär. 2010 (CEST)
thread_title:  Wie funktioniert die Adressvergabe? 

message: Hallo, gibt es keine Probleme mit der Privatsphäre, falls jedes Gerät direkt durch seine Adresse angesprochen wird, das bisher durch veränderte Adressen (bspw. hinter NAT) vor eindeutiger Identifizierung geschützt war ? (nicht signierter Beitrag von 88.217.30.230 (Diskussion | Beiträge) 19:55, 7. Mai 2010 (CEST)
replies: text: Lies den Artikel. --ben g 14:37, 8. Mai 2010 (CEST)
thread_title:  ipv6 und Privatsphäre 

message: http://tools.ietf.org/html/rfc4291#section-2.5.2 ist meiner Meinung nach eindeutig, BenG. RFC 2462 gilt jedoch nur für Autokonfiguration, also im Groben: Ethernet. Schon bei PPP sehen die Hersteller das mit den link-locals leider sehr unterschiedlich. Trotzdem ist die jetzige Formulierung wohl ausreichend, wir sollten in diesem unwichtigen Punkt nicht ausschweifen und RFCs zitieren. Gruß, -- Rischmueller 22:59, 11. Jan. 2011 (CET)
replies: text: Deswegen habe ich meine Änderung ja auch eineinhalb Stunden bevor du diesen Beitrag geschrieben hast rückgängig gemacht. --ben g 00:37, 12. Jan. 2011 (CET)
replies: text:  Hab ich dann auch gesehen, vielen Dank, -- Rischmueller 10:41, 12. Jan. 2011 (CET)
thread_title:  ::/128 

message: Neben der Tatsache, daß im Artikel noch kein Abschnitt zur Geschichte existiert und IPv6 vor kurzem zum 15. Geburtstag beglückwünscht wurde wäre es hier doch bestimmt auch zumindest nennenswert, daß am 8. Juni 2011 der erste(?) Welt-IPv6-Tag veranstaltet werden soll.
--Konrad – 12:25, 13. Jan. 2011 (CET)
thread_title:  Geschichte: Welt-IPv6-Tag 

message: Den eigentlichen Skandal um IPv6 haben leider 99% der Journalisten bisher immer noch nicht verstanden.
Das neue Protokoll wird die Vorratsdatenspeicherung überflüssig machen. Bereits jetzt wird klar, dass praktisch alle Provider in Zukunft auf das bisherige "Durchroutieren" der IPs bei Endkunden verzichten werden. Das heißt im Klartext -> in Zukunft wird jedes Endgerät eine eindeutige IP bekommen. Dies wird eine einfachste Identifizierung jedes Einzelusers ermöglichen.
Die im Protokoll implementierten Privacy-Optionen kommen schon jetzt in den Planungen praktisch nicht mehr vor.
Wer noch immer nicht versteht was das bedeutet sollte z.B. mal beim CCC nachfragen.
Das anonymisierbare Internet so wie es aktuell kennen ist demnächst nicht mehr viel mehr als ein nostalgischer Gedanke. Lebe wohl Datenschutz, Meinungsfreiheit und kritische Gegenöffentlichkeit.
In letzter Zeit erschienen hierzu mehrere Beiträge in Technoblogs. Da diese wahrscheinlich nicht [W:Q] entsprechen wäre es gut wenn jmd Fachliteratur hätte.--146.82.18.170 12:51, 28. Jan. 2011 (CET)
replies: text: Mir kommt es so vor, als sei der Privatsphäre-Aspekt in der öffentlichen Diskussion das einzige was an IPv6 interessiert. Der Artikel versucht hier mit Fakten aufzuklären, konkret: dynamisches Präfix und Privacy Extensions (bei modernem Windows von Hause aus eingeschaltet) lösen das Problem für Privatkunden. Über die zukünftige Vergabepraxis von Providern ist nicht viel bekannt. Die Deutsche Telekom scheint relativ stabile Präfixe vergeben zu wollen, die aber nach längerem (eine Nacht, ein Tag?) ausschalten des DSL-Routers gewechselt werden: http://www.heise.de/newsticker/meldung/Deutsche-Telekom-konkretisiert-IPv6-Plaene-1102458.html Ich gehe davon aus, dass sich zunächst andere Provider an der Telekom-Praxis orientieren, das steht aber nicht auf Dauer in Stein gemeißelt. Ich habe einige weitere Sicherheitsbetrachtungen in diesem Blog zusammengetragen: http://blog.1und1.de/2010/05/07/ipv6-totale-ueberwachung/  Viele Grüße, -- Rischmueller 14:03, 1. Feb. 2011 (CET)

text: Noch mal ich, die Privacy Extensions sind eine reine Sache des Betriebssystems und müssen nicht vom Provider oder ähnlichen "unterstützt" werden. Welche Planungen meinst Du, in denen die Privacy Extensions keine Rolle spielen? Ich sehe sie überwiegend genutzt. Viele Grüße, -- Rischmueller 14:12, 1. Feb. 2011 (CET)
thread_title:  Datenschutz- feste IPs für jeden Endanwender 

message: Wieso wurden sie abgeschafft? Was genau waren die Probleme / offiziellen Gründe? --RokerHRO 14:38, 27. Mär. 2011 (CEST)
replies: text: Alle Gründe sind im verlinken RFC nachzulesen. Den meines Erachtens wesentlichen habe ich im Artikel eingefügt. --ben g 17:49, 27. Mär. 2011 (CEST)
thread_title:  Site-Local-Adressen 

message: ich war nach paar tagen eher zufällig wieder hier und habe quasi mit frischem blick das umgebesserte intro gelesen und dann den ersten satz aufgeteilt, um einen neuen kopfsatz zu dichten, den ben G dann wieder revertierte. was ist so falsch daran gewesen?:
*Das Internet Protocol Version 6 (IPv6) (früher auch Internet Protocol next Generation, IPnG) ist ein 1998 von der Internet Engineering Task Force (IETF) standardisiertes Verfahren, nach dem Computer und Vermittlungsstellen miteinander Daten austauschen. Es soll den aktuellen Standard IPv4 ablösen.
revert-kommentar von ben G zu obigem: Das ist verwirrender als vorher. Zuerst wolkig "Verfahren", dann "Netzwerkprotokoll". Wer sich nicht auskennt, sollte eine vernünftige Definition bekommen und nicht Fäden zusammensuchen müssen.
darf ich Euch IPv6-experten dann nochmal meinen außenblick auf den ist-zustand kommunzieren?
*ERSTER SATZ: Das Internet Protocol Version 6 (IPv6) (früher auch Internet Protocol next Generation, IPnG) ist ein von der Internet Engineering Task Force (IETF) seit 1998 standardisiertes Netzwerkprotokoll für paketvermittelnde Datennetze, welches die Adressierung der beteiligten Netzwerkelemente (Rechner oder Router) und den Vorgang der Paketweiterleitung zwischen Teilnetzen (Routing) regelt.
ein un-satz. nicht nur wegen der 5 (!) klammern. macht bitte zwei draus, hebt paar klammern für fußnoten oder für später auf. im nächsten absatz ist viel platz dafür. die stelle mit dem komma bietet sich zur satztrennung an. ben G - sprich im ersten satz Deine tante an, von der wir schon früher mal sprachen ,-) sowas hilft auch mir immer wieder, der gefahr eines tunnelblicks zu begegnen. siehe oben: wie man artikeln einen für jeden barrierefrei nutzbaren einstieg bereitet.
*ZWEITER SATZ: Es stellt als Protokoll der Vermittlungsschicht (Schicht 3 des OSI-Modells) im Rahmen der Internetprotokollfamilie eine über Teilnetze hinweg gültige Adressierung her.
völlig unvermittelt einsetzendes wort "Schicht". der satz setzt das vorwissen voraus, dass die kommunikation meines routers mit meinem PC mehrschichtig aufgebaut ist. bitte zumindest in einem halbsatz auf diese schichten hinleiten!
ps. mir wäre das hier alles egal, aber zurzeit zieht der begriff nun mal viele leute an, und ich will sie nicht gern im regen stehen lassen. grüße! Maximilian 21:35, 20. Jun. 2011 (CEST)
replies: text: Ich möchte mal eben meine Sicht der Dinge darlegen: Artikel für Laien verständlicher machen, ist normalerweise immer eine gute Sache. Die Grenze ist für mich aber da erreicht, wo der Artikel dadurch für Fachleute unbrauchbar wird. Die Verwendung des Wortes "Vermittlungsstelle" anstatt des Fachworts "Router" ist für mich so ein Fall. Vermittlungsstelle weckt bei Fachleuten völlig falsche Assoziationen an irgendwelche Bunker der Deutschen Telekom. Und ich finde, dem Laien ist auch nicht geholfen, wenn nur die Wikipedia den Router "Vermittlungsstelle" nennt, aber niemand sonst da draußen. Man sollte den Laien durchaus die Fachbegriffe zumuten, und sie zur Erklärung fleißig verlinken. Wer bei "Router" nicht Bescheid weiß, muss eben klicken, um sich erleuchten zu lassen. Ebenso sollte einfach ein Link aufs Schichtenmodell gesetzt werden, anstatt im IPv6-Artikel, der völlig zurecht wegen seiner enormen Länge kritisiert wird, noch einen und noch einen erklärenden Nebensatz einzuführen. Damit vertrete ich wohl genau die entgegengesetzte Meinung als Maximilian Schönherr, und unsere Ansichten werden sich wohl nicht vereinen lassen. Letztlich ist mir egal, wie die Einleitung des Artikels aussieht. Ich wollte es nur mal gesagt haben. Macht was Ihr wollt. --Echoray 12:40, 21. Jun. 2011 (CEST)

text: Ich finde ja die Einleitungen der allermeisten Artikel auf dieser Seite (auch die, die mit meinen Fachgebieten gar nichts zu tun haben) gar nicht unverständlich. Vielleicht bin ich nur außergewöhnlich allgemeingebildet, aber es erscheint mir doch wahrscheinlicher, dass da einige Leute "ich will mich beim Lesen nicht anstrengen" mit "das ist unverständlich" verwechseln. Meiner Ansicht nach vergreifst du dich konsequent in der Textsorte. Wir schreiben hier eine Enzyklopädie, da sind solide Begriffsdefinitionen unerlässlich, auch wenn man sie vielleicht zweifach lesen muss, weil das Thema etwas komplexer ist. Die Komplexität zu verstecken, worauf du effektiv hinauswillst, hilft niemandem wirklich. Da könnte man auch einen Zeitungsartikel lesen. --ben g 04:24, 22. Jun. 2011 (CEST)
thread_title:  Zurück auf Los 

message: Würde man den ersten 0-Block in Regel 2 nicht komplett nach Regel 3 "entfernen"? Zudem finde ich "bis auf die letzte" verwirrend, wenn man einen Block 0012 (Bsp.) hat. Denn den würde man dann nach der Regel auf 012 kürzen, obwohl er auf 12 gekürzt wird. -- Madman-Maniac 11:12, 16. Feb. 2009 (CET)
replies: text: Entweder den ersten, oder den zweiten 0-Block. RFC4291 gibt im Abschnitt 2.2.2 keine Preferenz vor. Allerdings geht es in Regel 2 darum, die Entfernung der führenden Null(en) sichtbar darzustellen. -- Dennis 15:34, 26. Dez. 2009 (CET)
thread_title:  Adressnotation 

message: Als eher technischer Laie, der ich diesen Artikel lese, hätten mich interessiert, was sich für den Endbenutzer ändert. Muss man neue Hardware anschaffen, neue Netzwerkkarten einbauen, neue Betriebssysteme installieren?
Ich war leider nicht einmal ansatzweise in der Lage diesem mit Fachwörtern gespicktem Artikel zu folgen.
Was ist IPv6 und in welcher Relation steht es zum normalen Benutzer? Einer der unverständlichsten Artikel, die ich in Wikipedia bisher gelesen habe, daher hinterlasse ich auch diesen Kommentar.
-- 93.104.102.83 13:00, 2. Feb. 2010 (CET)
replies: text: Ergibt sich aus dem Ersten Satz des Artikels! Bitte den dort verlinkten deiner Frage entsprechenden Links zu den deiner Frage betrefenden Lammata. Dort würdest du herausfinden, das sich an der Otto-Normal-Verbraucher-Hardware recht wenig tut; eventuell aber Software/Firmware Updates notwendig sind. -- ucc 14:05, 2. Feb. 2010 (CET)

text: Wikipedia ist kein Ratgeber. Abgesehen davon werden alle Fragen im Artikel beantwortet. Sich dumm stellen und nicht woanders in Wikipedia das notwendige Grundlagenwissen aneignen wollen zählt nicht. --ben g 17:12, 2. Feb. 2010 (CET)

text: Ich erlebe diese Probleme häufiger bei Erklärungen über IPv6, bildete mir jedoch ein, die meisten in diesen Artikel eingebracht zu haben. Habe noch ein paar Änderungen vorgenommen, etwas konkretere Verbesserungsvorschläge fände ich gut. Was ist ein normaler Nutzer, weiß der, was eine IP-Adresse ist? Irgendwann ist vielleicht sein OS IPv6-fähig und er benutzt es, ohne etwas darüber zu wissen, genauso wenig wie über ARP, Ethernet, PPP, ATM, HTTP, SMTP, DNS, SIP, etc.. Dem Nutzer, der jetzt schon mit IPv4-Adressen umgeht, erscheint mir der Artikel hilfreich.  Gruß, -- Rischmueller 14:12, 27. Feb. 2010 (CET)
replies: text: Dir ist bewusst, das es schon einige OS gibt, die voll IPv6-fähig sind und das die Nutzer diese massenweise verwenden, ohne das zu wissen? Hehe. Nur mal so ;-) -- ucc 15:12, 27. Feb. 2010 (CET)
thread_title:  Artikel für technische Laien absolut unverständlich 

message: Aus Abschnitt "Tunnelmechanismen":
:Befindet sich ein Rechner in einem privaten IPv4-Adressbereich und findet beim Verbinden mit dem Internet NAT statt, so können Mechanismen wie AYIYA oder Microsofts recht automatisch funktionierendes Teredo helfen. Erlaubt ein Administrator diese Protokolle, die meist auf UDP basieren, kann schnell die Netzwerksicherheit in Gefahr geraten.
Letzteres bedarf IMHO einer genauer Erklärung. --Hamburger 18:47, 16. Nov. 2011 (CET)
replies: text: Besser? --ben g 17:27, 17. Nov. 2011 (CET)
replies: text: Deutlich besser. Danke. --Hamburger 20:32, 18. Nov. 2011 (CET)
thread_title:  Tunneling: unverständliche Aussage 

message: Leider ist in dem ganzen Artikel nicht ein einziges Beispiel wie die neue
Adresse nun eigendlich aussieht. Etwa dieses Schema?: 126.000.000.000.000.001
(nicht signierter Beitrag von 213.206.180.130 (Diskussion) 13:47, 18. Nov. 2011 (CET)
replies: text: Unter IPv6#Adressnotation steht alles klar und verständlich. --Fomafix 14:09, 18. Nov. 2011 (CET)
thread_title:  Wie sieht eine IP6-Adresse aus? 

message: "Da die Autokonfiguration ohne nicht allseits unterstützte Protokollerweiterungen keine Informationen über Host-, Domainnamen, DNS, NTP-Server etc. berücksichtigt, kann sie durch den Einsatz eines DHCPv6-Servers ergänzt werden." 
Das sind 3 Verneinungen. Was ist da gemeint? Bitte umformulieren, danke ... --Hamburger 21:14, 4. Dez. 2011 (CET)
thread_title:  Unverständlicher Satz 

message: Warum hat man so viel gewählt? 2128 > 1038 ist so unglaublich viel, damit könnte man jeder Bakterie auf der Erde 10 Millionen Nummern zuweisen (Es gibt weniger als 1031 Bakterienzellen auf der Erde, vgl. William B. Whitman, David C. Coleman, William J. Wiebe: Prokaryotes: The unseen majority. In: Proceedings of the National Academy of Sciences of the United States of America. Band 95, Nr. 12, 1998, S. 6578–6583, Digitalisat). Als Laie verstehe ich das überhaupt nicht. So eine extrem hohe Anzahl macht doch nur die IP länger. Oder wo ist mein Denkfehler? --Ephraim33 20:31, 3. Feb. 2011 (CET)
replies: text: Moin, ich denke man wollte dieses Mal einfach die ANzahl so groß wählen, dass die Zahl auf längere Zeit nicht erreicht wird. Darüber hinaus ist 128 eine Zweierpotenz, genauso wie die 32 von IPv4 eine ist. (32 = 25; 128 = 27) --ThorJH Disk. 20:42, 3. Feb. 2011 (CET)
replies: text: Aber 264 ≈ 1,8 · 1019 ist doch auch schon viel, würde immerhin reichen, um jedem hundersten Sandkorn eine Nummer zu geben („2000 billion billion grains of sand on Earth“). Das würde doch auch schon längere Zeit reichen. --Ephraim33 20:52, 3. Feb. 2011 (CET)
replies: text: Moin, die derzeitigen Vergaberegeln sehen vor, dass jedem Endanwender mindestens ein /64 Subnetz zusteht, damit reduziert sich die Anzahl der verfügbaren Adressen schonmal signifikant. In diese ganzen Überlegungen spielt auch hinein, dass Adressen immer nicht einzeln, sondern in Blöcken vergeben werden (z.B. das /64 oder teilweise auch /56 Netz für jeden Endanwender). Außerdem sind teilweise recht große Bereiche für spezielle Aufgaben reserviert (z.B. fe80::). Mit 2128 ist man einfach auf der sicheren Seite, vor allem da das Internet weiter stark wächst. --ThorJH Disk. 21:07, 3. Feb. 2011 (CET)
replies: text: Das würde aber doch bedeuten das sich der Adressbereich letztendlich "nur" auf 224 oder so erhöht wenn jeder gleich ein gigantisch großes /64 Netz bekommt (was ein vielfaches des heutigen IPv4 Netzes ist) --B.O. 19:50, 14. Dez. 2011 (CET)
thread_title:  Warum 2<sup>128</sup>? 

message: "Richtlinien für neues Internet-Protokoll Anonym surfen trotz IPv6" ipv6council.de
Bitte an IPv6 Artikel Professionisten hier: folgende Formulierung zu IPv6 
http://www.ipv6council.de/documents/leitlinien_ipv6_und_datenschutz.html?L=1
sollten sich zwecks Objektivität auch im Wikipedia Artikel widerspiegeln.---93.104.214.48 07:52, 11. Mai 2012 (CEST)
thread_title:  Leitlinien IPv6 und Datenschutz des Deutschen IPv6-Rates 

message: Ich finde, der Artikel geht zu wenig auf diesen Aspekt der Thematik ein. Dabei dürfte gerade dieser zumindest technische Laien unter den Lesern am meisten interessieren. In der Einleitung steht zwar etwas dazu, aber danach wird es nur noch ein mal am Rande erwähnt. Ein separater Abschnitt (z.B. unter Probleme) wäre mE sinnvoll.--Berita 15:11, 30. Jan. 2012 (CET)
replies: text: Hi, der Abschnitt Probleme >> Adressierung der Netzknoten befasst sich durchaus damit. Wenngleich allgemeinverständlicher sein könnte, wie weitreichend die Konsequenzen sind. Aber WP:Sei mutig und ergänze daran was du für sinnvoll hältst. Am Besten unter Angabe guter Quellen! (siehe Literatur etc) Dann haben wir eine Grundlage zur Disk. --Hamburger 16:44, 30. Jan. 2012 (CET)
replies: text:  Hallo ich habe mal, -abgeleitet auch vom englischen IPv6 Artikel- eine allgemein verständliche Formulierung ergänzt mit zwei Referenzen eingefügt.--Reinraum (Diskussion) 00:30, 11. Mai 2012 (CEST)
replies: text:  Bitte höre auf, deinem POV immer wieder ungebührlich Raum im Artikel zu verschaffen. (Ich erinnere mich noch an dich.) Die brauchbare Referenz an geeigneter Stelle einzufügen, hätte vollkommen gereicht, und ich habe den Artikel entsprechend abgeändert. --ben g (Diskussion) 02:45, 11. Mai 2012 (CEST)
replies: text:  Hallo Ben g, begründe bitte deinen Revert, ein entsprechender Abschnitt Datenschutzbedenken findet sich auch in der englischssprachigen Wikipedia. Der Wunsch auf einen entsprechenden Hinweis ist siehe Artikel Diskussion hier klar vorhanden, Wikipedia soll alle Aspekte widerspiegeln.--93.104.214.48 07:21, 11. Mai 2012 (CEST)
replies: text:  Der Revert ist begründet, und ganz einfach: Das steht alles schon im Artikel. --ben g (Diskussion) 17:37, 11. Mai 2012 (CEST)
replies: text:  Hallo Ben g, es steht eben nicht alles im Artikel, derzeit finden sich Datenschutzbedenken lediglich verschämt im Absatz "Adressaufbau" versteckt, jene sechs vom IPv6-Rat formulierten Richtlinien haben im Artikel jedenfalls mehr Raum verdient. Zitat:(URV: Komplettzitat von http://www.ipv6council.de/documents/leitlinien_ipv6_und_datenschutz.html entfernt. --ben g (Diskussion) 18:45, 12. Mai 2012 (CEST)
replies: text:  Zumal die Datenschutzbedenken sich durch den neuen Adressaufbau ergeben, ist der Absatz zu selbigen da gut aufgehoben, und mehr als ein Absatz muss es auch nicht sein (insbesondere, weil das Fazit "ohnehin alles so wie früher" ist). Wozu die Urheberrechtsverletzung mit dem Vollzitat jetzt gut war, das überlasse ich dir besser selbst. --ben g (Diskussion) 07:36, 12. Mai 2012 (CEST)
replies: text: @Urheberrechtsverletzung.. klar, wir sollten froh sein dass es damals als Moses vom Berg stieg Urheberrechtsverletzungen noch nicht gab, die 10 Gebote wären uns sonst vorenthalten geblieben. Es scheint Ipv6 ist für die Contentindustrie ein richtiges Herzensanliegen anders kann ich mir die Blockartmentalität hier auf der IPv6 Artikelseite in der Du bereits jeden Hauch an Kritik im Keim unterbindest nicht erklären. Nochmals der Hinweis, der englischsprachige IPv6 Artikel leistet sich zum Thema Privatsphäre Bedenken http://en.wikipedia.org/wiki/IPv6#Privacy einen eigenen Absatz, begründe bitte daher deine ablehnende Haltung.--93.104.214.32 10:17, 12. Mai 2012 (CEST)
replies: text:  Aha, ich bin also ein Agent der Contentindustrie. Es wäre ja durchaus positiv, wenn Leute mit meiner persönlichen Einstellung zum Urheberrecht im digitalen Zeitalter tatsächlich Teil der Contentindustrie wären. Wie wäre es aber, wenn du jetzt einmal deine URV entfernst und eine entsprechende Versionslöschung anstrengst, um Schaden vom Projekt abzuwenden, anstatt wilde Unterstellungen um dich zu werfen? --ben g (Diskussion) 10:38, 12. Mai 2012 (CEST)
replies: text:  Das hört sich doch bereits ganz konstruktiv an, eine URV sehe ich aber da ich da ich ja auf die Quelle http://www.ipv6council.de/documents/leitlinien_ipv6_und_datenschutz.html?L=1 verweise und das Zitat im Artikel Diskussionsteil steht nicht. Datenschutzbedenken haben im Abschnitt IPv6 Adressaufbau http://de.wikipedia.org/wiki/IPv6#Adressaufbau_von_IPv6 nichts verloren, ich beantrage daher die Behandlung der Thematik Privatsphäre - wie im englischsprachigen Artikel - http://en.wikipedia.org/wiki/IPv6#Privacy auch aufgrund der immensen Bedeutung dieser Thematik in einem eigenen Absatz.--93.104.214.32 11:49, 12. Mai 2012 (CEST)
replies: text:  Die Bedeutung ist offensichtlich nicht immens, da sich im Endeffekt gegenüber IPv4 nichts ändert. Bei welcher Stelle du irgendeinen Antrag stellen willst, das weißt wohl auch nur du. Dass eine Quellenangabe eine Urheberrechtsverletzung ungeschehen macht, ist übrigens auch offensichtlicher Unsinn -- meinst du, du kannst ein ganzes Buch kopieren, so lange du die Quelle angibst? --ben g (Diskussion) 15:40, 12. Mai 2012 (CEST)
replies: text:  Es handelt sich hierbei http://www.ipv6council.de/documents/leitlinien_ipv6_und_datenschutz.html?L=1 nicht um ein Buch sondern um eine veröffentlichte Leitlinie. Zum Thema "es ändere sich nichts gegenüber IPV4", na dann können wir ja deiner Meinung nach auf IPv6 genauso komplett verzichten. Tatsächlich ändert sich grundlegendes, vor allem an Datenschutz und Privatsphärerisiken.--93.104.214.32 18:20, 12. Mai 2012 (CEST)
replies: text:  OK, da du dich jetzt offenbar komplett von der Realität losgelöst hast, werde ich die Sache selbst in die Hand nehmen und dich außerdem im folgenden ignorieren, bis du etwas Leseverständnis und Realitätssinn zeigst. --ben g (Diskussion) 18:45, 12. Mai 2012 (CEST)
replies: text:  Zu deiner Anmerkung "Verschwinde", ich habe in der Diskussion bewusst einen Edit mittels IP gewählt um zu demonstrieren was geschieht sofern wie bei IPv6 möglich jedes Endgerät mittels eindeutiger IP identifizierbar wäre (derzeit gibt es unter IPv6 kein Versprechen sondern nur ein flehen  nach einer weiteren dem IPv4 folgenden Modell der dynamischen IP Zuteilung. Die gestern von von mir verwendete IP ist heute angeblich als Open Proxy IP identifiziert und gesperrt, dabei handelt es sich lediglich um eine dynamisch zugeteilte IP meines Providers. Hätte ich unter einer Fixen IP editiert so wären unter dieser sämtliche von mir jemals in Wikipedia getätigten Edits einsehbar. Datenschutzbedenken und Risiken sind daher bei Ipv6 einer besonderen Erwähnung wert, derzeit im Artikel - auch wohl aufgrund deiner penetranten Intervention - komplett ausgeklammert.--Reinraum (Diskussion) 09:58, 13. Mai 2012 (CEST)
thread_title:  Wegfall/Einschränkung der Anonymität im Internet 

message: Meines Erachtens steht in dem Abschnitt ziemlicher Unsinn.
>IPv5 existierte nicht< Aha. 
Das Internet Stream Protocol(ST2), eine Erweiterung zu IPv4, hat die Nummer 5 bekommen und damit war die Bezeichnung IPv5 blockiert, als u.a. wegen Adressverknappung eine neue IP Version her musste. ST2 Pakete haben sich selbst im "IP Version Number field" mit der Nummer 5 identifiziert.
* http://www.oreillynet.com/onlamp/blog/2003/06/what_ever_happened_to_ipv5.html
* http://tools.ietf.org/html/rfc1819
* http://en.wikipedia.org/wiki/Internet_Stream_Protocol
Desweiteren ist dort zu lesen, dass ST2 wegen IPv6 aufgegeben wurde, jedoch ist es nur ein Teil der Wahrheit. ST2 war für sich bereits ein Flop, wohl zum Teil auch da vor seiner Zeit war, und hat sich so nie durchgesetzt. Die arbeiten an IPng und die Verbesserungen auf Basis von IPv4, welche in IPV6 mündeten, haben dem Teil dann den letzten Stoß versetzt.
* http://fcw.com/articles/2006/07/31/what-ever-happened-to-ipv5.aspx (nicht signierter Beitrag von Madeddy (Diskussion | Beiträge) 19:38, 5. Jun. 2012 (CEST)
thread_title:  IPv5 

message: Im Artikel wird erwähnt dass sich die Verbreitung von IPv6 verbessert hat, dennoch wird in der Statistik etwas vergessen, was hier auch hervorgehoben werden sollte um den Endnutzer darüber zu informieren.
Die höhere Verbreitung von IPv6 rührt mehr durch die Verbeitung moderner Betriebssysteme her welche das Protokoll automatisch aktivieren als von der aktiven Entscheidung des Nutzers.
Die meisten Nutzer werden weder den Unterschied kennen noch überhaupt irgendwo informiert. Eine höhere Anschlussrate kann also keine verbesserte Akzeptanz wiederspiegeln. Das Konzerne und staatliche Intiutionen IPv6 bevorzugen verwundert nicht, aber die meisten Datenschützer schauen kritischer darauf.
Die Provider stehen daher in der Pflicht die Nutzer darüber zu informieren. Dies sollte explizit erwähnt werden.
-- anmaril (Diskussion) 10:28, 5. Jul. 2012 (CEST)
replies: text: Es hat sich auch kein Endnutzer aktiv für IPv4 entschieden. Die Endnutzer spielen bei der Verbreitung von IPv6 schlicht überhaupt keine Rolle, da sind Entscheidungsträger bei Providern, Netzausrüstern, Diensteanbietern etc. gefragt. --YMS (Diskussion) 13:45, 5. Jul. 2012 (CEST)
thread_title:  Verbreitung 

message: Kann man diesen Teil nicht streichen?
Derzeit sind 74 % aller IPv4-Adressen den nordamerikanischen Internet Registries und einigen US-amerikanischen Institutionen und Unternehmen direkt zugewiesen, während beispielsweise ganz China – mit inzwischen über 250 Millionen Internet-Benutzern (Stand: Juni 2008[58]) – vor Jahren noch nur über etwa so viele IP-Adressen verfügte wie ein Campus der University of California (Dezember 2004).[59]
In den Artikel geht es schließlich um die Verbreitung von IPv6 und nicht von IPv4.
--Tschäfer (Diskussion) 19:37, 9. Jun. 2012 (CEST)
thread_title:  Derzeit sind 74 % aller IPv4-Adressen  ....Kann man diesen Teil nicht streichen? 

message: Zitat:
Aktuell > Link-lokale Adressen Eine mögliche Designschwäche von IPv6 ist, dass die Adressräume für link-lokale Adressen grundsätzlich nicht getrennt sind. Will man link-lokale Adressen also auf Anwendungsebene zur Kommunikation zwischen Rechnern im gleichen Netzwerksegment verwenden, ergibt sich das Problem, dass es für diese nicht ausreichend ist, die IP-Adresse im Ziel-Feld einzutragen, sondern auch ein Zone Index nach RFC 4007 (in den meisten Fällen ein Interface) angegeben werden muss ...
Was hat das bitte mit einer Designschwäche zu tun? Das ist doch absolut klar und wer dagegen verstößt, der hat einfach quatsch programmiert. Wer HTTP, statt HTTPS in Browser eingibt, aber verschlüsselste Seiten erwartet, dessen Problem ist auch nicht die Designschwäche von HTTP, sondern die eigene Unwissenheit. Nur, dass man von einem Netzwerkler erwarten sollte, dass er weiß, wie das geht. Daher habe ich diesen Abschnitt gelöscht. (nicht signierter Beitrag von 188.110.243.174 (Diskussion) 23:29, 19. Jul 2012 (CEST)
replies: text: Naja, zumal RFC 3986 beispielsweise keine Möglichkeit spezifiziert, zone indices anzugeben ("A host identified by an IPv6 literal address is represented inside the square brackets without a preceding version flag. The ABNF provided here is a translation of the text definition of an IPv6 literal address provided in [RFC3513].  This syntax does not support IPv6 scoped addressing zone identifiers."), haben wir ein etwas größeres Problem als dass halt nur irgendwer irgendwo nicht gewusst hat, wie man es richtig macht. Daher Abschnitt wieder rein. --ben g (Diskussion) 00:34, 20. Jul. 2012 (CEST)
thread_title:  mögliche Designschwäche bei link-lokalen Adressen 

message: Der Artikel IPv4 stellt die Headerfelder als Tabelle darf, IPv6 als Grafikdatei.
Dies sollte vereinheitlicht werden.
Die Variante "Tabelle" ist in Sachen Barrierefreiheit besser, während die Grafik eine schönere Darstellung bietet. Vielleicht findet sich eine Mischung aus beiden Lösungen in Form einer besonders gut gestalteten Tabelle? --Hamburger 18:09, 16. Nov. 2011 (CET)
replies: text: Die Grafik enthält keine wesentlichen zusätzlichen Informationen gegenüber der bereits im Fließtext in Tabellenform enthaltene Beschreibung der Kopfdatenfelder. Die durch die geometrische Anordnung der Felder entstehende größere Übersicht dürfte auch in Texttabellenform durch Screenreader ohnehin nicht zu vermitteln sein. Insofern sehe ich kein Problem mit der Barrierefreiheit. --ben g 17:27, 17. Nov. 2011 (CET)
replies: text:  Naja die x/y-Skalierung kommt eben bei der Grafik ergänzend hinzu. Im Übrigen hast du Recht. Stellt sich dennoch weiterhin die Frage, ob das gegenüber dem Artikel über v4 nicht vereinheitlicht werden sollte. Der Vergleichbarkeit wäre damit sicher geholfen. --Hamburger 20:35, 18. Nov. 2011 (CET)

text: die 0 beschreibt die Linie vor dem ersten Bit, wäre somit die Addresse für das erste Bit. Die 32 beschreibt die Linie nach dem 32ten Bit, dem mit der Adresse 31. Sollte es wirklich so verwirrend sein, könnte man es auf der Diskussionsseite der Grafik auf den Commons anmerken. Grüße --ucc 17:06, 31. Jul. 2012 (CEST)
thread_title:  Header 

message: Im Abschnitt "Probleme" unter "Historisch" steht, "Datenschützer waren besorgt, dass [...] Nutzer [...] identifizierbar werden [...]. [...] Da aber die ersten 64 Bit der IPv6-Adresse eines Netzes (z.B. eines Haushaltes) weiterhin erhalten bleiben, muss ein weiterer Schutz durch regelmäßiges Wechseln des Netzteils gewährleistet sein (wie heute bei DSL-Anschlüssen)".
Die Begründung mit den ersten 64 Bit verstehe ich nicht (habe nicht den gesamten Artikel gelesen), da ich eigentlich nur etwas über den Datenschutzaspekt herausfinden wollte (muss man eine ganze Weile für suchen...), das ist aber hoffentlich für das ansatzweise Verständnis der Problematik nicht notwendig. 
Nun heißt es, dass man zur Gewährleistung von weiterem Schutz ein Netzteil regelmäßig wechseln müsse.
Könnte mir bitte jemand erklären welches Netzteil damit gemeint ist?
Die Überschrift "Historisch" suggeriert ja, dass das Problem inzwischen gelöst/nicht mehr vorhanden ist. Stimmt das auch so, oder nur unter gewissen Bedingungen?
Danke schon mal.
lG --134.76.62.65 04:30, 12. Dez. 2012 (CET)
replies: text: Was hier relativ sperrig mit Netzteil bezeichnet wird ist nicht etwas "das" Netzteil (=PSU) vom Gerät/Router, sondern der netzbezogene Teil der IPv6-Adresse, wie unter Adressaufbau beschrieben. Ich weiß nicht ob "Netzteil" wirklich der korrekte Begriff dafür ist. Jedenfalls ist es für Laien und Einsteiger missverständlich. Evtl. umformulieren? --Hamburger (Disk) 11:25, 12. Dez. 2012 (CET)
replies: text: Danke für den Hinweis. Habe es ausgebessert.--Lex parsimoniae (Diskussion) 18:46, 12. Dez. 2012 (CET)
thread_title:  Frage zu Datenschutzbedenken 

message: Muss das wirkich sein? Es ist doch nicht Krautchan hier wo alles mit der Zange eingedeutscht werden muss. --77.12.60.130 16:33, 12. Dez. 2012 (CET)
replies: text: Der Begriff wird aber so verwendet, siehe Protokollstapel. --Lex parsimoniae (Diskussion) 15:45, 17. Dez. 2012 (CET)
thread_title:  Protokollstapel? 

message: Der Sinn von "diese Adressbereiche sind ihnen z. T. aber noch nicht zu dem Anteil zugeteilt" in "Adressbereiche/Global Unicast" erschließt sich mir nicht. Kann das jemand umformulieren? Ich kanns ja nicht, weil ich nicht weiß was es aussagen soll :) --2001:470:6D:486:21C:25FF:FE18:E2C9 23:24, 4. Jan. 2013 (CET)
thread_title:  nicht verständlich 

message: Um die doppelte Vergabe einer Adresse zu verhindern, ist der Mechanismus Duplicate Address Detection (DAD – Erkennung doppelt vergebener 
 Adressen) vorgesehen.[33] Ein Gerät darf bei der Autokonfiguration nur unvergebene Adressen auswählen. Der DAD-Vorgang läuft ebenfalls ohne 
 Benutzereingriff via NDP ab.
Wie funktioniert das? Vor allem unter Berücksichtigung dass es weiter unten heißt:
  ...ist die Autokonfiguration eine „Stateless Address (Auto)Configuration“, da Geräte sich selbst eine Adresse zuweisen und über diese Vergabe 
 nicht Buch geführt wird.
Grüße, --StYxXx ⊗ 23:58, 19. Mär. 2013 (CET)
replies: text: DAD siehe RFC 2462, Abschnitt 5.4 und Stateless Address Autoconfiguration siehe RFC 4862. --Lex parsimoniae (Diskussion) 00:10, 20. Mär. 2013 (CET)
replies: text: Öhm...könnte das jemand für Nicht-Experten übersetzen und in den Artikel einbauen? :D --StYxXx ⊗ 16:36, 21. Mär. 2013 (CET)
replies: text: Eigentlich ist das im Artikel schon richtig erklärt. Die DAD ist ein Mechanismus, der während der Autokonfiguration zur Anwendung kommt. Vielleicht verstehe ich auch Deine Frage nicht richtig. Was genau ist unklar? --Lex parsimoniae (Diskussion) 22:04, 21. Mär. 2013 (CET)
replies: text: Was ich nicht verstehe ist: Wie wird verhindert, dass eine Adresse doppelt belegt wird? Dazu müsste ja Buch darüber geführt werden, welche Adressen bereits genutzt werden und von wem. Es heißt aber im zweiten Zitat, dass genau das nicht der Fall wäre. --StYxXx ⊗ 08:19, 6. Apr. 2013 (CEST)
replies: text: Salopp gesagt: Man schickt eine "Neighbor Solicitation" an die Adresse, die man belegen will. Wenn keine Antwort kommt, ist die Adresse frei. Wenn eine Antwort kommt, ist sie nicht frei. --Echoray (Diskussion) 08:45, 6. Apr. 2013 (CEST)
thread_title:  Autokonfiguration - DAD 

message: ...Im Internet soll IPv6 in den nächsten Jahren die gegenwärtig noch überwiegend genutzte Version 4 des Internet Protocols ablösen ... Geht's vielleicht etwas präziser? --88.77.149.59 00:28, 15. Apr. 2013 (CEST)
replies: text: Nein. Das hängt von einer unüberschaubaren Vielzahl von Beteiligten ab, die ihren Teil dazu beitragen müssen. Wie schnell das gehen wird ist nicht vorhersehbar. --Hamburger (Disk) 01:38, 15. Apr. 2013 (CEST)
replies: text: Einen Anhaltspunkt wie weit verbreitet IPv6 zumindest bei den Website-Anbietern ist findet man unter http://www.allesedv.at/de/Support_IPv6.htm. Der Link ist aber nach wie vor nicht in den Weblinks drin - siehe http://de.wikipedia.org/wiki/Diskussion:IPv6#IPv6_Stats . Ich trau mich aber nicht selbst den Link wieder reinzustellen - will ja keine auf den Deckel bekommen :-) --DonatelloXX (Diskussion) 00:37, 17. Apr. 2013 (CEST)
replies: text: „Im Internet soll IPv6 in den nächsten Jahren die gegenwärtig noch überwiegend genutzte Version 4 des Internet Protocols ablösen“ heißt es schon seit 15 Jahren... und wird wohl auch noch einige Jahre lang die präziseste Prognose sein, die machbar ist. --Lex parsimoniae (Diskussion) 21:25, 17. Apr. 2013 (CEST)
thread_title:  Zeitangaben 

message: Im Abschnitt IPv6#Adressnotation heißt es, ein eizelner 0-Block dürfte nicht ausgelassen werden (Quelle: RFC5952 4.2.2). Laut RFC5952 4 handelt es sich bei den Unterpunkten aber lediglich um Empfelungen zur Notation. Die Regeln aus RFC4291 sind, soweit ich das verstehe, weiterhin gültig. --Remohe (Diskussion) 19:50, 5. Mai 2013 (CEST)
thread_title:  Auslassen eines einzelnen 0-Blocks 

message: Hallo,
im Gegensatz zu der englischen Version der Wikipedia fehlt hier ein Abschnitt zu Proxy Mobile IPv6 (RFC5213).
Es wäre toll wenn sich jemand darum kümmern würde, da es afaik wichtig für die Migration IPv4 > IPv6 ist und laut der englischen Wiki-Seite das einzige Mobility-Management Protokoll ist, welches von der IETF standartisiert wurde.
http://en.wikipedia.org/wiki/Proxy_Mobile_IP
http://tools.ietf.org/html/rfc5213 (nicht signierter Beitrag von 134.60.140.24 (Diskussion) 17:03, 7. Aug. 2013 (CEST)
thread_title:  Proxy Mobile IPv6 fehlt! 

message: Ich störe mich an dem Satz "Da ein einzelner Host auch als Netzwerk mit einem 128 Bit langen Präfix betrachtet werden kann, werden Host-Adressen manchmal mit einem angehängten „/128“ geschrieben."
Das hat mehrere Gründe: 
1. Ein host hat praktisch nie nur eine einzige IPv6, sondern es wird ihm immer ein Prefix gegeben. 
2. Gemäß dem RFC 6177 sollen /128 Adressen nicht mehr vergeben werden "This document obsoletes RFC 3177, updating its recommendations in the following ways: 1) It is no longer recommended that /128s be given out. [...]"
3. Selbst wenn es so wäre, dass man eine /128 Adresse zugewiesen hat, so würde man damit nicht den einzelnen Host identifizieren, sondern einen (der meist mehreren) Netzwerk-Adapter des Hosts. (nicht signierter Beitrag von Masgo (Diskussion | Beiträge) 22. Jan. 2016, 03:52:33‎)
:Zwar wird den Standards entsprechend üblicherweise ein /64-Subnetz an einen einzelnen Host geroutet, die Ansprache des Hosts (ein Verbindungsaufbau) erfolgt dann aber über eine einzelne Adresse aus eben diesem /64-Subnetz. Eine einzelne Adresse kann auch als /128-"Subnetz" dargestellt werden. Vereinfacht: Wenn du in deinem Browser eine IPv6 eingibst, gibst du da nicht ein /64-Subnetz ein, sondern eine einzelne Adresse aus dem zu diesem Host gerouteten /64-Subnetz.
:Übrigens: Bitte unterschreibe deine Beiträge mit --~~~~ damit man das später nachvollziehen kann. Bitte entschuldige außerdem die kommentarlose Zurücksetzung, ich habe erst nach meinem Klick gemerkt, dass ich eigentlich eine Begründung angeben wollte. --Vanger !–!? 23:15, 22. Jan. 2016 (CET)
thread_title:  Einzelner Host als „/128“ geschrieben. 

message: Hier sollte noch die Situation mit Windows 10 beschrieben werden, diese fehlt zurzeit. Oder falls diese Identisch mit der Unterstützung von Win 8 sein, dort der Eintrag in "Windows 8/8.1/10" umbenannt werden. (Was ich mal annehme, dass es richtig ist.) --Divof (Diskussion) 16:18, 1. Dez. 2016 (CET)
replies: text: Ich habe mir die Freiheit genommen, die Einträge zu Windows zusammenzufassen und massiv zu kürzen. Wie bei den anderen Systemen enthält der Text nun den Hinweis ab welcher Version IPv6 verfügbar ist. Eine historische Auflistung von längst nicht mehr erhältlichen Systemen wie Windows 98/ME oder Windows 2000 Server macht hier meiner Meinung nach keinen Sinn. --Bruflu (Diskussion) 13:50, 15. Mai 2017 (CEST)
thread_title:  Technische Umsetzung: Betriebssysteme 

message: Gemäß RFC6666 existiert ein Blackhole Prefix, 0100::/64, welcher als "Blackhole" fungiert. Fehlt im Artikel als besonderer Adressbereich. --80.155.143.226 16:14, 13. Dez. 2018 (CET)
thread_title:  Besondere Adressen - RFC 6666 fehlt 

message: m.E. sollte das Thema stärker hervorgehoben werden. IPV6 erschwert das anonyme Arbeiten im Netz und ermöglicht praktisch jedem Webseitenbetreiber, die Besucher zu tracken und zu loggen. 46.88.170.162 17:09, 15. Jan. 2019 (CET)
replies: text: Kann man so nicht sagen. --Seewolf (Diskussion) 17:16, 15. Jan. 2019 (CET)

text: Unter IPv6#Datenschutz ist m.M.n. bereits alles dazu gesagt, was es zu sagen gibt. Falls etwas fehlen sollte, kannst du es gerne ergänzen. --RokerHRO (Diskussion) 11:08, 16. Jan. 2019 (CET)
thread_title:  Anonymität 

message: Warum verweist das ii m Artikel auf einen Absatz in dem es auch auf sich selbst verweist.
Nur wird im Abschnitt nirgends erklärt was Link local überhaupt bedeutet?!
Wer kennt sich aus und kann was dazu schreiben?--91.20.181.199 20:36, 4. Sep. 2019 (CEST)
thread_title:  Link local verweist auf sich selbst 

message: 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)
replies: text: 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)
thread_title: IPv4 Einleitungstext gehört verschoben