Dave the Network Engineer: Relationship on the Rocks
So kann es kommen, wenn man nicht vorbereitet ist:
IPv6 Transition Update
Beim IEEE gibt es eine ca. 90-minütige Cisco-Präsentation mit dem obigen Titel:
http://www.comsoc.org/form/tutorial-registration-building-comprehensive-ipv6-transition-strategy
Früher, als Linux meine Hauptplattform war, konnte ich die IEEE-Tutorials nie betrachten. Das es jetzt auf meinem Mac auch nicht funktioniert hat, hat mich bei den Rechner-Empfehlungen auch nicht wirklich gewundert:
Viewing Recommendations: IE 8 or higher and Adobe Flash Player 10
(Auf meine Anfrage, ob Mac und Linux nicht eine unterstützenswerte Plattform für eine technisch orientierte Gesellschaft wäre, bekam ich damals übrigens nur die Antwort, das die meisten Mitglieder Windows verwenden …)
Wer wie ich als Mac-User dieses Tutorial trotzdem sehen möchte, dem kann natürlich geholfen werden. Im Seiten-Quelltext sind die Video-URLs hinterlegt:
http://host.comsoc.org/freetutorial/cisco4/Part1/draft-metz-ipv6-transition-tutorial-update-4-ieee-2011-part-1.pptx.mp4
http://host.comsoc.org/freetutorial/cisco4/Part2/draft-metz-ipv6-transition-tutorial-update-4-ieee-2011-part-2.pptx.mp4
Und diese URLs lassen sich direkt in Quicktime verwenden.
IPv6: Verwendung von /127er Prefixen
Unter IPv4 ist heutzutage die Verwendung von /30er oder /31er Netzen auf Point-to-Point-Links der Standard. Während früher Links noch häufig mit einer 30-bit Maske konfiguriert, und auch auf Point-to-Point-Links eine Netz- und Broadcast-Adresse vorsehen wurde, so verwendet man heute fast ausschließlich /31er Netze um keine Adressen zu verschwenden. Und besser rechnen lässt sich mit /31er Adressen auch.
Im IPv6 wurde die Verwendung von /127er Netzen lange Zeit sehr kontrovers diskutiert. Oftmals wurden diese mit Hinweis auf die nicht-Konformität mit den geltenden RFCs abgelehnt. Vielfach wurde es auch einfach damit begründet, dass man im IPv6 keine Adressen sparen müsse.
Jetzt haben die /127er Netze im IPv6 aber doch den offiziellen Segen des IETFs bekommen:
Während ich mir des “Ping-Pong”-Problems bisher nicht bewusst war (Section 5.1), hat mich das Problem der Neighbor Cache Exhaustion (Section 5.2) auch schon beschäftigt und ich fand die Verwendung von /127er Netzen auch keine schlechte Idee.
Schön, das man diese Prefixe jetzt auch “offiziell” auf Inter-Router Links verwenden darf.
Cisco IOS: EIGRP-Authentifizierung mit Key-Rollover
Über die Qualität der Cisco Schulungsunterlagen habe ich mich schon ab und an mal ausgelassen.
Und während ich mich gerade auf eine neue Kursversion eines Security-Kurses vorbereite, fällt mir schon wieder eine Sache auf, die man besser nicht so macht, wie es im Kurs beschrieben ist. Beim Thema Routing-Protokoll-Authentifizierung findet sich dort eine Key-Chain mit den folgenden send- und accept-lifetimes:
key chain MYKEYS key 1 key-string ThisIsKey1 accept-lifetime 04:00:00 Jan 1 2010 04:00:00 Feb 1 2012 send-lifetime 04:00:00 Jan 1 2010 04:00:00 Jan 1 2012 key 2 key-string ThisIsKey2 accept-lifetime 04:00:00 Jan 1 2012 04:00:00 Feb 1 2014 send-lifetime 04:00:00 Jan 1 2012 04:00:00 Jan 1 2014
Die accept-lifetime des zweiten Keys schließt sich hier genau an die sent-lifetime des ersten Keys an.
Was passieren kann, wenn man es genau so konfiguriert, habe ich in GNS3 nachgestellt (GNS3-Datei und Konfiguration):
- EIGRP-Authentication zwischen Router1 und
Router2
R0#ping ipv6 R2-Loopback0 repeat 500
Type escape sequence to abort. Sending 500, 100-byte ICMP Echos to 2001:DB8:2222::12, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!...............!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!R1:
Jan 1 03:59:56.435: IPv6-EIGRP: received packet with MD5 authentication, key id = 1
Jan 1 04:00:01.135: IPv6-EIGRP: received packet with MD5 authentication, key id = 1
Jan 1 04:00:03.971: IPv6-EIGRP: received packet with MD5 authentication, key id = 1
Jan 1 04:00:03.983: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 100: Neighbor FE80::C202:30FF:FE3F:0 (FastEthernet0/0) is down: Interface Goodbye received
Jan 1 04:00:08.495: IPv6-EIGRP: received packet with MD5 authentication, key id = 1
Jan 1 04:00:13.423: IPv6-EIGRP: received packet with MD5 authentication, key id = 1
Jan 1 04:00:17.767: IPv6-EIGRP: received packet with MD5 authentication, key id = 1
Jan 1 04:00:22.339: IPv6-EIGRP: received packet with MD5 authentication, key id = 1
Jan 1 04:00:26.723: IPv6-EIGRP: received packet with MD5 authentication, key id = 1
Jan 1 04:00:31.683: IPv6-EIGRP: received packet with MD5 authentication, key id = 2
Jan 1 04:00:32.551: IPv6-EIGRP: received packet with MD5 authentication, key id =2
R2:
Jan 1 03:59:28.843: IPv6-EIGRP: received packet with MD5 authentication, key id = 1
Jan 1 03:59:33.271: IPv6-EIGRP: pkt authentication key id = 2, key not defined or not live
Jan 1 03:59:33.271: EIGRP: FastEthernet0/0: ignored packet from FE80::C201:30FF:FE3F:0, opcode = 5 invalid authentication)
Jan 1 03:59:33.271: EIGRP: Dropping peer, invalid authentication
Jan 1 03:59:33.275: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 100: Neighbor FE80::C201:30FF:FE3F:0 (FastEthernet0/0) is down: Auth failure
Jan 1 03:59:37.823: IPv6-EIGRP: pkt authentication key id = 2, key not defined or not live
Jan 1 03:59:37.823: EIGRP: FastEthernet0/0: ignored packet from FE80::C201:30FF:FE3F:0, opcode = 5 (invalid authentication) ...
Jan 1 03:59:57.347: IPv6-EIGRP: pkt authentication key id = 2, key not defined or not live
Jan 1 03:59:57.347: EIGRP: FastEthernet0/0: ignored packet from FE80::C201:30FF:FE3F:0, opcode = 1 (invalid authentication)
Jan 1 04:00:01.851: IPv6-EIGRP: received packet with MD5 authentication, key id = 2
Jan 1 04:00:01.851: EIGRP: Received HELLO on FastEthernet0/0 nbr FE80::C201:30FF:FE3F:0
Jan 1 04:00:01.851: AS 100, Flags 0x0, Seq 0/0 idbQ 0/0
Jan 1 04:00:01.851: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 100: Neighbor FE80::C201:30FF:FE3F:0 (FastEthernet0/0) is up: new adjacencyWas ist da passiert? Für dieses Beispiel habe ich die Uhren beider Router mit einer Differenz von 30 Sekunden konfiguriert. Solche und größere Zeitabweichnungen habe ich auch schon in Netzen mit NTP gesehen. Im Normalbetrieb sollte das zwar nicht auftreten, aber durch Konfigurations-Probleme kann ein NTP-Server halt auch mal nicht erreichbar sein. Und ein Grundsatz guten Netzwerk-Designs heißt halt mit Recht “Always Plan for Problems”.
Für 30 Sekunden (das ist die Zeitspanne am 1.1.2012 von 04:00:00 bis 04:00:30 auf Router1 bzw. von 03:59:30 bis 04:00:00 auf Router2) wird der Router1 den ersten Key nicht mehr verwenden, dieser würde aber von Router2 noch akzeptiert werden. Dafür verwendet Router1 den zweiten Key, dieser wird aber von Router2 noch nicht akzeptiert:
- Die sent- und accept-lifetimes (nicht proportional gezeichnet)
Der Verbindungsabbruch von ca. 30 Sekunden ergibt sich daher, das der Router2 bei einer fehlerhaften
Authentifizierung sofort die Nachbarschaftsbeziehung abbricht und erst wieder aufbaut, wenn beide Router den Key 2 benutzen können. Router1 hat in dieser Zeit keine fehlerhaften Authentifizierungen.
Das Problem lässt sich recht einfach vermeiden, indem man die accept-lifetime nicht nur länger laufen lässt als die sent-lifetime, sondern auch vor der sent-lifetime des nächsten Keys beginnen lässt:
- Die accept-lifetime beginnt jetzt vor der send-lifetime
Was passiert jetzt in diesen 30 Sekunden:
- Router1 sendet seine Pakete schon mit Key 2, der auch von Router 2 akzeptiert wird.
- Router2 sendet seine Pakete noch mit Key 1, der von Router 1 noch akzeptiert wird.
Die (relevante) Konfiguration von Router2 sieht dabei folgendermaßen aus. Wie lang man dabei die accept-lifetime überlappen lässt hängt natürlich von den persönlichen Vorlieben ab. Ich habe für dieses Beispiel einfach fünf Minuten genommen:
hostname R1
!
key chain MYKEYS
key 1
key-string ThisIsKey1
accept-lifetime 04:00:00 Jan 1 2010 04:00:00 Feb 1 2012
send-lifetime 04:00:00 Jan 1 2010 04:00:00 Jan 1 2012
key 2
key-string ThisIsKey2
accept-lifetime 03:55:00 Jan 1 2012 04:00:00 Feb 1 2014
send-lifetime 04:00:00 Jan 1 2012 04:00:00 Jan 1 2014
!
interface FastEthernet0/0
ipv6 address 2001:DB8:2::11/64
ipv6 eigrp 100
ipv6 authentication mode eigrp 100 md5
ipv6 authentication key-chain eigrp 100 MYKEYS
!
ipv6 router eigrp 100
router-id 1.1.1.1
no shutdownWer sich darüber wundert, das ich dieses Beispiel mit IPv6 aufgebaut habe, dem sei der Beitrag Blog Examples Going IPv6 Next Year von PacketLife.net zu empfehlen. Diese Idee werde ich aufgreifen und ab sofort meine Beispiele auch mit IPv6 implementieren, wo es möglich ist.
Die (neue) richtige Schreibweise von IPv6-Adressen
Falsch: 2001:0db8::0001
Richtig: 2001:db8::1
Führende Nullen müssen unterdrückt werden!
Falsch: 2001:db8:0:0:0:0:2:1
Richtig: 2001:db8::2:1
Falsch: 2001:db8::0:1
Richtig: 2001:db8::1
Die Verwendung des “::” muss bis zum Maximum durchgeführt werden!
Falsch: 2001:db8::1:1:1:1:1
Richtig: 2001:db8:0:1:1:1:1:1
Ein einzelnes 16bit-Feld mit Nullen darf nicht zusammengefasst werden!
Falsch: 2001::1:0:0:0:1
Richtig: 2001:0:0:1::1
Bei mehreren Möglichkeiten die Adresse durch ein “::” zu verkürzen muss das längste Vorkommen von Nullen gekürzt werden!
Falsch: 2001:db8:0:0:1::1
Auch falsch: 2001:db8::1::1
Richtig: 2001:db8::1:0:0:1
Wenn mehrere Abfolgen von Nullen gleich lang sind, muss die erste verkürzt werden!
Falsch: 2001:db8:0:0:A::B
Richtig: 2001:db8:0:0:a::b
Die Zeichen “a” bis “f” müssen klein geschrieben werden!
Dies kann alles im RFC 5952 – A Recommendation for IPv6 Address Text Representation nachgelesen werden.
IPv6 readiness
Bei Jens Link habe ich einen Hinweis auf die “Test your IPv6 connectivity”-Seite gefunden. Und ja, ich denke, das sieht gut aus:
Aber die “Real-Life”-Geschwindigkeit wurde dabei nicht getestet. Und die ist mit dem HE-Tunnel leider nicht wirklich gut.
Es geht voran mit IPv6
So werden morgen z.B. für 24 Stunden die DNS-Rootserver abgeschaltet, um sie für IPv6 umzurüsten. Danach werden allerdings Benutzer älterer Systeme wie Windows XP offline bleiben.
Nähere Informationen gibt es bei tagesschau.de.
IPv6 TechWiseTV
Bei Cisco gibt es eine TechWiseTV-Episode zu IPv6:
Join Cisco expert Harold Ritter as he provides a technology update, shows best practices, and addresses how to deploy IPv6 in a service provider environment to cope with growing demand (59:18 min.).
Agenda
Is IPv4 Broken? Why Change a System That Works?
IPv6 for Dummies: Layer 2 Deep Exploration
Understanding IPv6 Routing and Security Challenges
Quality of Service and Transition Mechanisms
Planning and Deployment Considerations
Update: Eben sehe ich gerade, dass diese Folge schon über zwei Jahre alt ist. Bis Ende Januar ist sie noch anzuschauen.
Der Weg zur Weisheit
Nur wenige Wege führen zur Weisheit, und den Wenigsten ist dies wohl beschieden …
Für EDVler gibt es aber schon einen Weg, weise zu werden. Im Zuge des IPv6-Zertifizierungs-Prozesses von Hurricane Electric (die Firma hinter tunnelbroker.net, die kostenlose IPv6-Tunnel zur Verfügung stellen) durchläuft man verschiedene Stufen, bis man beim “Sage” angekommen ist und zumindest für dieses Thema eine Form der Weisheit erreicht hat.
Bei dieser Zertifizierung geht es darum, verschiedene Level der IPv6-Erreichbarkeit zu demonstrieren und eine Reihe von Fragen zu IPv6 zu beantworten. Die Sache ist nicht nur sehr informativ, sondern macht auch viel Spaß. Bei dieser IPv6-Erreichbarkeit ist es nicht notwendig, einen Tunnel von HE zu verwenden. Wer einen anderen Tunnel-Provider benutzt oder sogar nativ IPv6 hat (der Glückliche), der kann natürlich ebenfalls mitmachen.
Im folgenden beschreibe ich mein Setup, mit dem ich die verschiedenen Stufen dieser Zertifizierung durchgeführt habe und letztendlich bei der Weisheit angekommen bin:
- Newbie
- Explorer
- Enthusiast
- Administrator
- Professional
- Guru
- Sage
Für diesen ersten Level muss man nur ein paar einfache Fragen zu IPv6 beantworten. Wer sich bisher nicht mit IPv6 auseinandergesetzt hat, der könnte hiermit den Einstieg wagen.
Die Explorer-Stufe erreicht man, wenn man eine IPv6-Verbindung zum Internet hat. Für eine getunnelte Verbindung mit einem Cisco-Router habe ich die Vorgehensweise in einem eigenen Beitrag beschrieben.
Für den Enthusiast muss man einerseits einen IPv6-fähigen Client haben, mit dem man auf das Internet zugreifen kann, andererseits muss man einen Webserver betreiben, der Webseiten per IPv6 ausliefern kann. Die generelle Konfiguration eines Linux-Servers hat Jens Link schon in einer Reihe von Beiträgen beschrieben. Bei mir kamen noch ein paar Punkte hinzu. Zum einen sind meine Dienste (Mail, Web, DNS, etc.) mit OpenVZ virtualisiert. OpenVZ muss also auch für IPv6 konfiguriert sein (alle Systeme sind Debian Lenny):
klio:~# grep ipv6 /etc/sysctl.conf
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.default.forwarding=1klio:~# grep IPV6 /etc/vz/vz.conf
IPV6="yes"Weiterhin muss dem OpenVZ-Gast eine weitere IP-Adresse zugewiesen werden, in diesem Fall eine IPv6-Adresse:
klio:~# vzctl set 123 --ipadd 2001:DB8:1:2:3::1 --saveDiese IPv6-Adresse stammt nicht aus dem Tunnel-Netz, sondern aus dem zusätzlich zugewiesenen “routed /64″-Netz, das man beispielsweise bei tunnelbroker.net bekommt.
Hier könnte man natürlich auch mehrere IP-Adressen zuweisen, um jedem vhost eine eigene IP-Adresse zu geben. Damit könnte man problemlos alle Webpräsenzen mit HTTPS sichern. In meinem Beispiel bekommt die gesamte VM eine IPv6-Adresse, die für alle vhosts verwendet werden kann.
Vor einiger Zeit bin ich vom Apachen auf Lighttpd umgestiegen und bin bisher sehr zufrieden damit. IPv6 ist beim Lighty eine einzige zusätzliche Zeile in der Konfiguration:
root@www2:/# grep ipv6 /etc/lighttpd/lighttpd.conf
server.use-ipv6 = "enable"Natürlich soll auf die Webpräsenz per FQDN zugegriffen werden, weshalb auch im DNS ein neuer Eintrag vorgenommen werden muss. Während die IPv4-Adresse mit einem A-Eintrag konfiguriert wird, muss die IPv6-Adresse mit einem AAAA-Eintrag konfiguriert werden:
In der Zonen-Datei wird also folgende Zeile aufgenommen:
www IN AAAA 2001:DB8:1:2:3::1
Durch diesen Eintrag in der Zonen-Datei von example.com kann der FQDN nun zu der IPv6-Adresse 2001:470:1f0b:c2c::211 aufgelöst werden und der Webserver kann per IPv6 die Seite für www.example.com ausliefern.
Für diesen Level muss der Mail-Server per IPv6 Mails annehmen können.
In einem einfachen Postfix-Setup wird auch dafür nur eine neue Zeile in der Konfiguration benötigt:
inet_protocols = all
Ebenso muß für den FQDN des Mailservers natürlich ein AAAA-Eintrag hinzugefügt werden.
Um die Professional-Stufe zu erlangen, muss man eine funktionierende Reverse-DNS-Auflösung für den Mailserver haben.
Bei Tunnelbroker.net kann man für sein IPv6-Netz eine Reverse-Delegation anlegen. Damit ist der eigene Nameserver dann für die Reverse-Auflösung zuständig. Hierbei gibt es die Herausforderung, daß in der Zonendatei die Adressen in einer umgekehrten Schreibweise angegeben werden. Aus der Adresse 2001:DB8:1:2:3::1 wird z.B. die Zeichenkette 1.0.0.0.0.0.0.0.0.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2. Diese Umrechnung kann man mit dem Befehl “host -n” durchführen:
karstens-macbook-pro:~ karsten$ host -n 2001:DB8:1:2:3::1
Host 1.0.0.0.0.0.0.0.0.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa not found: 3(NXDOMAIN)
Alternativ kann man sich die Zonendatei bei fpsn.net mit dem Zone-Builder erstellen lassen.
Hier muss der Nameserver selbst AAAA-Einträge haben und per IPv6 erreichbar sein. Das ist im Prinzig die gleiche Arbeit wie beim Webserver weiter oben. Zusäzlich muss beim Bind9 die Option “listen-on-v6″ gesetzt sein.
Die letzte Stufe. Hierfür benötigt man für seinen Nameserver einen IPv6-Glue-Record. Dieser wäre notwendig, wenn Systeme, die kein Dual-Stack haben und nur noch IPv6 benutzen, eine Namensauflösung durchführen wollen. Das ist zwar heutzutage nun wirklich noch nicht relevant, gehört aber halt zu einer kompletten DNS-Konfiguration dazu. Meine Domain habe ich bei Hosteurope registriert, die dies nicht automatisiert eintragen können. Dort musste ich ein Ticket öffnen und um eine manuelle Eintragung bitten. Diese war dann auch schon nach kurzer Zeit erledigt und der letzte Test der Zertifizierung war bestanden.
Natürlich ist mit IPv6 nicht alles automatisch besser. Einige Baustellen bleiben schon. Da ist zum Beispiel die Zugriffs-Geschwindigkeit per Tunnel ein gutes Stück langsamer als per IPv4. Weiterhin gibt es wohl in der einen oder anderen Software doch noch einige Bugs. Unter PHP funktioniert beispielsweise die fopen()-Funktion nicht mehr, die in WordPress an einigen Stellen benötigt wird. Aber das kann mit der Zeit natürlich nur besser werden.
Viel Spaß an alle, die ihre Server auch per IPv6 erreichbar machen wollen.
Cisco IPv6 Feature Parity
Was es bei einigen Cisco Catalysten schon länger gibt, ist jetzt endlich auch bei der neuen Generation der Integrated Services Router (ISR-G2: 1900, 2900, 3900) angekommen:
