IPv6 Probleme mit routing [gelöst]

[Lolek]

Hi Folks,

ich setze mich gerade mit IPv6 auseinander und habe gleich die ersten Probleme. Ich bin gerade dabei mir einen Router für IPv6 aufzubauen.

Ich habe von meinem Internetprovider einen IP Präfix xxxx:xxxx:xxxx::/48 zugewiesen bekommen. Der Provider sagt ich könnte das erste /64 des Präfixes verwenden, wenn ich weitere Netze adressieren will muß ich einen eigenen Router verwenden.

Also habe ich ein debian installiert und eth0 mit xxxx:xxxx:xxxx:0000::8/64 und dem Gateway xxxx:xxxx:xxxx:0000::1 konfiguriert. Laut Aussage meines Providers, wird an die xxxx:xxxx:xxxx:0000::8 der gesamte Traffic der an den Präfix xxxx:xxxx:xxxx::/48 adressiert ist geroutet.

Auf eth1 habe ich die Adresse xxxx:xxxx:xxxx:1::1/64 vergeben und konfiguriere mit radvd die clients.

Soweit funktioniert alles. Ein Client im Netzwerk bekommt eine IPv6 Adresse zugewiesen und ich kann beide Interfaces des Routers anpingen. Sende ich einen Ping an die xxxx:xxxx:xxxx:0000::1 (Gateway des Providers) geht der request über den Router (mit tcpdump beobachtet) raus aber ich bekomme keine Antwort. Es schaut aus, als würde das Gateway vom Provider den Rückweg nicht kennen.

Muß ich über eth0 mit NDP bekanntgeben das ich ein Router bin

Danke für alle Antworten.

[hec_tech]

Hast du in der sysctl forward für ipv6 aktiviert?

Ich verwende radvd habe aber eine ähnliche Konfiguration. Sollte also so wie du es konfiguriert hast funktionieren. Eventuell irgendwo ein Tippfehler?

Eventuell hat dein Provider irgenwo ein Problem.

lg
Gregor

[Lolek]

Hallo hec_tech,

danke für die Antwort.

Jo! Routing ist aktiviert. Ich kann auch mit tcpdump beobachten wie der icmp request über das Interface geht. Es kommt aber keine Antwort vom Gateway.

[wanne]

Sicher, dass xxxx:xxxx:xxxx::1 das GW ist? Normalerweise sollte der korrekter Weise xxxx:xxxx:xxxx:: nehmen. Sonst ist autokonfiguration spoofing deutlich einfacher.

Hast du mal ausprobiert, was passiert, wenn du dir vom Provider dein GW zuweisen lässt? Ganz oft ist das GW auch fe80:: oder fe80::1.

Würde erstmal den ganzen foo mit eth1 und so weglassen und erstmal gucken, dass das Debian richtung eth0 ins Internet kommt.

Sonst zur sicherheit immer das:
ip -6 r
ip -6 a
# ip6tables -S; ip6tables -t nat -S

[Lolek]

Hallo Wanne,

danke für die Antwort.

Das ist ja das verrückte. Vom Router aus komme ich ja ins Netz. Ich kann ohne Probleme ipv6.google.com pingen.
ip6tables ist nicht aktiviert. Ich habe auf eine Firewall verzichtet, weil ich mir auf dem Testrouter keine unnötigen Eier legen wollte. Wenn es funktioniert wird er eh platt gemacht.

[wanne]

Der nächste test auf dem Debian-Rechner müsste der sein:

Code: Alles auswählen

ip a a xxxx:xxxx:xxxx:2::1/64 dev eth0
ping6 -I xxxx:xxxx:xxxx:2::1 debianforum.de

Und ich wäre immernoch stark daran interessiert:

Code: Alles auswählen

ip -6 r
ip -6 a

Und guck dir da nochmal sauber an, ob du da wirklich nichts bekommst:

Code: Alles auswählen

ip6tables -S; ip6tables -t nat -S

Gibt leider verdammt viel, dass dann doch irgend wo was einfügt.

[Lolek]

Jo, danke nochmal für die Tipps.

Bei ip6tables gibt es keine Tabelle nat. Es gibt ja auch kein NAT wie bei ipv4.
Die anderen Sachen werd ich Montag mal testen. Ich kann übers Wochenende nicht an den Rechner. Ich melde mich dann Montag hier.

schönes WE

[wanne]

Bei ip6tables gibt es keine Tabelle nat. Es gibt ja auch kein NAT wie bei ipv4.

Man kann das dazupatchen. Ist aber glaube ich nur mit modifiziertem Kernel möglich.
Aber du hast natürlich recht.

[catdog2]

Bei ip6tables gibt es keine Tabelle nat. Es gibt ja auch kein NAT wie bei ipv4.

Doch gibt es seit Linux 3.7

[hec_tech]

NAT und IPv6 klingt sehr nach einem Feature für Masochisten.

Da bekommt man endlich diese Notlösung NAT weg und dann will das jemand wieder haben.

Probier mal ohne radvd zu arbeiten und alles statisch zu konfigieren. Eventuell funktioniert das besser. Mit Debian müsste ich das mal testen habe bisher IPv6 nur auf dem PfSense Cluster im Einsatz und da funktioniert es perfekt mit der identen Konfiguration also erstes /64 als Transportnetz.

Nur mal so eine Frage ist der Gateway deines Providers überhaupt pingbar? Nicht jedes GW antwortet auf ping.

Kannst du andere Adressen pingen? Probier mal 2a04:d3c0:3:161::1

lg
Gregor

[wanne]

NAT und IPv6 klingt sehr nach einem Feature für Masochisten.

Schon aber jetzt nicht mehr als ping abzustellen

Problem ist, dass du halt erstmal dumm guckst, wenn dir dein Provider eine einzelne IP oder ein dynamisches /64 per Autokonfiguration mit unkonfigurierbarem Zwangsrouter gibt. Und dann nehmen die meisten halt wieder NAT. Weil das hat schon immer Funktioniert um Providergängelung zu umgehen.
Und sowas ist halt gerade in Deutschland bei weitem der Normalfall und nicht die Ausnahme.

Um das mal an den Kommunistenwitz anzulehen:
Es gibt zwar Milliarden mal mehr IPs als Sandkörner in der Wüste, aber Kapitalismus schafft es auch das zu dem Unbezahlbaren Gut, dass sich nur die reichsten leisten können zu verknappen.

[catdog2]

Problem ist, dass du halt erstmal dumm guckst, wenn dir dein Provider eine einzelne IP oder ein dynamisches /64 per Autokonfiguration mit unkonfigurierbarem Zwangsrouter gibt. Und dann nehmen die meisten halt wieder NAT. Weil das hat schon immer Funktioniert um Providergängelung zu umgehen.
Und sowas ist halt gerade in Deutschland bei weitem der Normalfall und nicht die Ausnahme.

Ja sowas kann passieren.
Außerdem umfasst NAT eine ganze Reihe von Techniken, die irgendwas mit dem umschreiben von IP Adressen zu tun haben und nicht nur dieses hochproblematische SNAT/Masquerading. Port forwading z.B. kann auch bei IPv6 hin und wieder hilfreich sein. Außerdem kann man da man bei IPv6 zumindest meistens genügend Adressen zur Verfügung hat ein 1zu1 Mapping durchführen, ohne irgendwelches Port gebastel also ohne das Ende zu Ende Prinzip zerstören zu müssen. Es sollte halt nicht mehr die Regel sein, dass man das benutzt aber es gibt eben noch durchaus Anwendungsfälle. Klar ist NAT immer ein etwas unschöner hack aber nicht in jedem Szenario hat es üble Konsequenzen.

[hec_tech]

Je nach Größe des Kunden weisen wir zwische /48er oder /56er zu. Wir haben von RIPE ein /29er IPv6 bekommen. Damit sollten wir mal etwas auskommen.

Wir machen aber nur Cloud Services bzw Hosting. Ich möchte gar nicht wissen was andere Provider so von RIPE bekommen haben.
Mir kommt es vor dass der gleiche Fehler wie damals bei der IPv4 gerade passiert. Zwar gibt es ausreichend Blöcke aber der kleineste Block den man sinnvoll verwenden kann ist nun mal ein /64.
Bei IPv6 sind die Routing Tables schon ein riesen Problem und wenn die Provider bei IPv6 anfangen komplett geistesgestört zu fragmentieren dann gute nacht.

Aber lassen wir das und schaun wir mal ob wir das Problem lösen können.

Kannst du den GW deines Providers vom Router aus pingen?

[catdog2]

Je nach Größe des Kunden weisen wir zwische /48er oder /56er zu. Wir haben von RIPE ein /29er IPv6 bekommen. Damit sollten wir mal etwas auskommen.

Das sind 134217728 /56 oder 524288 /48, so viele Kunden muss man erst mal haben.

Wir machen aber nur Cloud Services bzw Hosting. Ich möchte gar nicht wissen was andere Provider so von RIPE bekommen haben.

Vermutlich mehr aber z.B. mit einem /24 kann man schon so viele (praktisch sogar mehr) /56er vergeben wie es auf der Welt v4 Adressen gibt. Die Deutsche Telekom die sicherlich zu den größeren zählen dürfte hat ein /19, man kann also aus dem aktuell verwendeten Global Unicast /3 65536 Provider dieser Größe bedienen. Sollte das wieder erwarten wirklich nicht reichen hat man immer noch eine Hand voll /3 um es nochmal zu versuchen.

Bei IPv6 sind die Routing Tables schon ein riesen Problem und wenn die Provider bei IPv6 anfangen komplett geistesgestört zu fragmentieren dann gute nacht.

Naja das sollten sie ja eigentlich nicht tun müssen weil sie jedem ein mal genug geben können und genug Platz da ist um hierarchisches routing ordentlich umzusetzen. Wenn sie das trotzdem nicht auf die Reihe kriegen sind sie selber Schuld. Die Routerhersteller freuen sich sicher.

Zwar gibt es ausreichend Blöcke aber der kleineste Block den man sinnvoll verwenden kann ist nun mal ein /64.

Wieso? SLAAC ist nur eine Möglichkeit Adressen zuzuweisen und nicht Zwangsläufig immer die sinnvollste. Auf der anderen Seite ist es nur im Fall doofer ISP wirklich notwendig was kleineres zu nutzen. Ok man muss zwar theoretisch etwas aufpassen: https://tools.ietf.org/html/rfc5375#appendix-B.2

[Lolek]

Hallo Leuts,

sehr interessant Diskussion die sich hier entfaltet hat. Ich sehe schon, jeder der mit Netzwerk zutun hat, hat ähnliche Gedanken und Probleme

Von meinem Testrouter aus kann ich das Gateway vom Provider pingen. Ich komme auch zu ipv6.google.com. Für mich sieht es so aus, als würden vom Providergateway keine Pakete auf meine Routeradresse geroutet. Ich habe mit dem Service vom Provider telefoniert, der hat einen Traceroute auf eine Adresse hinter meinem Gateway gestartet. Da kahm als letzer Hop das Gateway vom Provider.

Für meine Begriffe hätte ja als letzter Hop mein Router antworten müssen. Bei einem Ping auf meine interne Adresse konnte ich mit tcpdump auch keine ICMP Pakete an der Schnittstelle sehen.

Ich will am Montag nochmal einen Rechner auf die andere Seite des Routers stellen und sehen ob der Router funktioniert.

[wanne]

Zwar gibt es ausreichend Blöcke aber der kleineste Block den man sinnvoll verwenden kann ist nun mal ein /64.
Bei IPv6 sind die Routing Tables schon ein riesen Problem und wenn die Provider bei IPv6 anfangen komplett geistesgestört zu fragmentieren dann gute nacht.

? Größere Blöcke bedeutet kleinere Routing Tabellen. Deswegen ja auch die Mindestgröße von /56. Die Überbordenden IPv4 Routingtabellen waren ja der ursprüngliche Grund für die Entwicklung von IPv6.

Deswegen gibt's mit IPv6 eben keine probleme mit riesen Routing Tabellen:
http://bgp.potaroo.net/v6/as2.0/
http://www.cidr-report.org/cgi-bin/plot ... &with=step

Die Tabellen für IPv4 sind über 20 mal so groß. Und das ganze bei einem viel Größeren Wachstum: Das ist seit 2012 relativ konstant 10 mal so groß wie bei IPv6.
Und wenn da irgend ein Provider Intern nicht zurecht kommt, dann macht er was falsch.

[Lolek]

Hallo zusammen,

wie angedroht habe ich heute etwas weiter an dem Problem geforscht. Ich habe mir eine Testumgebung geschaffen wie in der Grafik illustriert.

Ich habe einen ping von Testrechner 1 zu Testrechner 2 über Testgateway 1 abgesetzt. Das hat funktioniert. Ein Ping von Testrechner 2 zu Testrechner 1 war ebenfalls erfolgreich. Ein Ping von Testrechner 2 zum Provider Gateway ging ins Leere. Auf Testrechner 1 ist als defaultgateway die ****:****:****::8 konfiguriert.
Ich kann von Testrechner 1 ipv6.google.com erreichen. Ebenso lässt sich der Nameserver mit der IP 2003:40:4000::53 ohne Probleme erreichen. Ein Traceroute von Testrechner 1 zeigt folgendes Ergebnis.

Wie Ihr seht, geht die Route über Testgateway 1 (****:****:****::8) und dann über das Provider Gateway (****:****:****::1). Aus dem ersten /64 ist die Verbindung problemlos möglich.
Versuche ich die gleichen Ziele von Testrechner 2 zu erreichen, endet Traceroute am Testgateway1.

Da die Kommunikation zwischen Testrechner 1 und Testrechner 2 problemlos funktioniert, gehe ich davon aus, daß das Provider Gateway den „Rückweg“ in das Netz hinter dem Router nicht kennt. Ich habe für dieses Verhalten keine andere Erklärung, als das vom Provider Gateway nicht das ganze /48 an die ****:****:****::8 geroutet wird.

Was sagt Ihr dazu

[wanne]

Bevor das untergeht:

Der nächste test auf dem Debian-Rechner müsste der sein:

Code: Alles auswählen

ip a a xxxx:xxxx:xxxx:2::1/64 dev eth0
ping6 -I xxxx:xxxx:xxxx:2::1 debianforum.de

Und ich wäre immernoch stark daran interessiert:

Code: Alles auswählen

ip -6 r
ip -6 a

PS: Welcher Provider macht korrektes IPv6?

[Lolek]

Hallo Wanne,

die Liste mit den Routen bekommst du Morgen. Hab ich heute total verdrängt... man ist ja nicht mehr der Jüngste Die Tests mit dem ping hab ich doch schon gemacht, zwar nicht mit -I... -I steht für Interface?

Also ich kann Google von Testrechner 1 und von Testgateway 1 erreichen. Von Testrechner 2 endet der Trace am Testgateway.

[wanne]

-I steht für Interface?

Ja. Man kann aber (laut manpage) auch Source-Adressen abgeben.
Außerdem ist jetzt morgen

[Lolek]

Moin Wanne,

den ping Test habe ich gemacht.

Code: Alles auswählen

ip a a xxxx:xxxx:xxxx:2::1/64 dev eth0
ping6 -I xxxx:xxxx:xxxx:2::1 debianforum.de

Hat nicht funktioniert; ging ins Leere.

Die Ausgabe von

Code: Alles auswählen

ip -6 r
ip -6 a

ist hier.

[wanne]

ist hier.

Ich nehme mal an, das Netz xxxx:xxxx:xxxx:1::1/64 ist in Wirklichkeit xxxx:xxxx:xxxx:1000::1.
Sonst sieht das erst mal gut aus.
Aber könntest du Text statt Bilder posten? Und wenn dann wenigstens hier hochladen.

Hat nicht funktioniert; ging ins Leere.

Klingt irgend wie massiv danach als ob da was beim Provider nicht stimmt. (Oder eben
/proc/sys/net/ipv6/conf/all/forwarding
auf 0 steht.

(Guck auch mal bei
/proc/sys/net/ipv6/conf/eht1/forwarding))

[Lolek]

Hallo Wanne,

in der Datei /proc/sys/net/ipv6/conf/all/forwarding steht eine 1 drin. Das Routing zwischen Testrechner 1 an eth0 und Testrechner 2 an eth1 funktioniert ja auch.

Ich denke auch, daß der Fehler am Provider Gateway zu suchen ist. Da du die gleiche Meinung hast, gehe ich davon aus, daß wir Recht haben.

Ich hab den Provider schon angeschrieben. Ich habe aber noch keine Antwort. Mal sehen was rauskommt.

[Lolek]

Hallo Leute,

das Problem ist gelöst. Der Internetprovider hatte auf seinem Router ein falsches Gateway eingetragen.

Danke für alle Beiträge.