Datenhaufen zu IT und Elektronik.

Schlagwort: IPv6

FreeBSD und Netcup: Probleme mit IPv6 lösen

Als Kunden der bei netcup FreeBSD „rootserver“ auf KVM qemu Basis einsetzt, habe ich schnell gemerkt, dass meine IPv6 Verbindung nicht stabil ist.

Bild wie ein Dinosaurier ein Patchkabel durchbeißt, im Hintergrund ist das Buch IPv6 Workshop zu erkennen.

Dieses zeigt sich wie folgt:

– Direkt nach dem Boot scheinen IPv6 Verbindungen zu funktionieren, wie gewünscht.

– Nach einiger Zeit brechen die Verbindungen zusammen, sowohl Verbindungen vom System in die Welt als auch Verbindungen von der Welt ins System.

– Verbindungen scheinen „Startprobleme“ zu haben. Ein ping läuft erst ein paar Mal ins Leere und dann funktionieren alle Verbindungen plötzlich wieder für einen Moment.

Ein möglicher Workaround ist es, vom System aus einen ping auf die IPv6 Adresse des Gateways von netcup zu starten. Dieses sorgt in der Regel kurzzeitig für funktionsfähige IPv6 Verbindungen. Aber was ist das genaue Problem und wie könnte eine brauchbare Lösung aussehen?

Als Leser mit IPv6 Wissen, denkt man natürlich sofort a NDP das Neighbor Discovery Protocol und ja ich denke genau hier liegt das Problem. Dieses unterscheidet sich zur Implementation bei Linux etwas, daher funktioniert IPv6 im netcup Testsystem problemfrei unter FreeBSD, NetBSD usw. aber nicht. Die Probleme im NDP lassen sich auf dem System schnell wie folgt erkennen:

root@netcup-vps:~ # netstat -s -picmp6
icmp6:
    0 calls to icmp6_error
    0 errors not generated in response to an icmp6 message
    0 errors not generated because of rate limitation
    Output histogram:
        neighbor solicitation: 29
        neighbor advertisement: 10
        MLDv2 listener report: 8
    0 messages with bad code fields
    0 messages < minimum length
    0 bad checksums
    0 messages with bad length
    Input histogram:
        router advertisement: 17
        neighbor solicitation: 633
        neighbor advertisement: 25
    Histogram of error messages to be generated:
        0 no route
        0 administratively prohibited
        0 beyond scope
        0 address unreachable
        0 port unreachable
        0 packet too big
        0 time exceed transit
        0 time exceed reassembly
        0 erroneous header field
        0 unrecognized next header
        0 unrecognized option
        0 redirect
        0 unknown
    0 message responses generated
    0 messages with too many ND options
    0 messages with bad ND options
    423 bad neighbor solicitation messages
    0 bad neighbor advertisement messages
    0 bad router solicitation messages
    0 bad router advertisement messages
    0 bad redirect messages
    0 path MTU changes

Ich habe einige Zeit damit verbracht, mich mit dem Support darüber auszutauschen. Wie immer landet man zuerst in der human firewall, im Anschluss erreichte ich oft Supportmitarbeiter in Ausbildung eines IT Berufes. Zwischenzeitlich wurde mir das Problem von netcup dann auch bestätigt und mit dem Hinweis versehen, dass es an ihren Core-Routern liege, welche irgendwann ein Update bekommen sollen. Wann genau dieses Updates gemacht wird, konnte/wollte mir niemand bestätigen. Ebenfalls wurde versucht mein System auf verschiedene Hosts zu verschieben, von welchen andere Kunden wohl positives berichtet hatten. Dann sollte das Problem irgendwann behoben sein und netcup war erstaunt, dass es dieses noch nicht ist. Was auch immer… Aus meiner Sicht liegt das Problem an netcup.

Gelöst werden kann dadurch, dass man seinem BSD mitteilt, es soll bitte ND nach RFC4861 machen. Dieses ähnelt zumindest im Punkt der Bindung des jeweiligen ND ans Interface. Dafür kann man dieses als kurzen Test wie folgt aktivieren:

sysctl net.inet6.icmp6.nd6_onlink_ns_rfc4861=1

Stellt sich der gewünschte Erfolg ein, wird es mit dem passenden Eintrag in der /etc/sysctl.conf permanent aktiviert:

net.inet6.icmp6.nd6_onlink_ns_rfc4861=1

Dabei aber bitte beachten, dass FreeBSD dieses vor ca. 10 Jahren aus Sicherheitsgründen deaktiviert hat. https://www.freebsd.org/security/advisories/FreeBSD-SA-08:10.nd6.asc

Ich bin mit meinen Bemühungen aber leider nicht zu einer, für mich funktionierenden, Lösung von Seiten netcups gekommen. Daher blieb mir nur RFC4861.

Ich denke das Problem ist sicher schon lange beim Support bekannt, einfache google Suchen oder im netcup Forum zeigen dieses schnell auf. Dennoch vermittelte der Support mir erst das Gefühl, selbst etwas falsch konfiguriert zu haben, nur um mir dann den Eindruck zu vermitteln, dass sie noch nie von einem solchen Problem gehört haben. Ich vermute daher, dass ihr Setup aktuell einfach keine „einfache“ Lösung dieses Problems zulässt und sie daher so agieren. Was aber natürlich reine Spekulation ist, ich kann auch nur „vor“ das Setup schauen.

Fragen? Dann fragen…

IPv6 ULA (fd00::/8), fc00::/7 und warum die Priorität oft anders ist als erwartet

Pv6 Unique Local Address fd00::/8 vs IPv4 – Priorität, Prefix Policy und Default Address Selection

Unique Local IPv6 Addresses sind eines dieser Themen, über die man meist erst stolpert, wenn man IPv6 ernsthaft benutzt. Nicht beim ersten „IPv6 ist an“-Häkchen, sondern dann, wenn man anfängt, Netze sauber zu trennen, VPNs aufzubauen, interne Services umzuziehen oder einfach keine Lust mehr auf NAT und IPv4-Private hat.

ULA sollen genau das sein: lokal, eindeutig genug, nicht global routbar. Im Prinzip der IPv6-Nachfolger von 10/8 & Co. Klingt simpel. Ist es auch – bis man merkt, dass Betriebssysteme mit ULA manchmal Dinge tun, die man nicht intuitiv erwartet.

Fangen wir vorne an.

Der reservierte Adressraum für ULA ist fc00::/7. Das liest man oft so, und formal ist das auch korrekt. Praktisch relevant ist davon aber nur fd00::/8. Das sogenannte L-Bit (local) muss gesetzt sein. Der andere Teil, also fc00::/8, ist bis heute nicht weiter definiert und sollte in realen Netzen schlicht nicht verwendet werden. Wenn man ULA nutzt, dann immer fd….

Eine typische ULA sieht dann so aus:

fdXX:XXXX:XXXX::/48

Aufgeschlüsselt:

| 8 Bit | 40 Bit    | 16 Bit | 64 Bit        |
| fd    | Global ID | Subnet | Interface ID |
  • fd → Local-Bit gesetzt
  • Global ID → pseudozufällig, soll Kollisionen vermeiden
  • Subnet → klassische Subnetzstruktur
  • Interface ID → wie bei anderen IPv6-Unicast-Adressen

Die Global ID ist nicht „zentral vergeben“, sondern wird lokal generiert. Ziel ist nicht Sicherheit, sondern praktische Eindeutigkeit, falls Netze später zusammengeführt werden. In der Praxis funktioniert das erstaunlich gut.

Bis hierhin ist alles noch harmlos. Die eigentliche Verwirrung beginnt in dem Moment, in dem ein Host mehrere mögliche Wege zum Ziel hat.

Dual-Stack ist heute der Normalfall. IPv4 und IPv6 gleichzeitig. Und plötzlich steht ein System vor der Frage:
Nehme ich IPv4? Nehme ich IPv6? Und wenn IPv6 – welche Adresse eigentlich?

Die Antwort darauf regelt RFC 6724. Dort ist die Default Address Selection definiert. Vereinfacht gesagt: eine Prioritätenliste für Adresspräfixe. Jedes Präfix bekommt eine Präzedenz. Höher gewinnt.

Und genau hier liegt der Punkt, der viele überrascht:
IPv6 ULA haben nach RFC 6724 eine niedrigere Priorität als IPv4.

Das heißt ganz konkret:
Ist ein Ziel sowohl über IPv4 als auch über IPv6-ULA erreichbar, wird IPv4 bevorzugt.

Das fühlt sich erstmal kontraintuitiv an. IPv6 ist doch „das Neue“. Aber aus Sicht des Standards ist die Logik klar: ULA sind bewusst lokal begrenzt. IPv4 ist – trotz aller Altlasten – global eindeutig. Also gewinnt IPv4.

In der Praxis sieht man dieses Verhalten regelmäßig, vor allem auf Linux- und FreeBSD-Systemen, die sich sehr nah am RFC orientieren. Windows und Apple-Systeme mischen zusätzlich noch Happy-Eyeballs-Mechanismen hinein, was das Verhalten manchmal schwerer nachvollziehbar macht, am Grundprinzip aber nichts ändert.

Wenn man verstehen will, was ein System tatsächlich tut, hilft ein Blick in die jeweilige Prefix-Policy.

Diagnose: Welche Prioritäten nutzt mein System?

Linux:

ip -6 addr show
ip -6 route show
ip -f inet6 addrlabel show

Interessant ist vor allem die Ausgabe der Address-Labels. Dort sieht man, mit welcher Präzedenz fd00::/8, IPv4-Mapped-Adressen und andere Präfixe bewertet werden.

Windows:

netsh interface ipv6 show prefixpolicies

Hier sieht man sehr direkt, welche Präzedenz Windows den einzelnen Präfixen zuordnet. In der Default-Konfiguration liegt ULA unter IPv4.

FreeBSD:

ip6addrctl

Auch hier ist die RFC-6724-Policy gut sichtbar.

Spätestens an dieser Stelle wird klar, warum ein interner Dienst trotz sauber konfigurierter IPv6-ULA plötzlich doch über IPv4 angesprochen wird. Das System macht exakt das, was der Standard vorsieht.

Nun kann man sagen: „Okay, verstanden.“
Oder man kann sagen: „Das ist nicht das Verhalten, das ich will.“

Beides ist legitim.

Anpassung: ULA bewusst höher priorisieren

Wenn ULA für interne Kommunikation wichtiger sind als IPv4 – etwa in reinen IPv6-Infrastrukturen mit IPv4 nur als Fallback – kann man die Präzedenz anpassen.

Linux (/etc/gai.conf):

# IPv6 ULA höher priorisieren als IPv4
precedence fd00::/8  45

Nach einem Reload des Stacks oder Neustart gilt die neue Reihenfolge.

Windows:

netsh interface ipv6 set prefixpolicy fd00::/8 precedence=45 label=1

Damit liegt ULA über IPv4. Windows speichert diese Einstellung persistent.

FreeBSD:

Je nach Version über ip6addrctl oder entsprechende rc-Settings.

Wichtig: Das ist keine rein kosmetische Änderung. Man greift hier bewusst in die Adressauswahl ein. Das sollte man nur tun, wenn man das Netzdesign verstanden hat und weiß, warum man es will.

ULA sind kein Ersatz für Global Unicast Addresses. Sie sind auch kein Allheilmittel. Sie sind ein Werkzeug. Ein gutes – aber eben eines mit klar definiertem Scope.

Spannend ist, dass es inzwischen Entwürfe gibt, die das Verhalten von RFC 6724 weiterentwickeln. Ziel ist unter anderem, ULA-zu-ULA-Kommunikation besser zu priorisieren und bestimmte unerwünschte IPv4-Fallbacks zu vermeiden. Stand heute ist das aber noch nicht flächendeckend umgesetzt. Man sollte sich also nicht darauf verlassen, sondern das Verhalten der eigenen Systeme prüfen.

Am Ende bleibt:

ULA funktionieren. Sie sind sauber spezifiziert. Aber ihre Priorität ist kein Zufall, sondern eine bewusste Designentscheidung. Wer sie einsetzt, sollte wissen, warum IPv4 manchmal „gewinnt“ – und dann entscheiden, ob das so bleiben soll oder nicht.

Wie so oft bei IPv6 liegt das eigentliche Problem nicht im Protokoll, sondern in den Erwartungen, die man aus der IPv4-Welt mitbringt.

IPv6 ULA und das SyncThru Web Service von Samsung / HP mögen sich nicht…

Inzwischen ist es kaum noch etwas Besonders von seinem ISP mit einem echten globalen IPv6 /64 beworfen zu werden. Dualstack bietet fast jeder an. Die meisten Dienste im Internet sind ebenfalls so erreichbar und fast jeder in der IT hat zumindest schon mal von IPv6 gehört.

Nicht ganz so bekannt sind anscheinend bei IPv6 die ULAs die Unique Local Addresses RFC 4193. Es ist der Bereich fc00::/7 und im speziellen der Bereich fd00::/8 ist bei IPv6 vergleichbar mit den alten bekannten 10.0.0.0/8, 172.16.0.0/12 und natürlich 192.168.0.0/16. Wenn mal also sein internes Netzwerk für IPv6 Aufbaut benutzt man diese Adressen.

Auf der Arbeit beschäftigen wir uns auch mit diesem Thema. Wir haben uns ein /48 gewürfelt, geplant wie wir verschiedene /56 daraus auf die verschiedenen Standorte verteilen bis am Ende in den verschiedenen Netzten ein /64 per RA herauskommt. Stück für Stück verteilen wir im Moment die einzelnen Netze und so bekommen immer wieder neue Systeme zu ihrer IPv4 Adresse auch eine IPv6 Adresse. Immer mal wieder stößt man selbst 2018 dabei noch auf Überraschungen. Die eine oder andere werde ich in der nächsten Zeit mit euch teilen.

Starten möchte ich heute mit unserer Samsung Printstation X4300LX. Diesem Drucker wollten wir die im zugedachte IPv6 ULA fest einstellen. Leider beantwortete der Drucker diesen Versuch immer nur mit: Make sure your input is correct. This field only allows IPv6 address

Gehen wir erst einmal auf das Thema fest einstellen ein, bevor dazu die ersten Mails kommen 😀

Bei IPv6 sollte der Client selbst sich darum kümmern eine Adresse zu haben. Selbst im kleinsten „sinnvollen“ IPv6 Netz (/64) gibt es so viele Adressen, dass bekannte zentrale Möglichkeiten schnell gestresst sein könnten. Daher bekommt der Client per RA Router Advertisement einige der nötigen Informationen um sich selbst eine Adresse zu basteln. Im Zusammenspiel mit der eigenen MAC Adresse kommt dann eine IPv6 Adresse zustande. Sofern diese Adresse nicht schon einmal im Netzwerk vertreten ist (dieses prüft der Client selbst per NDP Neighbor Discovery Protocol) hat der Drucker damit immer die selbe Adresse. Warum also selbst eine feste IPv6 Adresse am Drucker vergeben? Nun ja, für die Zeit der Umstellung ist es etwas einfacher wenn die IPv6 Adressen für uns Menschen etwas übersichtlicher sind. Die eigentlichen Benutzer kommen an keiner Stelle mit den Adressen in Berührung, sie nutzen ausschließlich den DNS Namen. Für uns Admins ist es dennoch etwas einfacher wenn gewisse zentale Systeme schon für uns an der IPv6 Adresse erkennbar sind. Zumindest solange wir noch im Aufbau des gesamten ULA Netzwerkes bei uns sind. Später wird dieses natürlich anders sein.

Zurück zum Drucker! Die eingegebene IPv6 Adresse ist natürlich gültig und absolut korrekt. Also haben wir uns an unseren Servicepartner für den Drucker gewendet. Hier ist IPv6 noch nicht so „weit“. Aussage war das wir die Ersten sind welche sich zu diesem Thema jemals gemeldet haben. Unser Servicepartner hat sich selbst noch etwas schlau gemacht und ist dann direkt in Kontakt mit Samsung / HP getreten. Die erste Rückmeldung die wir bekommen haben ist: Wenn wir das fd00 zum Beginn weglassen, dann könnten wir eine Adresse eintragen. Sie könnten dieses an verschiedenen Drucker so nachstellen. Zusammen sind wir dann zum Schluss gekommen, dass einfach die Adressüberprüfung vom Samsung SyncThru Web Service einen Bug hat. Unser Servicepartner ist also wieder in Kontakt mit seinem Ansprechparnter bei Samsung / HP getreten. Von diesem kam einige Zeit später eine E-Mail welche uns weitergeleitet wurde. In dieser E-Mail wird uns erklärt das IPv6 Adressen eindeutig sein sollten und wie sich aus der MAC Adresse eine IPv6 Adresse berechnet. Was natürlich absolut korrekt ist, unser eigentliches Problem nur leider nicht betrifft oder löst. Wir haben also wieder mit unserem Servicepartner gesprochen welcher uns wenig Hoffnung machte. Wenn Samsung / HP meint keinen Fehler gemacht zu haben wird es schwer ihnen das Gegenteil zu beweisen. Wir könnten dem Drucker ja einfach per DHCPv6 eine Adresse reservieren….

Joar könnten wir…. Wir haben einen zentralen DHCPv4 und auch einen zentralen DHCPv6 Server. Verschiedene DHCP-Relay Server leiten die Anfragen aus verschiedenen Netzten an diesen weiter. Dieses funktioniert für IPv4 und IPv6 problemlos. Für IPv4 kümmert er sich zusätzlich um gewisse Reservierungen und die Adressvergabe. Bei IPv6 (hierzu ist im RA das Flag „other config“ gesetzt) holt er sich Dinge wie DNS, Timeserver, Searchdomains usw… Wir wollen aus beschriebenen Gründen keine Adressreservierungen per DHCPv6. Ausgewählte Systeme bekommen hier eine eindeutige und vorher definierte IPv6 Adresse und der Rest darf alleine rechnen. DHCPv6 fällt also raus. Für diese Druckstation werden wir also ersteinmal die selbstgerechnete Adresse benutzen bis wir es zusammen mit unserem Servicepartner geschafft haben Samsung / HP davon zu überzeugen das es einen Bug in ihrem SyncThru Web Service gibt.

Wenn also jemand einen guten Kontakt hat….. Wir können ja nicht die Einzigen sein welche versuchen ein ULA Netz aufzubauen, oder?

Samsung / HP sind nicht die Einzigen welche hier noch Probleme haben. Wir sind noch auf viele andere spannende Dinge gestoßen und wir werden sich noch auf einige kommen. Ausgewählte wird es hier wie angekündigt geben!

DNSSEC IPv6 DENIC und ein DNS in Japan

Ich brauche mal eure Hilfe…

Zum Spaß habe ich mir einen VPS Server in Japan geklickt. Was nun damit tun? Einfach mal ein weiteren DNS Server nutzen \o/ Gute Idee? Nein… Warum nicht? Weil der Server in Japan steht, höhere Antwortzeiten hat und der meist zufällig entscheidet, welcher DNS Server nun gefragt wird. Ich habe somit also sporadisch DEUTLICH langsamere DNS Antworten. Für meinen Spieltrieb aber gerade OK .-P

Ist also nun ein FreeBSD 10 mit einem Bind9.11 als slave für drei Spielzonen (kernel-error.org, kernel-error.com, kernel-error.de). FreeBSD ans Ende gepatcht, aktuellen Bind drauf, getestet ob die Kiste sauber signierte Zonen abfragen und prüfen kann (TCP/UDP und größer 512) alles gut. Dann als slave eingebunden wieder getestet und dann in die Zone darüber eintragen lassen. Die Zonen org. sowie com. haben den DNS-Server einfach gefressen. die Zone de. meckert aber! DNS timeout bei IPv6 O_o Öhm, ok… dig und drill sagen das geht aber. Bind ist auch fest ein und ausgehend an die IPv6 Adresse gebunden. Als „Firewall“ rennt PF, das mal deaktiviert ändert aber nichts. Vielleicht filter der Provider? Nope nur switch, iptables und ebtables öhm, das klingt sehr spartanisch.

Hat das Problem nur denic? Nö, DNSViz scheint es auch nicht zu können: http://dnsviz.net/d/kernel-error.com/dnssec/

Wie gesagt NUR bei IPv6! Jetzt habe ich mir alle Mühe gegeben diesen Timeout selbst mal zu produzieren, klappt aber nicht. Bei mir geht es einfach IMMER egal was für Optionen ich dig mitgebe.

# dig @2001:310:6000:f::1fc7:1 +edns +multi +norec +bufsize=4096 kernel-error.com IN MX +short
10 smtp.kernel-error.de.
# dig @2001:310:6000:f::1fc7:1 +tcp +edns +multi +norec +bufsize=4096 kernel-error.com IN MX +short
10 smtp.kernel-error.de.

Ich verstehe das nicht! Ich mache am bind keine Unterscheidung zwischen IPv4 und IPv6, für mich geht alles. Alle Antworten und Fragen in alle Richtungen laufen ohne jedes Problem. Nur DNSViz und denic scheinen ein „Problem“ zu haben. Mal sehen ob jemand von der denic mit einen sinnvollen Tipp geben kann. Mir würde ja schon der dig Aufruf reichen der zu einem timeout führt :-/ Dann hätte ich etwas zum Testen.

Oh ja, ich habe natürlich auch ganz brav mal tcpdump laufen lassen. Leider sieht es hier ebenfalls einfach funktionstüchtig aus 🙁

https://www.kernel-error.de/download/dns.tar.gz

Hat von euch irgendjemand eine Idee?


*U-P-D-A-T-E*

Die interne Fehlermeldung der API DENIC:

ERROR: 223 Timeout after switching from UDP to TCP – switch to TCP due to timeout (target) (ns3.kernel-error.com./2001:310:6000:f:0:0:1fc7:1:53)


*U-P-D-A-T-E*

Mal querry log eingeschaltet:

30-Jan-2017 18:30:04.669 client @0x802e62600 2a02:568:201:214::1:15#38145 (ns3.kernel-error.com): query: ns3.kernel-error.com IN A -E(0)DC (2001:310:6000:f::1fc7:1)
30-Jan-2017 18:30:04.670 client @0x802e62600 2a02:568:201:214::1:15#41589 (ns3.kernel-error.com): query: ns3.kernel-error.com IN AAAA -E(0)DC (2001:310:6000:f::1fc7:1)
30-Jan-2017 18:30:04.938 client @0x802e62600 2a02:568:201:214::1:15#20703 (kernel-error.de): query: kernel-error.de IN SOA - (2001:310:6000:f::1fc7:1)
30-Jan-2017 18:30:05.510 client @0x802e6f800 2a02:568:201:214::1:15#58465 (kernel-error.de): query: kernel-error.de IN NS -T (2001:310:6000:f::1fc7:1)
30-Jan-2017 18:30:05.889 client @0x802e62600 2a02:568:201:214::1:15#47548 (kernel-error.de): query: kernel-error.de IN SOA -E(0)D (2001:310:6000:f::1fc7:1)
30-Jan-2017 18:30:05.896 client @0x802e62600 2a02:568:201:214::1:15#55493 (kernel-error.de): query: kernel-error.de IN DNSKEY -E(0)D (2001:310:6000:f::1fc7:1)
30-Jan-2017 18:30:06.416 client @0x802e70c00 2a02:568:201:214::1:15#37170 (kernel-error.de): query: kernel-error.de IN DNSKEY -E(0)TD (2001:310:6000:f::1fc7:1)

*U-P-D-A-T-E*

Ich glaube es nicht… Ich teste hier gerade rum, will einem Kollegen zeigen das es nicht geht und das Update läuft bei DENIC einfach durch und OK Ö_ö ich verstehe das nicht, wirklich nicht. Absolut 0,0 warum geht das jetzt und warum meint DNSViz das es dennoch nicht geht? Was passiert hier?


*U-P-D-A-T-E*

Bleibt nur noch meine Vermutung, dass es wirklich um die Antwortzeit des Servers geht… Die liegt so zwischen 200 und 300ms. Das ist echt lange aber auch nicht SOOOOOOO lange :-/ Mal sehen ob von denic irgendwas kommt?!?!


*U-P-D-A-T-E*

Da fliegt mir doch gerade folgende Info rein:

die DENIC meinte dazu:

    unsere Kollegen können derzeit nicht genau sagen woran es hängt. Jedoch sind unsere Verbindungen nach Korea zeitweise leicht beeinträchtigt, evtl. wurde dir Nast Prüfung genau in dem Moment durchgeführt.


Es scheint als bekommen wir das nicht geklärt. Aber schön, wenn das
Update nun durch ist.

PS: Ein leicht ungutes Gefühl bleibt ...

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑