Ich denke Du wirst nicht um IPv6 Tests, bzw. IPv6 VPN Tests rum kommen aber selbst dann ist es IMHO unwahrscheinlich, dass Deine Meldung bei den richtigen Mitarbeitern der DG ankommt. Wuerde mich freuen, wenn Du Dich nach Wechsel zu VF hier noch mal mit neuen Traces melden wuerdest... vielleicht weckt so ei Post ja Neugierde bei der DG Technik wenn denn VF das Problem nicht aufweist.
Beiträge von pufferueberlauf
-
-
Oder Du trennst Modem vom Router und Router vom AP, und SIP-Basis vom Router, dann kannst Du auf jeder Position jeweils optimieren... (aber in der Summe wird das eher teurer als ein All-in-one und duerfte wohl auch mehr Strom verbrauchen). Die Herausforderung bei diesem Ansatz ist, dass es reine Modems nur noch selten gibt, und wenn sind das meist Router die sich Dumm-stellen koennen
(Ich habe z.B. eine FB7520 als bridged-DSL Modem laufen, die musste ich erst ueberzeugen sich dumm zu stellen, und das ging auch nur gut, weil die 7520 unter OpenWrt mit DSL betrieben werden kann, und damit lassen sich Interface schnell bridgen.)
-
Bei wechselndem Präfix wird eh neu nummeriert, was für einen Unterschied macht es da, wenn der Interface-Identifier dann sich auch ändert?
Easy, ich meine ich hatte das bereits erwaehnt, ich moechte nicht alle 224 Stunden meine Firewallregeln anpassen, und schon gleich gar nicht will Gruetze wie UPNP/PCP auf meiner Firewall aktivieren.
Discovery läuft eh über mDNS, DynDNS o. ä. und mit zufällig abbrechenden Sessions muss jeder Dienst für Privatkunden sowieso klar kommen.
Ja, aber das ist nicht mein Problem.
Mit Zero Trust networking macht niemand "Löcher in die Firewall". Und wer noch ein anderes Modell als Zero Trust hat, hat eh viel größere Probleme.
Mei, Dein Netz, Deine Regeln, mein Netz meine Regeln... Ich gehe nicht davon aus, dass mein Heimnetz ein sicherer Ort ist und aktiviere bei allen System die individuellen Firewalls, dennoch betreibe ich auch eine Firewall im Internetgateway... Zwiebelprinzip und so. Musst Du weder gut finden noch nachvollziehen koennen...
-
Was passiert wenn Du auf das blaue "Ändern" hinter der 1000/500 Anzeige klickst?
-
Ach ja, auch wenn es bisher kein RFC geworden ist, Ubuntu/Linux unterstuetzt das natuerlich:
Ubuntu Manpage: ip-token - tokenized interface identifier support
-
Jain, bei IPv4 ist NAT44 die Regel nicht die Ausnahme, d.h. die Firewall-Freigabe fuer interner Server-IPs und Ports bleibt unberuehrt von IP-Renumbering... Klar dynamisches DNS funktioniert sowohl bei IPv4 als auch bei IPv6, aber dann muss man jedesmal nach Prefixchange die IPv6 Freigabe fuer die Server GUA anpassen* und das ist IMHO Gruetze. Die "Loesung" die F. Gont da vorschwebt ist PCP also dem Server erlauben selber neue Loecher in die Firewall zu machen, aber IMHO ist PCP (und UPNP) eine schlechte Idee fuer IPv4 oder IPv6...
*) OpenWrt kann Freigaben anhand der IID festlegen, so dass das Prefix ignoriert wird und solche Freigaben daher Renumbering einfach ueberleben.
-
Das sehe ich nicht so. Ich unterstelle der IETF keine (durch welche Zielvorstellungen auch immer begründete) Agenda, mit der sie "Nutzer umerziehen" will. Schon gar nicht die Idee, ULA am CPE-Router via NPTv6 (RFC6296, falls du das mit "NET66" gemeint hast) auf GUA zu übersetzen. Btw.: Die Bedeutung des mir bisher unbekannten Begriffs "Bike-Shedding" musste ich erst mal nachlesen, danke für das Schließen dieser meiner Bildungslücke.
Oh, ich lese die IPv6 discussions listen der IETF (zumindest einige) Nutzer umerziehen ist da sehr wohl ein Bestreben zumindest von einigen (unter anderem dem Autor von RFC7217), manchmal aus guten Gruenden, manchmal aus weniger guten Gruenden.
Na ja, ich meint den Austausch des Prefixes per NAT, fuer mich ist das ein Spezialfall von generellem NAPT. Und nein diese Form von NAT66 ist nichts was die IETF sehen moechte, IMHO ist das eine Konsequenz daraus, dass die IETF seit Jahren einige (ihr selbst) offensichtliche IPv6 Probleme nicht ordentlich geloest hat (Hotfail zwischen verschiedenen IPv6 Uplinks, bei denen die IPv6 Routen eines ploetzlich verschwundenen Links noch lange in den Endpunkten aktiv bleiben und genutzt werden was zu Konnektibvitaetsproblemen fuehrt, NAT66 ist da eine echte Loesung wenn auch weder elegant noch im Geiste von IPv6).
Es sollen nur temporäre IPv6-Adressen (IPv6 privacy extensions) gemäß RFC8981 verwendet werden, weil das Gerät keine Services anbietet, also ausschließlich als Client genutzt wird. Eine permanente/stable IPv6-Adresse wird nicht benötigt. Zielgruppe: Vor allem mobile, drahtlose Endgeräte, die sich zu wechselnden WLANs verbinden.
Jai, eine ULA waere schon schoen da stimmen wir ueber ein... aber hier geht es um ULAs?
Man möchte ausschließlich oder zusätzlich zu temporären Adressen auch permanente/stable IPv6-Adressen verwenden (muss einstellbar sein), weil das Endgerät auch (bzw. hauptsächlich) Services anbietet. Hier sollte man dann wählen können, welche Methode zu ihrer Generierung zum Einsatz kommen soll: Man sollte die moderne Methode gemäß RFC7217 wählen können (Zielgruppe: Server in IPv6-Netz mit festem IPv6-Präfix) oder auch weiterhin auf die Ur-Methode "Modified EUI-64" (Anhang A in RFC4291) zurückgreifen können (Zielgruppe: Server in IPv6-Netz mit wechselndem ISP-Präfix).
Auch hier Jain...ich bin da mehr ein ein Fan von https://datatracker.ietf.org/doc/id/draft-c…ntifiers-02.txt RFC7217 und Modified EUI-64 sind IMHO beide fuer Heimnetze nicht gut geeignet.
ZitatDie Motivation, Serverdienste in SOHO-Netzen an ISP-Privatanschlüssen möglichst zu unterbinden, liegt eher bei den ISP. Denn die möchten dafür gerne ihre deutlich höherpreisigen Business-Tarife mit festem IPv6-Präfix verkaufen.
Das werfe ich der IETF auch gar nicht vor, deren Ziel ist da echte end2end Kommunikation, also natuerlich auch das Anbieten von Diensten/Servern.
Schließlich noch zu "lokal mit stabilen ULAs arbeiten": Das nutze ich zusätzlich in meinem LAN seit eh und je, ist doch sehr sinnvoll, sich für die rein LAN-interne Kommunikation wenigsten darauf verlassen zu können, wenn der ISP mal wieder den GUA-Präfix wechselt oder ggf. auch mal gar keinen liefert (das soll bei DG ja ab und zu mal vorkommen).
+1
-
-
Ich war wohl zu subtil und vorsichtig, ich bin kein Fan von RFC7217 weil ich nicht glaube, dass es richtige Problem loest...
Zitatsince temporary addresses [RFC4941] do not eliminate the use of fixed identifiers for server-like functions, they only partially mitigate host-tracking and activity correlation across networks
Das ist fuer den Fall um den es hier geht ein "stabiles" Netz mit haeufig wechselndem Prefix halt nicht die richtige Loesung... die Grundannahme ist, wenn das Prefix wechselt, wechselt das Netz und das macht in Heimnetzen halt fuer Serverdienste nur wenig Sinn.
Was die IETF damit foerdert ist dass Endnutzer GUAs ignorieren, lokal mit stabilen ULAs arbeiten und diese dann mit NET66 mit dem jeweils aktivem Prefix versehen... Aber gerade bei den IPv6 RFC sehe schon mal Bike-Shedding und Versuche Nutzer umzuerziehen.
-
In der GUI kann man nur die ganze IPv6 Adresse manipulieren. Ob das Praefix beim Renumbering automatisch angepasst wird habe ich nicht ausprobiert, der Rest meiner Familie ist kein Fan von vermeidbaren Netzwerkunterbrechungen waehrend des WEs
Persoenlich bin ich kein Fan von RFC7217 zumindest nicht im Kontext von Heimnetzwerken mit haeufigem Prefix-Wechsel, aber vielleicht ist mir nur nicht klar welches Bedrohungsmodell dem RFC zugrunde liegt.
-
Unter macos (gestestet mit 15.5) kann man die IPv6 auch manuell setzen, dann verschwinden allerdings die privacy extension Adressen sofort, und ich habe nicht getestet was bei einem Praefix-Wechsel passiert.
-
Ich wuerde ja naiverweise erwarten, dass ein ISP so etwas in seiner Schnittstellenbeschreibung dokumentieren muesste... aber ich vermute, die BNetzA duerfte das anders sehen...
-
Der Arm A9 ist ein erstaunlich gutes Design... ja, "nur" 32bit aber ziemlich punchy und oft besser als der 64bit A53. Der typische Unterschied zwischen der Performance (Out-of-order A9) und der Efficiency Kategorie (in-order A53) von Arm Kernen halt...
Wuerde niemandem empfehlen heute noch eine Omnia zu kaufen (zumindest nicht vor der Einfuehrung des neuen Models)
Mal als Beispiel wie gut sich der A9 gegen den A53 schlaegt: (Quelle hier
Turris Omnia
(CZ11NIC13, 2016)Marvell Armada 385
(Dual Core ARMv7 A9, 1.6 GHz)23.05.4 371 Mbps OpenWrt One Mediatek MT7981BA
(Dual Core A53, 1.3 GHz)24.10.0 372 Mbps -
Also der SFP-Kaefig der Omnia unterstuetzt bis zu 2.5 Gbps... aber nicht mit jedem Modul...
Schau mal hier:
Supported SFP modules [Turris wiki]
ZitatSFP⚓︎
All of those, which fulfill the SFP standard, work on 100Mbps / 1Gbps / 2.5Gbps / SGMII. Some others work, too, despite not fulfilling the standard, if supported and worked by the Linux kernel.
We manufacture our own Turris SFP+ Copper module (RJ45) supported under Turris OS.
-
Du solltest in der Lage sein den SFP Port einfach mit einem der LAN ports zu bridgen... dann dient die Omnia letztlich nur ein fancy Medienkonverter
-
Ansonsten habe ich noch einen Turris Omnia (openwrt) mit sfp port hier rumfliegen...evtl werde ich diesen als dediziertes dmz/modem gerät verwenden, bin mir aber nicht sicher ob ich mit der ARM CPU 1Gb ausreizen kann.....
'Haengt davon ab was Du machen moechtest... SQM mit bidirektionalem Traffic ist beim Omnia bei ca. 500 Mbps am Ende, aber normales Routing/firewalling sollte bis ca. 1 Gbps skalieren.
-
Hier kannst du dir ein unabhängiges Bild über die Leistungen der Provider machen: https://www.connect.de/vergleich/fest…st-3206265.html
Zur Qualitaet des Connect Tests habe ich einige Bemerkungen gemacht:
Und zur Frage wie man der Peering/Uebergabe-Qualitaet eines ISPs auf den Zahn fuehlen kann hier:
Tl;dr: Der Zweck des Connect Test ist IMHO hauptsaechlich, dass Connect auf Basis nominell objektiver Kriterien Gewinner praesentieren kann; man sollte sich die Kriterien genau ansehen bevor man die Gewinner der Connect fraglos als "beste ISPs" akzeptiert.
-
Als Telefonica/O2 Kunde kann ich sagen, dass ich da keinen groesseren Sinn drin sehe alle 24h die PPoE Verbindung zu beenden*. Aber als "normaler" Endkunde bereitet es mir auch keine groesseren Schmerzen. Und ganz ehrlich, die Schritte die ich jetzt unternehme (z.B. MOSH per symbolischer DDNS Adresse statt SSH mit numerischer IP Adresse, sowie screen statt directem video terminal) muesste ich auch gehen, wenn die erzwungenen Reconnects z.B. alle 180 Tage kaemen... Die "richtige" Loesung waere eine fixe IP Adresse, aber da stehen fuer mich Kosten und Nutzen in keinem attraktivem Verhaeltnis.
*) Ehrlicherweise gibt es im O2 Netz groessere (von Emdkunden reportierte) Probleme, wobei O2 bisher auch komplizierte Probleme geloest hat, hat zwar jeweils Monate gedauert, aber geloest wurden die.
-
Man muss fairerweise auch sagen, das dieses Urteil noch nicht rechtskräftig ist. Es wird vor dem BGH erneut verhandelt und von daher kann hier keine zuverlässige Auskunft getroffen werden, ob die MVLZ mit Anschlussaktivierung oder Auftragsbestätigung beginnt.
In der Tat ist das noch unklar. Aber was mir relativ klar erscheint ist, dass ein "Vorvertrag" nicht ewig binden kann, die offene Frage ist da wie lange? Ich bin nicht sicher ob es zu dieser Frage schon Verfahren gibt. Allerdings duerfte das ein transientes Problem sein, wenn der FTTH Massenausbau mal durch ist, erwarte ich, dass Terminierung fuer Nachzuegler schneller und vor allem zuverlaessiger wird funktionieren. Wenn ich unterschreibe "Ausbau in 3 Jahren", und der kommt in 3 Jahren sehe ich da weniger Probleme als beim Status Quo "Ausbau wenn wir dazu kommen, aber der Vorvertrag bindet bis zum juengsten Gericht, ausser wir sagen den Ausbau von unserer Seite ab"
-
Jeder hat da so seine Meinung. Ich stimme Dir wohl zu, dass die Unternehmens-Politik des vorsaetzlichen Unterpeerings der Telekom ganz klar ein G'schmaeckle hat und meide daher die Telekom als ISP. Allerdings ist die Telekom in meinen Augen ansonsten ein kompetenter ISP mit passablen Produkten.
Also:
Kontra:
- vorsaetzliches Unterpeering
Pro:
- echten DualStack
- >>24 Stunden Zwangstrennung
- Unterstuetzung der Endgeraetefreiheit
Ja, ist inzwischen Vorgabe fuer alle ISP, aber die T hat sich da bewegt bevor sie musste und macht das recht kundenfreundlich - relativ viele lokale Uebergaben (aber halt nicht ueberall hin)
Wuerde ich die Telekom als ISP empfehlen? Nein, aber ich wuerde da immer differenzieren warum und nicht alles ueber einen Kamm scheren.
