Das Problem ist, solche Wikis auch nur annähernd aktuell zu halten. Wenn man keinen professionellen Maintainer dafür hat, hat sich das Thema nach einigen Monaten erledigt. Ich hab das leider schon zwei mal in Nutzerforen mitgemacht.
Beiträge von frank_m
-
-
Es geht um einen Server? Dann mach es doch einfach im SCP unter Medien -> Festplatte löschen.
-
aber vielleicht hat der ein oder andere mal mit dem Gedanken gespielt QUIC bzw. HTTP/3 auszuprobieren
Hab ich.
Aber leider sind die Einsatzmöglichkeiten momentan noch sehr eingeschränkt. Eigentlich kann man nur HTTP/3 und Chrome verwenden. Das ist nur so Semi-interessant.
Trotzdem danke für die Anleitung! Vielleicht mach ich doch mal einen Container damit.
-
-
Ansonsten hab ich bei meiner DDNS-Domain auch die TTL auf 300 runtergeschraubt, klappt einwandfrei.
Ist das eine eigene Domain? Oder erlauben es die netcup DNS Einstellungen auch, für einzelne Sub-Domains andere TTLs zu verwenden?
Hintergrund: Ich überlege, einige dyndns Einträge auf meine bei netcup regsitrierte Domain zu ziehen (mit ownDynDns). Ich stelle mir das in etwa so vor:
domain.com mit ttl 86400 für alle "normalen" Einträge und das Webhosting
dyn.domain.com: sub Domain für die dynamischen hosts mit TTL 300
host1.dyn.domain.com
host2.dyn.domain.com
...
Voraussetzung: dyn.domain.com hat eine andere TTL, als domain.com.
-
Das interessante ist: Der 2. Hop "2a00:11c0:47:3::32" ist bei mir der gleiche, wie bei dir (ein Anexia Router). Aber bei mir geht es dann weiter, direkt zu einem weiteren Anexia Hop, der nur 0,2 ms länger brauch, also quasi direkt daneben steht
Kühner Verdacht: Da findet ein Anexia Router den Rückweg in dein Subnetz nicht.
-
Die Frage ist ja, warum funktionieren einige Seiten und andere nicht? Wie weit kommen denn die Traceroutes auf z.B. Heise oder Google?
-
Der VPS ist nur an das von Netcup zugewiesene IPv4 und IPv6 Netzwerk angeschlossen.
Gut. Ich dachte, dass möglicherweise ein HE Tunnel auf dem Server terminiert. Dann hätte man ggf. besondere Maßnahmen im Routing ergreifen müssen.
Verwirrt war ich, weil ich in meinem Netzwerk tatsächlich einen HE-Tunnel habe. Die Tests oben wurden aber direkt auf einer ssh Konsole (putty) am VPS durchgeführt. Der dazu verwendete Rechner hat nur IPv4. Kann also keinen Einfluss auf die Konfiguration am VPS haben.
Ja, das sehe ich auch so.
-
Das heißt, es funktioniert immer noch nicht? Ich habe keine vergleichbaren Probleme.
Was ist mit den HE.net Geschichten? Gibt es da was?
-
Das meiste was ich da sehe ist völlig normal, auch das FAILED bei ip -6 neigh. Das einzige, was auf einem Fehler hindeutet, ist, dass du schreibst, du kannst gewisse Seiten nicht erreichen.
Ich sehe he.net in deinen Angaben. Nutzt du den Tunnel von denen? Geht da beim Routing was schief?
-
Mich würde der technische Hintergrund interessieren. Einfach aus Neugier.
Damit ist Ausgangsrichtung (an fe80::1%vtnet0) ungleich der Eingangsrichtung (zu meiner IP).
Das stimmt soweit, die Pakete in Ausgangsrichtung gehen an eine andere MAC-Adresse, als die ankommenden Pakete als Absender MAC haben. Die Frage ist, warum BSD ein Problem damit hat. Macht die Firewall auch auf Schicht 2 eine Art Connection Tracking?
-
Um das deutlich zu sagen: Ich habe absolut gar nichts gegen den Anwendungsfall von MeisterYoda. Seit 2008 mache ich schon genau solche Dinge mit vServern. Ich war früh mein erster eigener IPv6 Tunnelbroker. Damals hab ich schon geflucht über das einzelne /64, dass man üblicherweise dazu bekam - wenn überhaupt.
Auch öffentliche IPv4 Adressen von vServern für 6tunnel oder ähnliches zu nutzen, ist absolut legitim (für letzteres reicht allerdings locker ein /64). Oder als VPN Gegenstelle, die man an Hotspots oder in anderen öffentlichen Netzen nutzen kann - inkl. Adblocker etc. Alles gut, und alles Dinge, in denen man eine Lösung für das einzelnen /64 braucht, das man nur hat. Von daher kann ich MeisterYoda verstehen: ich leide ja auch darunter.
Wir sind halt nur unterschiedlicher Auffassung über die Auslegung der Standards. Mir ist auch klar, dass die nicht kurzfristig geändert werden und man eine andere Lösung braucht. Das ist dann im Zweifel ein Tunnel von HE oder vergleichbar, oder eben ein zusätzliches /64 Netz beim jeweiligen Hoster.
Man darf netcup hier aber sehr wohl den Finger dafür in die Wunde legen, dass hier keine Rücksicht auf das architectuelle Design von IPv6 Rücksicht genommen wird und man entgegen der Empfehungen von z.B. rfc6177 und der Registries agiert.
Da hingegen bin ich nach wie vor anderer Meinung. Die RFC6177 empfiehlt ein /48 für End-Sites, aber nicht für einzelne Nodes. Im Sinne der RFC4949 (Glossary) ist eine End-Site das Rechenzentrum und ein Node ein VPS oder vergleichbares. Ich kann hier beim besten Willen keinen Verstoß gegen die Empfehlungen feststellen.
-
Fehlt vielleicht der Punkt am Ende von blablubb.cv51ofwsnxxc7z4v.myfritz.net? Das passiert mir nämlich jedes mal ...
-
An welcher Stelle könnte ein Reverse DNS denn aufgerufen werden?
Reverse DNS war ja nur ein Beispiel. Hab da halt immer mal wieder Überraschungen erlebt, auch im Umfeld IPv6, im Zusammenhang mit Domain Names usw. Fehlende Domainnames in Containern zum Beispiel können Kommunikation schon mal ausbremsen.
Kann ich irgendwie schauen, ob es daran liegt?
Vielleicht in einem Paketmitschnitt mit tcpdump/Wireshark.
-
Nein. Eine Site ist im allgemeinen ein Kunde an einem Standort.
Laut rfc4949 (Glossary) ist eine Site:
CodeA facility -- i.e., a physical space, room, or building together with its physical, personnel, administrative, and other safeguards -- in which system functions are performed.Hört sich für mich eher nach Rechenzentrum denn nach Kunde an.
Ein Server kann durch Virtualisierung / Container / VPNs etc. und sonstige Dienste deutlich mehr, als ein Client-Rechner zuhause im /64ger LAN, der braucht tatsächlich nicht mehr.
Hat er ja. Ein /64 Netz anstatt eine /128 Adresse. Oder sogar mehrere /64 Netze bei Bedarf.
Aber wie schwer ist es eigentlich zu verstehen, dass IPv6 nicht für einzelne /64ger Netze designed ist?
Gar nicht, ich hab das verstanden. Aber wie schwer ist es zu verstehen, dass genau das das Problem ist?
Und das es nur aufgrund der Einschränkungen eines verhältnismäßig winzigen Teils der Technologie (SLAAC), während ein Großteil der IPv6 Suite auch heute schon anders arbeiten könnte? Zumal SLAAC ja ursprünglich mal für kleine und ressourcenmäßig eingeschränkte Geräte und private Nutzung vorgesehen war, während für die Adressvergabe im professionellen Umfeld eher DHCPv6 angedacht war. Das hat sich in der Praxis allerdings sehr aufgeweicht, zugegeben.
Dies gilt allerdings nicht für professionelle Server, dort sollte im Allgemeinen weiterhin ein /48 das Maß der Dinge sein (bzw. pro Kunde, der dann das am Besten flexibel an seine gebuchten Server verteilen kann).
Ein /48 pro Server halte ich für übertrieben. Und als ein Kunde mit mehreren Servern hast du ja auch mehrere /64 Netze.
Wir sind ja gar so weit auseinander. Wir haben beide das Problem, mit dem einen /64 Netz im Grund nicht zufriedenstellend arbeiten zu können. Nur die über die Gründe dafür sind wir unterschiedlicher Auffassung.
-
Hast du denn irgendeinen Anhaltspunkt dafür, dass deine Probleme auf Paketverluste zurückzuführen sind? Vielleicht sind es auch nur Prozesse, auf die gewartet wird? Reverse DNS Lookups sind typsiche Kandidaten dafür.
-
Dort ist übrigens nur von "Home-Sites", sprich klassischen Endkunden von ISPs die Rede
Eben. Dort ist die Konstellation eine andere mit mehreren Endgeräten und ggf. auch mehreren Netzen (Gastnetz etc.). Außerdem ist dort immer von "sites" die Rede, also nicht von einzelnen Servern, sondern vom Standort, in diesem Fall also wohl dem Rechenzentrum.
Ein Server ist erst mal nur ein Endgerät, der nicht nur eine Adresse, sondern direkt ein ganzes /64 Netz bekommt. Für evtl. Container oder VMs kannst du ein oder mehrere weitere /64 Netze bekommen. Wo siehst du da jetzt einen Widerspruch zu deinen Zitaten? Dazu kommt folgendes: Es gibt in Standards obligatorische Vorschriften ("shall") und Empfehlungen ("should"). Letztere kann man machen, muss man aber nicht. Welchen Typs deine Zitate sind, ist ja offensichtlich.
-
Wenn du öfter in der Situation bist ist, ist der Grund genau der selbe, dass du beim falschen Provider unterwegs bist.
Das sind leider viele.
Die RFCs sind wenn man so will die globalen Gesetze für die technische Realisierung von IT-Lösungen.
Ich weiß, was Standards sind und wie sie funktionieren. Ich bin selber in diversen Standardisierungsgremien aktiv unterwegs, u.a. ISO und CEN.
Ich erwarte auch nicht, dass man da jetzt was dran ändert. Aber da ist man damals schon bequem gewesen.
Deine Vorschläge sind von daher in diesem Forum etwas fehl am Platz, wenn sie auch berechtigt sein mögen, aber das ist einfach das falsche Forum.
Das mir das hier nicht weiterhilft, ist mir klar. Dennoch kann man ja offen darüber diskutieren, was schief gelaufen ist, damit man es beim nächsten Mal besser macht.
Einfach an die RFCs halten und gut ist.
Genau das tun ja alle. Du kannst ja nicht sagen, dass sich das Angebot und die Umsetzung von netcup nicht an die RFC hält. Und es führt genau dazu, dass man in eine Sackgasse läuft, aus der man als Endanwender einen Ausweg suchen muss, der technisch dann oft eine Krücke ist.
-
Macht auch generell keinen Sinn, du hast mir bisher noch nie erklärt, was dich konkret an 64 bit SLAAC stört.
Mich stört daran genau das, was dich jetzt gerade stört. Du kannst mit dem einen /64 Netz, welches dir zur Verfügung steht, nichts anfangen. Mit mehr Flexibilität bei den Host-IDs könntest du dein Vorhaben direkt umsetzen. In der Situation war ich schon öfter, und es nervt jedes Mal, zu schauen, wo man jetzt mehr Netze herbekommt. Da müssen tausend Randbedingungen stimmen, entweder beim Anbieter oder ein Tunnel oder was auch immer. Anstatt einfach nur ein wenig mehr Hinrschmalz ins SLAAC zu stecken und damit den Adresspool nutzbar zu machen, den man bekommt.
-
Ja aber damit rüttelst du an den Grundmanifesten von IPv6, die kann man nicht mehr ändern. Außerdem wer sagt, dass die 128 bit in Stein gemeißelt sind?
Eine rückwärtskompatible Erweiterung ist ein Problem für dich, aber die Länge der Adresse ist diskutabel? Die Einstellung ist bemerkenswert.
So oder so, es spielt keine Rolle, wie es ist, ist es irgendwo auch sinnvoll.
Die funktionierenden Lösungen würden ja auch weiterhin funktionieren. Kein Grund, irgendwas zu ändern. Es würde einfach nur die Möglichkeiten deutlich erweitern - da wo es Sinn macht. Und in der Situation war ich schon öfter. So wie du heute.
Die Frage ist auch: Warum hat man nur bei SLAAC darauf verzichtet, aber bei DHCPv6 z.B. nicht? Das ist inkonsequent. Wie gesagt, EUI-64 kann es nicht sei, mit EUI-48 stände eine Alternative zur Verfügung, für kürzere Host-IDs hätte man einfach eine Lösung finden können.
Jetzt müsste man nur noch das Konzept richtig umsetzen
Gemäß deiner Vorgaben ist das Konzept ja richtig umgesetzt. Es verstößt in keinster Weise gegen die von dir genannten Regeln. Nur kannst du damit nichts anfangen, weil du an die Grenzen des Systems stößt. Wer hat jetzt Schuld? Das System oder der Anbieter?
