 IPv6, das unbekannte Wesen, immer noch, auch wenn die meisten von uns eigentlich schon so ein bisschen wissen sollten, was da abgeht und so, auch in Verbindung mit Linux. Aber noch mal als Nachhilfe und um das nochmal so eine Intro zu machen, ist Bücherratten hier. Sie hat auf dem 35C3 schon mal einen Vortrag gehalten über, ich baue mir mein Smartphone selber. Macht nicht jede, macht nicht jeder und heute ist sie hier und erzählt uns Dinge über V6. Ich bin selber super gespannt. Ja, Applaus für Bücherratten. Ja, schön, dass ihr alle so früh aufgestanden seid. Vorweg erstmal ein Disclaimer. Dieser Vortrag ist vegan. Das heißt, ich habe auf den Einsatz von Tieren und tierischen Erzeugnissen beim Vortrag erstellen verzichtet. Dass Tierwohl und die Rechte von Tauben und anderen Flugtieren bleibt gewahrt. Der Vortrag ist übrigens auch unvollständig, weil IPv6 so ein riesiges Thema ist, dass man das in einem Vortrag leider nicht komplett abhandeln kann. Ich habe mich sehr an die gültigen RFCs gehalten. Es sind auch humorvolle RFCs mit integriert. Die habe ich grün hervorgehoben, damit ihr halt einen Überblick habt, was ist ein humorvoller RFC und was ist wirklich ernst gemeint. Ich habe euch Befehlbeispiele mitgebracht. Dort habe ich das halt entsprechend hervorgehoben, was ihr zu ersetzen habt. Einfach, falls ihr das zu Hause mal selber ausprobieren wollt, das ist möglich. Ich werde halt einmal kurz am Rande Vogelkrankheiten erwähnen und bitte bedenkt auch, dass nicht alle Flugtiere Vegetarier sind. Das wäre sehr hilfreich. Was möchte ich mit euch machen? Ich werde euch so eine Einführung zu allgemein, zu IPv6 geben. Wir werden das Aussehen von IPv6-Adressen besprechen. Ich werde euch die unterschiedlichen IPv6-Adress-Bereiche vorstellen. Ich werde auf besondere IPv6-Adressen eingehen, aber auch die Bedingungen bei IPv6-Adressen in Bezug auf Brieftauben. Ich werde so ein bisschen Hands-ons machen. Da werde ich euch tatsächlich Befehle zeigen und ich werde auch so ein bisschen auf das Protokoll von IPv6 eingehen. Zum Schluss Autokonfiguration mittels Slack werde ich auch noch darauf eingehen und dann werde ich eigentlich auch schon durch. Ich bin Bücherattin, ich bin 39 Jahre alt, ich bin seit letzten Sommer Fachinformatikerin, ich bin beruflich sehr viel mit Ansible beschäftigt. Seit 2009 bin ich Linuxerin, ich bin Free Software Aktivistin, bin aktiv bei den Hexen Linux Vox, der Berliner Linux User Group und auch der FSFE. Warum eigentlich IPv6? Bei IPv6 gibt es endlich mal genug IP-Adressen. Ihr werdet vielleicht schon häufiger gehört haben, dass IPv4-Adressen eigentlich ausgegangen sind. Das heißt, wir haben endlich mal genug IP-Adressen auch für IoT beziehungsweise des Internet of Toilets. Wen das näher interessiert, ich habe da mal einen Vortrag verlinkt, den ich sehr cool fand. Sie erlauben wieder eine reine End-to-end Kommunikation. Die globalen Adressen sind auch von global erreichbar. Wir haben wieder eine hierarchische Adressvergabe. Sie erlauben einen geografischen Bezug. Es gibt keine umständlichen Adressübersetzung mehr. Für die Leute von euch, die den Nut ein Begriff ist, das verwendet man unter IPv6 nicht unbedingt. Es gibt eine einfache Autokonfiguration von IPv6-Adressen. Es gibt einige Änderungen im Herder, wodurch das Routing verbessert ist und auch Quality of Service. Last but not least muss ich natürlich erwähnen, die Verschmutzung durch den Verzicht auf Rieftraum und andere Flugtiere ist natürlich nicht minder zu beachten. Kommen wir mal dazu, was braucht man eigentlich so für Voraussetzungen, um IPv6 eigentlich zu machen. Es gibt dazu einen offiziellen RFC, was so die Voraussetzungen sind. Ich habe mich hier darauf beschränkt, nur das, was zwingend erforderlich ist laut diesem RFC, halt euch mal zu zeigen. Ganz banal, ihr müsst natürlich die Fähigkeit haben, IPv6-Pakete zu empfangen und zu senden. Das weitere muss gewährleistet sein Präfix-Erkennung, MultiCast. ICMP-V6, das ist sowas wie PING oder PING gehört zu ICMP. Niber Unretual Detection zwischen den einzelnen Rechnern, Duplicate Address Detection, aber auch die Router-Erkennung. Dort ist insbesondere das Advertisement und das Soliciation zu erwähnen. Wichtig ist auch, die DNS-Option in dem Router-Advertisement, das muss gelesen werden können laut diesem RFC. Ich habe herausgefunden, dass unter Microsoft Windows das erst ab Version 11 möglich ist. Wichtig ist auch die MTU-Fahrterkennung und die Größenerkennung und halt Stateless Address Auto-Configuration. Das, wo man als erstes mal drauf stößt, viele schalten IPv6 aus. Das heißt, ich habe euch hier einmal die Befehle mitgebracht, wie ihr IPv6 wieder anschalten könnt unter Linux. Ich werde nur auf die entsprechenden Kernel-Parameter-System die NetworkD und den NetworkManager eingehen. Es kann sein, dass je nachdem, was ihr für eine Software verwendet, um mit dem Internet oder dem Netzwerk zu kommunizieren, das entsprechend anders bei euch ist. Aber ich konnte nicht alles abdenken. Das hätte ich nicht auf die Slides gepasst. Kommen wir nun zu den Brieftauben beziehungsweise IPAC. Erstmal so eine grobe zeitliche Einordnung. Erstmals wurden IP over Area and Carrier 1990 im RFC 1149 erwähnt. Seit 1999 ist tatsächlich auch die Quality of Service definiert und seit 2011 ist das Ganze auch für IPv6 spezifiziert. Wie sieht das eigentlich praktisch aus? Erstmal müsst ihr hingehen und euer IP-Paket in Hexadecimal auf eine Papierrolle ausdrucken. Die rollt ihr dann um die Beine des Area and Carriers, den ihr euch ausgesucht habt. Das Ende des Papiers wird mit Panzer Tape laut RFC befestigt. Ich habe gehört, das soll nicht so gut sein. Und die Länge der Beine bestimmen halt die Bandbreite. Das heißt, wenn ihr auf eine hohe Bandbreite setzen wollt, dann würde ich euch vorschlagen, vielleicht ein Flamingo zu nehmen. Wenn ihr so eine Brieftaube oder einen Area and Carrier empfängt, dann müsst ihr natürlich vorsichtig das Panzer Tape entfernen und die Papierrolle wieder einscannen. Es gibt da natürlich auch sehr typische Probleme, also so Windverhältnisse sollen ein Problem sein bei der Übertragung. Es gibt auch ein Risiko mit der Vogelgrippe H5N1. Da sind natürlich entsprechende Erkennungsmaßnahmen und Quarantäne-Maßnahmen wichtig mit zu beachten. Es ist auch ausschließlich eine Point-to-Point-Verbindung pro Area and Carrier möglich und es kommt zu hohen Verschwetungen bei einer niedrigen Durchflusshöhe. Wer es mag, kommen wir zum Thema, wie sieht eigentlich so eine IPv6-Adresse aus? Naja, das sind 128 Bit. Das Ganze wird den Hexadizimal beschrieben, also 0 bis 9, A bis F. Und wichtig, alle Buchstaben werden kleingeschrieben. Es gibt Gerüchte, dass es auch große Buchstaben in IPv6 Adressen gibt. Nein, das ist veraltet. Das Ganze wird aufgeteilt in 8 Blöcke, A4 Hexadizimalzahlen. Diese werden durch Doppelpunkt getrennt und man teilt es auf zwischen Prefix und Interface Identifier, jeweils 64 Bit. Und diese Zitre, die Netzwerkgröße, hängt man auch noch dran. Und ich habe euch ein Beispiel mitgebracht, damit ihr wisst, wie sowas aussehen kann. Jetzt kann man das natürlich auch noch kürzen, weil so eine IPv6-Adresse ist sehr lang. Das Erste, was man sich überlegt, hat man kann führende Nullen weglassen. Dann hat man sich überlegt, naja, man könnte auch den längsten Block einfach durch Doppelpunkt doppelpunkt ersetzen. Das macht das Ganze nochmal kürzer. Was ist denn jetzt, wenn ich mehrere Blöcke habe, die gleich lang sind? Na ja, es ist recommended, es ist nicht im RFC spezifiziert, nur recommended, dass man den ersten Block von links durch Doppelpunkt doppelpunkt ersetzt. Der ganze Vortrag ist etwas interaktiv. Das heißt, ich würde euch jetzt um Handzeichen bitten. Es geht darum, dass ihr ratet. Ich erwarte nicht, dass ihr es wisst. Wie denkt ihr, wird ein Interface Identifier gebildet? A. Nach EOI 64 Standard. Ich bitte um Handzeichen. Keiner. Entweder nach EOI 64 oder nach Privacy Extension. Ich bitte wieder um Handzeichen. Ja, das sind ein paar. Es gibt mehr als vier Methoden. Wer ist dafür? Das sind schon wesentlich mehr. Es gibt genau drei Methoden, die nicht mehr definiert sind. Das sind nicht ganz so viele, die darauf zählen. Ich habe euch natürlich auch die Auflösung mitgebracht. EO 64 ist veraltet. Auch Privacy Extension wird nicht mehr unter Linux standardmäßig verwendet. Es gibt tatsächlich mehr als vier Methoden, einen Interface Identifier zu bilden und die ist damit auch falsch. Aber gucken wir uns das eigentlich mal an, auch wenn es veraltet ist. Bei EOI 64 hat man sich überlegt, Mac-Adressen sind ja relativ unik und wir nehmen die Tiny in die Mitte, parken FFE in die Mitte rein und flippen noch ein Bit. Man hat halt nicht daran gedacht, dass Mac-Adressen doch nicht so unik sind. Dann hat man sich überlegt, das ist vielleicht auch nicht unbedingt so Privacy-konform und hat sich die Privacy Extension ausgedacht. Da wird der Zeitstempel nach der NTTP genommen und die Mac-Adresse verwurscht wird. Darüber bildet man ein MD5 Hash aus einer Länge von 64 Bit und damit hat man dann den Interface Identifier. Aber wie ich das schon erwähnt habe, die Sachen sind veraltet. Ich habe euch trotzdem mal mitgebracht, wie ihr das Unterlehnungs einstellen könnt. Das ist hier für EOI 64. Hier sind die Konfigurationsmöglichkeiten für die Privacy Extension. Kommen wir zu dem modernen Kram. 2014, FC 7217. Semantisch und durchsichtige Interface Identifier hat man sich ausgedacht. Da wird halt Information aus dem Präfix, dem Interface-Namen der Netzwerk-ID, Duplicate Addresdic-Tection-Counter und ein geheimer Schlüssel genommen. Das wird verwurscht, daraus wird eine Interface Identifier gebaut. Das hat ein Vorteil, man hat das stabil für jedes Subnetz. Es ist nicht vorhersagbar, es ist nicht an die Hardware gewonnen und damit halt für Server-Dienste geeignet. Es gibt aber auch Nachteile. So sicherstellen, dass das ein einzigartiger Interface Identifier ist, ist schwierig. Wie der Secret Key aussehen soll, der geheime Schlüssel, es ist im RFC nicht genau spezifiziert. Es kommt auch eventuell zu Wartezeiten bei der Generierung und so ein statischer Interface Identifier macht natürlich das Boofing leichter. Das ist seit 2015 im Linux-Körnel Integrit. Die meisten Distributionen aus meiner Erfahrung wenden das auch als Default an. Hier habt ihr entsprechend die Befehle dazu und natürlich gibt es auch temporäre Addressen in modernen. Temporary Address Extension. Das ist basically, man nimmt das, was ich euch vorhin erklärt habe und packt die Zeit als Approach da noch mit zu und diese Addressen gelten auch nur für einen bestimmten Zeitraum. Das ist halt für End-Anwender gedacht. Es sollte die Default-Adresse sein und es ist nicht auf die Global-Adresse begrenzt. Das war es bei der Privacy Extension. Es gibt auch sehr klare Regeln, wie lange so eine Adresse gültig sein darf. Die bevorzugte Lebenszeit ist ein Tag, die maximale Gültigkeit zwei Tage und es gibt genau drei erlaubte Versuche, so eine Adresse zu generieren. Auch hier gibt es natürlich Nachteile. Das macht natürlich es komplizierter, das Netzwerk zu administrieren. DNS wird sehr wichtig, um halt bestimmte Services zu erreichen. Insbesondere wenn ihr Mehl-Server aufsetzt. Reverse DNS ist erheblich erschwert damit. Das andere Ding, was ich noch rausgefunden habe, ist es noch nicht vollständig im Linux Kernel implementiert. Allerdings in OpenBSD, vielleicht wird das ja noch abgedatet. Wie sieht das mit den Interface Identifier und Briefterm aus? EUI 64 und Privacy Extension gibt nämlich bei dem Briefterm kein Layer 2. Damit haben wir keine Mac-Adressen. Das heißt, wir können diese Adressen nicht bilden. Was gibt es denn da so für Lösungen? Eine Lösung wäre tatsächlich Flying Address. Das steht unter complex addressing im RFC 8135. Das Problem ist, es ist nicht mehr spezifiziert. Es benutzt Teil die ICAO Class G Luftraum unterhalb der Wolken und das kann von unseren Layer-Technologien erwartet werden. Falls ihr Wassertiere einsetzt als Array and Carrier, besteht eine Verwechslungsgefahr mit Floating Addressen. Und diese Adressen werden halt mit Panzer Tape an dem entsprechenden Gerät befestigt. Und nein, das garantiert nicht, dass euer Gerät Wasser fest ist. Mit den neuen Adress-Interface Identifier ist es tatsächlich möglich, da diese unabhängig von der Mac-Adresse sind. Es gibt halt bestimmte Adress Bereiche, die ich euch jetzt vorstellen werde. Eines der allerwichtigsten Sachen ist dabei Unicast. Unicast ist die Kommunikation zwischen ganz genau zwei Tiny-Man. Ich habe euch hier mal eine Übersicht mitgebracht, wie viele Unicast-Adress-Bereiche es gibt. Einfach nur, damit ihr das einmal gesehen habt. Jetzt gehen wir da näher rein. Zum Ersten gibt es die Link-Local-Unicast-Adress. Und die erkennt ihr immer an dem FE80-Prefix. Das ist so für das LAN bei euch zu Hause. Und die wird immer erstellt, auch ohne Router. Sie ist eindeutig als Interface-Adresse und sie wird halt für die automatische Adressekonfiguration benutzt. Wichtig ist auch, diese Adressen werden nicht in ein anderes Netzwerk geroutet. Es ist bei IPv6 so, es macht einen Unterschied, ob ihr mit eurem Rechner im LAN oder im WLAN seid. Jede Netzwerkschnittstelle ist quasi eine Zone. Und diese Zone muss bei einer Link-Local-Adresse mit angehangen werden. Und das macht ihr mit Prozent. Und unter Linux findet ihr diese Zone heraus mit IP-Link. Das ist der Name des Interfaces. Unique Local ist auch für private Adressen. Es ist der FD0-Prefix. Und der kann in ein anderes Netzwerk geroutet werden. Sie müssen nicht registriert werden. Aber es gab bereits mehrere Versuche, das zu registrieren. Ich habe euch da mal den entsprechenden Link mitgebracht. Und bei DualSec, also wenn ihr IPv4 und IPv6 einsetzt, werden diese Adressen nicht bevorzugt benutzt, sondern IPv4. Das hat was mit den iBall-Adressen zu tun. Und das ist ein ernst gemeinte FD0 gewesen. Es gibt auch eine Diskussion, ob man Unique Local Adressen überbraucht. Das teilt sich auf als Refix einmal global FC. Und da drin ist der Refix FD für lokal. Bisher werden aber nur FD-Adressen vergeben. Es gibt da drin bei diesen Unique Local Adressen eine globale ID. Ich wollte euch nicht vorenthalten, wie die nach RFC zu bilden ist. Und zwar wird die Tageszeit genommen der EOI 64 Interface Identifier oder die Mikadresse des Systems. Tageszeit und Interface Identifier werden gemischt, um daraus einen Key zu erstellen. Dann wird ein SH1 Wert gebildet von 160 Bit. Und die letzten 40 signifikanten Bits werden als Global ID verwendet. Dann gibt es noch globale Unicast-Adressen. Das Problem dabei ist, der Refix ist nicht genau spezifiziert. Was spezifiziert ist, dass die ersten drei Bits, wenn die null sind, dann ist kein Interface Identifier erforderlich. Das hat man in der Regel, wenn man so Sachen baut wie IPv4 in IPv6-Adressen. Momentan werden aus dem Adressbereich 2000 Adressen verteilt. Diese Adressen werden im Internet geroutet und sie sind weltweit erreichbar. Da gibt es auch eine globale Struktur, die IANA vergibt in der Regel Slash 23 Adressen. Stripe baut daraus Slash 32 Adressen und euer Internet Service Provider würde daraus theoretisch euch ein Slash 48 zur Verfügung stellen. Ihr müsst dann entsprechend zahlen. Der Default ist tatsächlich Slash 64. Kommen wir wieder zum Raten. Was glaubt ihr? A. Broadcast ist auch in IPv6 vorhanden. Wer ist der Meinung? Das sind sehr wenige. In IPv6 gibt es nur Unicast, Multicast und Anycast. Wer ist der Meinung? Ja, das sind ein paar. C. Anycast ist genau das gleiche wie Broadcast. Ein bisschen mehr. Und Broadcast wird in IPv6 nicht verwendet. Das sind sehr viele. Das ist die Auflösung. Es gibt in IPv6 Unicast, Multicast und Anycast und Broadcast wird in IPv6 nicht verwendet, weil eine ähnliche Funktionalität Multicast verwendet. Schauen wir uns Multicast mal an. Multicast ist die Verbindung zu mehreren Teilnehmern. Ihr erkennt das am prefix ff und da kommen noch so einige Sachen danach hinzu. Ich habe euch das hier mal aufgelistet. Wie sehen die aus? Das sind so einige Beispiele. Es gab mal eine Frage, warum sind das nur lokale Adressen? Die Globalen sind noch nicht spezifiziert. Das Besondere hier ist, dass man zum Beispiel alle OSPF-Router ansprechen kann. Und zwar nur diese. Oder alle RIPE-Router. Oder halt alle Notes, die sich in dem Netzwerk befinden. Oder auch alle DRCP-Sauer. Da gibt es jeweils eine eigene Multicast-Adresse für. Kommen wir zu Anycast. Anycast kann auf mehreren Interfaces konfiguriert sein. Spricht aber immer nur mit der nächsten Adresse. Sie haben keinen spezifischen Adressbereich. Und das sind in der Regel Unicast-Adressen mit dem Interfaces Identifier auf Null. Wofür braucht man das? Ein Nutzen ist zum Beispiel Lordbalancing. Es gibt noch weitere besondere IPv6-Adressen. Die habe ich euch hiermit gebracht. Besonders herausheben möchte ich die 2001 DB8. Das ist eine nicht-routbare globale Unicast-Adresse für Dokumentationszwecke only. Wie sieht das jetzt mit den Brieftermausen? Also was halt sehr wichtig ist, es kann nur das andere Ende des Links adressiert werden. Und Unicast-Adressen kann man nicht zu Link-Local-Adressen mapen. Das steht halt so noch im RFC. Aber wir haben gesehen, dass das mit den neuen Interfaces Identifier durchaus möglich ist. Multicast-Implementierungsversuche, die resultierten inner erhöhten Geräuschübertragung und dadurch fehlerhafte Prüfzungen. Das heißt, wenn wir uns das so angucken, wir haben die Fähigkeit IPv6-Adressen Pakete zu senden und zu empfangen, ICMPR schwierig, Multicast nein. Es gibt es da so für Lösungsmöglichkeiten. Das eine wird tatsächlich im RFC 6214 schon erwähnt. Und zwar ein Präfix 127 zu verwenden oder halt eine statische Adresse. Das Ding ist dieser Präfix ist eigentlich gedacht für die Point-to-Point-Kommunikation zwischen Routern laut RFC 6164. Das Problem dabei ist, dass es zu einer Nibal-Discovery-Exhausten kommt. Das heißt, ihr schickt eure Brieftauben ständig hin und her, bis sie erschöpft sind. Ihr seid wieder drin. Ich möchte von euch wissen, welche dieser folgenden IPv6-Adressen ist gültig. Wer ist der Meinung, dass A gültig ist? Da zeigen einige auf. Wer ist der Meinung, dass B eine gültige Adresse ist? Da zeigen schon mehr auf. Wer ist der Meinung, dass C eine gültige Adresse ist? Einige wenige. Und wie sieht es mit D aus? Da zeigen auch einige auf. Ich habe euch natürlich wieder die Auflösung mitgebracht. A ist tatsächlich nicht möglich, weil FE 80 ist zwar richtig, aber danach direkt kommt kein Doppelpunkt-Doppelpunkt, sondern ein sogenanntes Subnetz. Und das ist für FE 80 nicht spezifiziert. B wäre richtig, das Slopec. C ist eine unique Local-Adress. Und D, da kann man jetzt drüber streiten, es ist die Adresse für Dokumentationszicke. Wir gehen jetzt so ins Hands-On rein. Hier ist es halt wichtig, dass, was ihr schon kennt, man prüft erst mal, ob man überhaupt eine IPv6-Adress hat. Und hier habe ich euch tatsächlich dann noch die Möglichkeiten fürs Ping mitgebracht. Ich habe natürlich meine Konsole mitgebracht. Schauen wir mal, hab das i vergessen. Wir haben hier unsere IPv6-Adresse. Das heißt, wir können jetzt tatsächlich anfangen zu spielen. Das ist schon mal gut. Das erste, was wir ausprobieren, ist natürlich Ping. Und nein, ich habe die nur gruppiert. Ich habe das nicht so schnell getippt. Was fehlt? Ping. Verdammt. Ihr seht, das antwortet. Das ganze kann man natürlich auch mit der unique Local-Adresse machen. Ich habe schon wieder das Ping vergessen. Bin nicht gut sortiert. Auch hier seht ihr, das funktioniert. Eine Sache muss ich euch noch zeigen. Ich habe natürlich meine Brieftaube mitgebracht. Es ist ein Raspberry Pi. Er heißt Brieftaube. Was wir auch noch machen können, ist, können natürlich auch auf die netten Multicast-Adressen mal prüfen. Hier fragt ihr jetzt alle Notes ab. Und wie ihr seht, das ist die Adresse für alle Router. Auch das funktioniert. Wie ihr das schon gesehen habt, bei Ping ist es halt tatsächlich, wenn ihr Link-Local-Adressen verwendet, sehr wichtig, dass ihr die Zone mitnehmt. Sonst funktioniert es nicht. Bei einer Ula ist es nicht so wichtig. Es geht natürlich auch SSH. Und damit bin ich verbunden. Und ich habe dem weiß erbracht, es ist Brieftaube. Das war die Link-Local-Adresse. Ich zeige euch, dass das mit der Ula tatsächlich auch funktioniert. Wieder drin. Auch hier bei der Link-Local-Adresse vergisst die Zone nicht. Es geht natürlich auch Köln. Ich habe ein Web-Sover drauf. Ich werde hier allerdings ein bisschen kürzen. Wir brauchen halt nur die Information, ob die Webseite da ist. Ihr seht, das funktioniert. Wichtig ist hier tatsächlich die erkriegenden Klammern. Und zwar, egal ob ihr Link-Local oder die Ula verwendet oder die GUA vielleicht irgendwann mal. Dann ist euer Rätselraten wieder gefragt. A. Der grafische Webbrowser, der kommt nur mit Multicast-Adressen zu Recht. Wer ist der Meinung? Keiner. IPv6-Adressen kann man im Webbrowser nicht aufrufen. GUI, wir sprechen von der Graphical vom Grafischen. Es zeigt keiner auf. IPv6-Adressen müssen im Webbrowser im Grafischen grundsätzlich in eckigen Klammern geschrieben werden. Das sind so gut wie alle. Wer ist für die Link-Local-Adressen, kann man im Grafischen Webbrowser nicht aufrufen. Nur Ulas und GUAS? Ganz wenige. Das ist die Auflösung. Ne? Das ist die Auflösung. Ich muss euch sagen, dass Link-Local-Adressen auflösen kann, aber der ist nicht grafisch. So würdet ihr das dann tatsächlich tun. Kommen wir nun zu den IPv6-Protokollen. Diese Protokolle nutzen halt ICMP. Ihr hattet schon mal, ich hatte schon mal erwähnt, das hat sehr viel mit Pink zu tun. Und das ist der Header, der tatsächlich in einem ICMP-V6-Paket verwendet wird. Der drunter fällt zum Beispiel das Niber-Discovery-Protokoll. Das wird verwendet, um halt zu erkennen, welche Teilnehmer noch alles in dem Netzwerk sind und entsprechende Informationen zu ermitteln. Sniper Unreachable-Protokoll. Das wird verwendet, um zu ermitteln, ob eine Adresse noch erreichbar ist. Das Ganze kann man sich natürlich unter Linux anschauen. Ich habe euch hier die entsprechenden Befehle mitgebracht. Dann sehr wichtig, Duplicate Address Dictation. Das soll verhindern, dass es Konflikte zwischen doppelt vergebenen IP-Adressen gibt und das halt erkennen. Das ist Pflicht, bei einer Adresse zu verwenden und das kann Betriebssystem seitig ausgeschaltet werden. Hier sind die entsprechenden Befehle. Was glaubt Ihr eigentlich? Ihr seid schon wieder dran. Wenn die Duplicate Address Detection anschlägt, was passiert? Ich muss noch einen Hinweis geben nach FC. A. Sollte das Interface deaktiviert werden? Wer ist dafür? Ganz wenige. B. Sollte ein Systemfehler gelockt werden? Ja, schon etwas mehr. C. Wurde der Interface Identifier nicht basierend auf der Mac Adresse gebildet, könnte vielleicht fortgefahren werden. Vielleicht. Das sind auch einige. D. Wird eine neue Adresse generiert. Oh, das sind viele. Ich hoffe, Ihr seid nicht enttäuscht. Der aktuelle FC dazu ist 7.527. Und der sagt, wenn eine doppelte Adresse dediktiert wird, dann ist dem zu folgen, was in FC 4862 steht. Und da ist das leider nicht sehr deutlich spezifiziert. Was auch sehr wichtig ist bei Epi4.6 ist die Kommunikation mit dem Router. Das passiert über eine Router-Solation. Damit wird ein Router-Advertisement angefordert beim Router. Und dieses Router-Advertisement ist quasi dann die Nachricht. Ich bin ein Router. Ich gebe mich im Netzwerk hiermit bekannt. Und ich habe noch folgende Informationen für Dich, lieber Kleint. Und das wird in regelmäßigen Abständen gesendet. Wie ist das so jetzt? Die Zusammenfassung in Bezug auf IPUAC. Router-Erkennung. Präfix-Erkennung. Ja, das könnte noch funktionieren. Niber Unreachable Detection. Router-Advertisement und Router-Solation. Ihr braucht viele Berieftum. Die MTU Fahrterkennung und Größenerkennung. Wir hatten das mit der Länge der Beine. Ping. Das ist auch ein bisschen schwierig. Multicast. Nein, hatten wir schon. Duplicated Address-Dictation-Vergästes. Die DNS-Optionen im Router-Advertisement. Ja, das könnten wir tatsächlich umsetzen. Und Slack. By the way, was ist Slack eigentlich? Kommen wir dazu. Slack ist Dateless Address Autoconfiguration für IP-Adressen. Dabei wird eine Link-Local-Adresse und eine globale Adresse gebildet, also wenn ein Präfix für eine globale Adresse vorhanden ist im Netzwerk. Das wird nur bei multicastfähigen Interfaces gemacht und es erfordert kein manuelles Eingreifen. Euer Rechner macht das in der Regel selber. Es wird eine Duplicate Address-Detection ausgeführt. Es nutzt lokale Informationen aus dem Router-Advertisement. Und wenn kein Router vorhanden ist, dann wird nur eine Link-Local-Adresse gebildet. Man kann das zusammen auch mit DHCP V6 verwenden. Dann hat man mehr Kontrolle über die Adressen. Die Router Solation wird auf allen Router-Multicast-Gruppen ausgeführt. Und wenn jetzt der Präfix und der Interface-Identifier zusammen nicht 128 Bit ergeben wird, keine Adresse gebildet. Ich habe gehört, es gibt einige ISPs, die das mit dem IPv6 noch nicht so ganz verstanden haben und haben gedacht, 64 ist ja viel zu lang. Wir vergeben mal ein 65, das funktioniert nicht. Bei dem Belieftauben, Niber Discovery ist eigentlich unmöglich. Slack sollte gar nicht erst versucht werden zu implementieren und es gibt halt Beweise, dass einige Arian Carrier, Raubvögel, andere Arian Carrier gegessen haben und dann den gegessenen Paketinhalt getragen haben. Das ist eine ganz neue Methode für IPv4 in IPv6 Tunneling. Aber der Entpackungsmechanismus ist noch unklar. Es gibt eigentlich so Verlösungen. Man könnte noch das Niber Discovery Optimation für IPv6 over Low Power Realist Personal Area Networks verwenden. Da ist der Interface-Identifier wird mit der Router Association gebildet. Duplicate Address Detection wird nur unterstützt, wenn Slack verwendet wird und es werden keine Niber Solation Nachrichten unterstützt. Bei Adresse Initialisierung wäre es erst die Router Solation Nachricht abgewartet, bevor ein Adresse gebildet wird. Das werde ich euch jetzt nicht vorlesen. Das dürft ihr irgendwann mal nachschlagen. Das wäre noch eine weitere Möglichkeit. Was auch noch sehr wichtig ist, es gibt ein Real-Life Beispiel für IPv6 mit IPv6. Scenic Routing. Das wird zur Unterstützung grüner IT verwendet. Die Pakete werden so geroutet, dass sie möglichst viel frische Luft bekommt. Ich meine, wir sprechen von grüner IT. Dafür werden Routen basierend auf IPv6 gewählt. In der Scenic Routing Layout gibt es eine Option mit dem Type OnAir. Das ist vorgesehen und es wird immer der längste Ariane Carrier Fahrt verwendet. Vielen Dank fürs Zuhören.