• Kunden aus Hessen und Nordrhein-Westfalen können über die Rufnummer 0221 / 466 191 00 Hilfe bei allen Problemen in Anspruch nehmen.
    Kunden aus Baden-Württemberg können über die Rufnummer 0711 / 54 888 150 Hilfe bei allen Problemen in Anspruch nehmen.

Unitymedia Kleiner IPv6-Workshop

Diskutiere Kleiner IPv6-Workshop im Internet und Telefon über das TV-Kabelnetz Forum im Bereich Internet und Telefon; HI Hab tatsächlich den HD pvr mit HDMU drauf. Hab mir das Thema auf dem Board angeschaut,scheint wirklich kein großes Interesse da gewesen zu sein...
  • Kleiner IPv6-Workshop Beitrag #26
hab da den Topfield mit e2 bin mir da nicht sicher ob ich den Zugriff übers Netz hin bekomme.
Den Topfield 77x0 HD PVR? :)

Als Zweitreceiver habe ich den auch. Nachdem das AAF-Image nicht mehr weiterentwickelt wird, habe ich auf das HDMU-Image umgestellt.
Das HDMU-Image ist für IPv6 derzeit nicht geeignet, es sind aber nur zwei Änderungen in der Konfiguration nötig ...

Siehe zu diesem Thema auch

Um es ganz kurz zusammen zu fassen:
Der Topfield würde - mit einem entsprechenden Image - mit IPv6 laufen. Daran, daß HDMU ein geeignetes Image baut, arbeite ich gerade. Aber es wäre natürlich toll, wenn Du Dich in dieser Hinsicht auch mal im HDMU-Forum äußern könntest, damit die Devs merken, daß wirklich ein Bedarf da ist.

HI
Hab tatsächlich den HD pvr mit HDMU drauf.
Hab mir das Thema auf dem Board angeschaut,scheint wirklich kein großes Interesse da gewesen zu sein aber dem hast du ja Wind eingehaucht ich hoffe das ihr da voran kommt.
Wäre sehr an ein Image interessiert wenn es dann eins gibt wäre ich gerne bereit das dann zu testen :naughty:
Hast nicht zufällig auch eine Nas von synology zu Hause. :smile:

Gruß Bibatop
 
  • Kleiner IPv6-Workshop Beitrag #27
Den Topfield 77x0 HD PVR? :)
Der Topfield würde - mit einem entsprechenden Image - mit IPv6 laufen. Daran, daß HDMU ein geeignetes Image baut, arbeite ich gerade. Aber es wäre natürlich toll, wenn Du Dich in dieser Hinsicht auch mal im HDMU-Forum äußern könntest, damit die Devs merken, daß wirklich ein Bedarf da ist.
aber dem hast du ja Wind eingehaucht ich hoffe das ihr da voran kommt.
Ich habe inzwischen ein IPv6-fähiges Image auf dem Topf.
Es geht eigentlich alles:
  • WebInterface (HDMU/Dream) über haproxy auf dem Topf
  • OpenWebif über haproxy auf dem Topf
  • Zugriff auf vorgenannte zwei auch vom Android-Handy aus mit DreamDroid!
  • o*c*m-Web-Interface (nativ)
  • o*c*m-Kekstausch über c***am-Protokoll (Mit o*c*m nativ, mit der Gegenseite (Original c***am) über haproxy)
  • telnet
  • ssh

Also keine einzige Einschränkung, eher sogar noch ein Vorteil ggü. dem alten IPv4:
Ich kann beide Receiver im Haus mit denselben Einstellungen im Heimnetz und von außen erreichen, da jeder Receiver seine eigene Adresse hat und alles auf den Standardports arbeiten kann. Bei IPv4 mußten für den Zugriff von außen Ports "verbogen" werden, wenn man beide von außen erreichen wollte.

Beispiel:
Statt
  • das Web-Interface des Topf
    • von außerhalb über <IPv4-DynDns-für's-ganze-Heimnetz>:17080,
    • lokal aber über 192.168.178.31:80
    und
  • das Web-Interface der Ultimo
    • von außerhalb über <IPv4-DynDns-für's-ganze-Heimnetz>:16080,
    • lokal aber über 192.168.178.30:80
anfrickeln zu müssen, geht das jetzt viel einfacher:
  • Web-Interface des Topf: <Topf-IPv6-DynDns>:80
  • Web-Interface der Ultimo: <Ultimo-IPv6-DynDns>:80
unabhängig davon, ob ich von zuhause oder von unterwegs drauf zugreifen will!

Also so, wie TCP/IP eigentlich immer schon gedacht war.

Hast nicht zufällig auch eine Nas von synology zu Hause. :smile:
Die sollten eigentlich IPv6 können:


Man kann so eine Synology NAS sogar benutzen, um darüber IPv6 überhaupt erst im Heimnetz zur Verfügung zu stellen, z.B. bei einem Bekannten mit Router ohne Unterstützung für einen SixXS-Tunnel!
 
  • Kleiner IPv6-Workshop Beitrag #28
Hallo,

erstmal vielen Dank für die zusammengetragenen Infos hier. Ich hätte da mal eine Frage die zu dem IPv6 Thema passt:
Ist es innerhalb des Unitymedia Netzes möglich zwei FB 6360 per VPN zu verbinden (beide Anschlüsse laufen über IPv6).

Grüße
 
  • Kleiner IPv6-Workshop Beitrag #29
erstmal vielen Dank für die zusammengetragenen Infos hier. Ich hätte da mal eine Frage die zu dem IPv6 Thema passt:
Ist es innerhalb des Unitymedia Netzes möglich zwei FB 6360 per VPN zu verbinden (beide Anschlüsse laufen über IPv6).
Nein.
Das AVM-VPN ist nicht IPv6-tauglich.

Mit OpenVPN sollte es gehen. Auf eine Fritz!Box kriegt man das aber nur durch Freetzen, also fallen die Kabel-Boxen dafür aus.
 
  • Kleiner IPv6-Workshop Beitrag #30
....
 
  • Kleiner IPv6-Workshop Beitrag #31
Hallo,

vielen Dank für die schöne Erklärung zum Thema IPv6! Nun habe ich vieles verstanden und auch einige Lücken schließen können, die sogar beim IPv4 Verständnis noch offen waren :zwinker:

Allerdings habe ich noch etwas vermisst: was macht man mit VPN? An vielen Stellen habe ich gelesen, dass das nicht mehr funktionieren sollte, stimmt das so? Gibt es Lösungen dafür, wie man es doch einrichten könnte? Geplant wäre die folgende Konfiguration:
Synology DS / Computer per OpenVPN mit den VPN-Servern eines Anbieters verbinden, der z.Z. noch keine IPv6 Unterstützung bietet.

Außerdem hätte ich noch eine Verständnisfrage, was die Sicherheit angeht. Ist IPv6 nicht ein wenig unsicherer? Weil so hatte man ja vom Provider meist eine immer wechselnde IP bezogen. Nun ist diese fest und sogar noch an die MAC Adresse des jeweiligen Gerätes gebunden. Ist das nicht sogar als nachteilig anzusehen?
 
  • Kleiner IPv6-Workshop Beitrag #32
vielen Dank für die schöne Erklärung zum Thema IPv6! Nun habe ich vieles verstanden und auch einige Lücken schließen können, die sogar beim IPv4 Verständnis noch offen waren :zwinker:
Freut mich, daß es was gebracht hat :)
Allerdings habe ich noch etwas vermisst: was macht man mit VPN? An vielen Stellen habe ich gelesen, dass das nicht mehr funktionieren sollte, stimmt das so? Gibt es Lösungen dafür, wie man es doch einrichten könnte? Geplant wäre die folgende Konfiguration:
Synology DS / Computer per OpenVPN mit den VPN-Servern eines Anbieters verbinden, der z.Z. noch keine IPv6 Unterstützung bietet.
Prinzipiell ist VPN auch nur irgendein Dienst wie alle anderen auch, somit kann man auch nichts Generelles dazu sagen, ob das geht oder nicht geht.

Auf IPSec basierende VPNs, wie z.B. das in der Fritz!Box eingebaute, gehen - wenn man es pauschal sagen will - nicht, die erwarten zwei IPv4-Tunnelendpunkte und transportieren auch keine IPv6-Payload (Payload= Das, was innerhalb des VPNs übertragen wird), es sei denn, es wären 6in4-Pakete, was logisch ist, da das ja eigentlich technisch betrachtet doch IPv4-Pakete sind.

Wenn der bzw. die Clients NAT-Traversal (Frei übersetzt: Durchquerung von Netzwerkadress-Übersetzungen) unterstützen, dann kann man allerdings auch ein solches VPN am CGN-Anschluß zum Laufen bringen, Beispiele von an IPv4-CGN-Anschlüssen laufenden VPNs gab es auch schon im Forum.
Ich habe auch ehrlich gesagt noch nicht verifizieren können, ob das AVM-VPN wirklich nicht geht, wenn eine der Seiten noch eine öffentliche IPv4 und dementsprechend auch nur eine Seite nur IPv4 mit CGN hat. Es versuchen ja durchaus beide Seiten, das VPN aufrecht zu halten, wie man gut daran sehen kann, daß der Aufbau auch dann gelingt, wenn man mal auf der einen und mal auf der anderen die DynDNS-Aktualisierung versaubeutelt.
Ich würde sogar die Behauptung wagen, daß es geht, immerhin kann ich von meinem Smartphone aus auch im Mobilfunknetz eine VPN-Verbindung zur Fritz!Box aufbauen und im Mobilfunk hat man ja i.d.R. auch nur IPv4-CGN.

OpenVPN unterstützt IPv6 sowohl als Trägernetz als auch als Payload, natürlich nur, sofern das auch die beiden Endpunkte unterstützen.

Genaueres kann man wirklich nur sagen, wenn man wüßte, welchen VPN-Client mit welchen Einstellungen und in welcher Version Du auf der NAS benutzen würdest/müßtest und wie der VPN-Server eingerichtet ist. Ein IPv6-tauglicher Anbieter wäre allerdings vorzuziehen. Da auch die Anbieter immer schlechter an IPv4-Adressen kommen, ist das auch kein Problem, einen solchen zu finden.
Außerdem hätte ich noch eine Verständnisfrage, was die Sicherheit angeht. Ist IPv6 nicht ein wenig unsicherer? Weil so hatte man ja vom Provider meist eine immer wechselnde IP bezogen. Nun ist diese fest und sogar noch an die MAC Adresse des jeweiligen Gerätes gebunden. Ist das nicht sogar als nachteilig anzusehen?
Meine Meinung hierzu habe ich schon erläutert, übrigens indirekt bereits in der "Rückschau" auf IPv4 in diesem Workshop:
NAT und dynamische IPs sind zuallererst und vorrangig Workaround-Mechanismen, um vorübergehend mit der Adressknappheit von IPv4 besser zurecht zu kommen. Sich an diese Einschränkungen zu gewöhnen, immerhin gab es die vom Start des privaten Internets an, ist die eine Sache. Da einen Sicherheitsmechanismus hinein zu interpretieren die andere und schon sehr gewagt. Ich sehe da absolut kein Problem mit. Die Gegenseite im Internet könnte jetzt, wenn Du keine Zufallskennung sondern EUI64 (Also Deine auf 64 Bit erweiterte MAC) verwendest, den Rückschluß ziehen, daß Du eine Netzwerkkarte von Marvell, Intel, 3com, Realtek, o.ä. verwendest. So wie Millionen anderer Menschen auch.
 
  • Kleiner IPv6-Workshop Beitrag #33
Vielen Dank für die ausführliche Erklärung!
Auf IPSec basierende VPNs, wie z.B. das in der Fritz!Box eingebaute, gehen - wenn man es pauschal sagen will - nicht, die erwarten zwei IPv4-Tunnelendpunkte und transportieren auch keine IPv6-Payload (Payload= Das, was innerhalb des VPNs übertragen wird), es sei denn, es wären 6in4-Pakete, was logisch ist, da das ja eigentlich technisch betrachtet doch IPv4-Pakete sind.

Wenn der bzw. die Clients NAT-Traversal (Frei übersetzt: Durchquerung von Netzwerkadress-Übersetzungen) unterstützen, dann kann man allerdings auch ein solches VPN am CGN-Anschluß zum Laufen bringen, Beispiele von an IPv4-CGN-Anschlüssen laufenden VPNs gab es auch schon im Forum.
Ich habe auch ehrlich gesagt noch nicht verifizieren können, ob das AVM-VPN wirklich nicht geht, wenn eine der Seiten noch eine öffentliche IPv4 und dementsprechend auch nur eine Seite nur IPv4 mit CGN hat. Es versuchen ja durchaus beide Seiten, das VPN aufrecht zu halten, wie man gut daran sehen kann, daß der Aufbau auch dann gelingt, wenn man mal auf der einen und mal auf der anderen die DynDNS-Aktualisierung versaubeutelt.
Ich würde sogar die Behauptung wagen, daß es geht, immerhin kann ich von meinem Smartphone aus auch im Mobilfunknetz eine VPN-Verbindung zur Fritz!Box aufbauen und im Mobilfunk hat man ja i.d.R. auch nur IPv4-CGN.

OpenVPN unterstützt IPv6 sowohl als Trägernetz als auch als Payload, natürlich nur, sofern das auch die beiden Endpunkte unterstützen.

Genaueres kann man wirklich nur sagen, wenn man wüßte, welchen VPN-Client mit welchen Einstellungen und in welcher Version Du auf der NAS benutzen würdest/müßtest und wie der VPN-Server eingerichtet ist. Ein IPv6-tauglicher Anbieter wäre allerdings vorzuziehen. Da auch die Anbieter immer schlechter an IPv4-Adressen kommen, ist das auch kein Problem, einen solchen zu finden.

Hmm, ich habe ein wenig gegoogelt und herausgefunden, dass Synology wohl die Version 2.1.4 verwendet. Ist wahrscheinlich komplett untauglich um auch nur auszuprobieren, ob DS-Lite zu IPv4 eine Verbindung aufbauen kann, richtig? Dann bliebe es ja nur zu hoffen, dass die beim nächsten FW Update auch OpenVPN aktualisieren. So würde ja wenigstens die Hoffnung bestehen, dass es evtl. möglich sein würde vom DS-Lite den IPv4 VPN Anbieter zu erreichen?

Ist im Moment halt so, dass ich erst vor kurzem einen VPN Anbieter gefunden habe, der voll und ganz meinen Vorstellungen entspricht und nun müsste ich auf diesen verzichten, weil er kein IPv6 unterstützt :traurig:
Meine Meinung hierzu habe ich schon erläutert, übrigens indirekt bereits in der "Rückschau" auf IPv4 in diesem Workshop:
NAT und dynamische IPs sind zuallererst und vorrangig Workaround-Mechanismen, um vorübergehend mit der Adressknappheit von IPv4 besser zurecht zu kommen. Sich an diese Einschränkungen zu gewöhnen, immerhin gab es die vom Start des privaten Internets an, ist die eine Sache. Da einen Sicherheitsmechanismus hinein zu interpretieren die andere und schon sehr gewagt. Ich sehe da absolut kein Problem mit. Die Gegenseite im Internet könnte jetzt, wenn Du keine Zufallskennung sondern EUI64 (Also Deine auf 64 Bit erweiterte MAC) verwendest, den Rückschluß ziehen, daß Du eine Netzwerkkarte von Marvell, Intel, 3com, Realtek, o.ä. verwendest. So wie Millionen anderer Menschen auch.
Ah gut, soweit habe ich jetzt nicht gedacht. Das heißt ja wiederum, dass auch in diesem Fall nur der Provider weiß, unter welcher realen Adresse die IP(v6) so und so zu finden ist, richtig?
 
  • Kleiner IPv6-Workshop Beitrag #34
[VPN]Hmm, ich habe ein wenig gegoogelt und herausgefunden, dass Synology wohl die Version 2.1.4 verwendet. Ist wahrscheinlich komplett untauglich um auch nur auszuprobieren, ob DS-Lite zu IPv4 eine Verbindung aufbauen kann, richtig? Dann bliebe es ja nur zu hoffen, dass die beim nächsten FW Update auch OpenVPN aktualisieren. So würde ja wenigstens die Hoffnung bestehen, dass es evtl. möglich sein würde vom DS-Lite den IPv4 VPN Anbieter zu erreichen?

Ist im Moment halt so, dass ich erst vor kurzem einen VPN Anbieter gefunden habe, der voll und ganz meinen Vorstellungen entspricht und nun müsste ich auf diesen verzichten, weil er kein IPv6 unterstützt :traurig:
Nun, um zu einer IPv4-Gegenseite eine Verbindung aufzubauen reicht die Version so oder so. Die Frage ist nur, ob die Verbindung über das CGN auch aufrecht bleibt.

Ich habe das heute noch am Smartphone gehabt: Mit dem "VPNC" konnte ich eine VPN-Verbindung zur Fritz!Box aufbauen, die brach aber nach wenigen Minuten auch wieder zusammen, mit VpnCilla hält sie bzw. wird aufrecht erhalten.
Die Verbindung vom Smartphone aus ist vergleichbar mit der von einem DS-lite-Anschluß aus (zu einem IPv4-Host): Auch im Mobilfunk hat man nur CGN und keine öffentliche IPv4. Ebenfalls ändert sich die IPv4 alle paar Minuten.

Es käme also schon auf einen Versuch an, wobei ich nach wie vor einen Anbieter mit IPv6 vorziehen würde.

Ich sehe da absolut kein Problem mit. Die Gegenseite im Internet könnte jetzt, wenn Du keine Zufallskennung sondern EUI64 (Also Deine auf 64 Bit erweiterte MAC) verwendest, den Rückschluß ziehen, daß Du eine Netzwerkkarte von Marvell, Intel, 3com, Realtek, o.ä. verwendest. So wie Millionen anderer Menschen auch.
Ah gut, soweit habe ich jetzt nicht gedacht. Das heißt ja wiederum, dass auch in diesem Fall nur der Provider weiß, unter welcher realen Adresse die IP(v6) so und so zu finden ist, richtig?
An der Zuordnung von einer IP zu einer Person ändert sich nichts:
Jeder, den sie nichts angeht, kann sie rausfinden - Dorfpolizist, Abmahnanwalt, NSA, BND, Verfassungsschutz ...
Da tun sich IPv4 und IPv6 gar nichts.

Was sich ändert:
Der Verfassungsschutz kann jetzt auch rausfinden, von welchem der beschlagnahmten Rechner der Facebook-Eintrag "Die Stimmung ist mal wieder am Anschlag, gleich lassen wir die Bombe platzen und stellen unseren Stargast vor! Das wird vor allem die Laune bei den weiblichen Gästen zum explodieren bringen!" kam ;)

Meines Erachtens ist diese ganze Diskussion um dynamische Präfixe für den "Datenschutz" eine reine Nebelkerze.
 
  • Kleiner IPv6-Workshop Beitrag #35
Nun, um zu einer IPv4-Gegenseite eine Verbindung aufzubauen reicht die Version so oder so. Die Frage ist nur, ob die Verbindung über das CGN auch aufrecht bleibt.

Ich habe das heute noch am Smartphone gehabt: Mit dem "VPNC" konnte ich eine VPN-Verbindung zur Fritz!Box aufbauen, die brach aber nach wenigen Minuten auch wieder zusammen, mit VpnCilla hält sie bzw. wird aufrecht erhalten.
Die Verbindung vom Smartphone aus ist vergleichbar mit der von einem DS-lite-Anschluß aus (zu einem IPv4-Host): Auch im Mobilfunk hat man nur CGN und keine öffentliche IPv4. Ebenfalls ändert sich die IPv4 alle paar Minuten.

Es käme also schon auf einen Versuch an, wobei ich nach wie vor einen Anbieter mit IPv6 vorziehen würde.
Ok, lasse mir das ganze nochmal durch den Kopf gehen. Vielen Dank aber schon mal für die Erklärungen!
An der Zuordnung von einer IP zu einer Person ändert sich nichts:
Jeder, den sie nichts angeht, kann sie rausfinden - Dorfpolizist, Abmahnanwalt, NSA, BND, Verfassungsschutz ...
Da tun sich IPv4 und IPv6 gar nichts.

Was sich ändert:
Der Verfassungsschutz kann jetzt auch rausfinden, von welchem der beschlagnahmten Rechner der Facebook-Eintrag "Die Stimmung ist mal wieder am Anschlag, gleich lassen wir die Bombe platzen und stellen unseren Stargast vor! Das wird vor allem die Laune bei den weiblichen Gästen zum explodieren bringen!" kam ;)

Meines Erachtens ist diese ganze Diskussion um dynamische Präfixe für den "Datenschutz" eine reine Nebelkerze.
Jep, jetzt habe ich es eingesehen, danke!
 
  • Kleiner IPv6-Workshop Beitrag #36
Hallo.

Ersteinmal vielen Dank für den tollen Workshop!!!!! Hat sicherlich sehr viel Mühe gemacht...
Ein kleine Anregung/ Wunsch habe ich noch, könntest Du auch einmal die DS-Lite "Technik" bzw. dieses Verfahren erläutern?

So ganz wird es für mich daher noch nicht rund... Ich will auf UM wechseln und überlege, ob ich ich auch mit IP6/DSlite glücklich werden kann - oder ich wirklich IP4* benötige. (* ich würde dann auf die 100 MBit ausweichen, hier kann man wohl noch IP4 mit 1play auf Wunsch bekommen.)

Vielleicht darf ich kurz skizzieren, was ich wirklich brauche bzw. was ich vorhabe. Hinter dem Kabelmodem/ UM-Router direkt meine FB7270, daran die LAN- und WLAN-Clients. An meiner FB hängt mein ISDN und es sind zwei VoIP-Anbieter (personal-voip.de, gmx.de) eingerichtet. Schön wäre darüber hinaus der Zugriff auf die FB-Weboberfläche von aussen.

Nun zu meiner Frage, kann ich dies mit IP6/DSlite umsetzen? (Die FB zu Freezen wäre für mich okay.)


Vielen Dank!
mic.kan
 
  • Kleiner IPv6-Workshop Beitrag #37
Es geht eigentlich alles:
  • WebInterface (HDMU/Dream) über haproxy auf dem Topf
  • OpenWebif über haproxy auf dem Topf
  • Zugriff auf vorgenannte zwei auch vom Android-Handy aus mit DreamDroid!
  • o*c*m-Web-Interface (nativ)
  • o*c*m-Kekstausch über c***am-Protokoll (Mit o*c*m nativ, mit der Gegenseite (Original c***am) über haproxy)
  • telnet
  • ssh

Könntest du bitte noch mal erläutern, wie man genau HAproxy auf der VU+ installieren muss, um das OpenWebif aufrufen zu können? Ich habe eine Vu+ Duo2 mit aktuellem VTi Team Image 6 und bin UM Neukunde, natürlich mit IPv6, DS-Lite.

Ich wäre dir sehr dankbar!
 
  • Kleiner IPv6-Workshop Beitrag #38
Es geht eigentlich alles:
  • WebInterface (HDMU/Dream) über haproxy auf dem Topf
  • OpenWebif über haproxy auf dem Topf

  • Könntest du bitte noch mal erläutern, wie man genau HAproxy auf der VU+ installieren muss, um das OpenWebif aufrufen zu können?

  • Ich kann es versuchen ...
    Ich habe eine Vu+ Duo2 mit aktuellem VTi Team Image 6
    ... ich verwende allerdings OpenPLi und habe eine Vu+ Ultimo, d.h. es könnten ein paar Pfade abweichen, insbesondere bei den Start-Scripts oder - was noch schlimmer wäre - inkompatible Binaries vorliegen.

    Ich habe mal meinen aktuellen Entwicklungsstand abgelegt. Achtung! Das Paket enthält für MIPS kompilierte Binaries. Also kommt nicht auf die Idee, das auf anderen, nicht-MIPS-Boxen, auszuprobieren, es kann nicht klappen! Ich übernehme ganz generell keine Verantwortung für das, was Ihr mit dem Paket anstellt!

    Das Paket beinhaltet folgende Dateien:
    /usr/sbin/haproxy
    /usr/lib/libpcreposix.so.3.13.1 inkl. Symlink auf /usr/lib/libpcreposix.so.3
    /lib/libpcre.so.3.13.1 inkl. Symlink auf /lib/libpcre.so.3
    /etc/init.d/haproxy inkl. Symlinks auf /etc/rc0.d/K55haproxy , /etc/rc1.d/K55haproxy , /etc/rc2.d/S55haproxy , /etc/rc3.d/S55haproxy , /etc/rc4.d/S55haproxy , /etc/rc5.d/S55haproxy und /etc/rc6.d/K55haproxy
    /etc/haproxy/haproxy.tpl
    /etc/haproxy/services

    Vor dem Auspacken meines Paketes also bitte prüfen, ob es irgendeine der Dateien schon gibt und die ggf. sichern.

    Auf einer Vu+ Ultimo oder kompatiblen unter OpenPLi müßte man nichts weiter tun, als das Paket im Wurzelverzeichnis zu entpacken:
    1. Paket haproxy-mips.tgz z.B. per ftp/Samba ins Wurzelverzeichnis der Box kopieren
    2. Secure Shell oder Telnet zur Box und dort dann eingeben:
    Code:
    cd /
    tar -xzf haproxy-mips.tgz
    shutdown -r now

    Folgendes macht das Start-Script /etc/init.d/haproxy anders als das originale haproxy-Startscript:
    1. Es ermittelt vor "start" "restart" oder "reload" die lokale IPv4 (Muß mit 192. beginnen) und alle aktuellen IPv6s.
    2. Daraus und aus der /etc/haproxy/haproxy.tpl bastelt er für alle in der Datei "/etc/haproxy/services" definierten Dienste einen Proxy-Eintrag in der temporären haproxy.cfg ( /tmp/haproxy.cfg )
    3. Danach wird das gewünschte Kommando (Also "start", "restart" oder "reload") mit eben dieser Konfigurationsdatei ausgeführt
    4. Die Symlinks in /etc/rc?.d sorgen dafür, daß haproxy beim Start/Neustart der GUI etc. pp. passend mit beendet oder gestartet wird.

    Klingt kompliziert, ist es aber nicht. Prinzipiell ist das eine fire&forget-Geschichte und es muß auch nichts an der Konfiguration verändert werden, da alle IPs per auto-detect gefunden werden.

    Sofern der automatische Start klappt, ist eigentlich nur die /etc/haproxy/services interessant für Änderungen. So sieht die mitgelieferte aus:
    Code:
    http;80;;
    https;443;;
    stream;8001;;

    Jede Zeile enthält alle Informationen, die das Script zusätzlich zu den IPs braucht, um eine Proxy-Definition zu schreiben:
    Dienst-Name;Port;Ziel-IP;Ziel-Port

    Wie in der Standardkonfiguration zu sehen, kann man Ziel-IP und Ziel-Port auch weglassen und sollte das auch in der Regel tun.

    Aus der ersten Zeile obiger /etc/haproxy/services würde durch das Start-Script z.B. folgende Proxy-Definition erzeugt:
    Code:
    listen http-proxy	bind fd5b:1234:5678:affe:021d:ecff:fe03:1234:80	bind 2001:0db8:affe:c0c0:021d:ecff:fe03:1234:80	bind 0000:0000:0000:0000:0000:0000:0000:0001:80	server http 192.168.1.16:80

    Wird haproxy mit dieser Config aufgerufen, dann ist das Web-Interface danach unter
    http://[fd5b:1234:5678:affe:021d:ecff:fe03:1234]
    aus dem lokalen Netzwerk
    und unter
    http://[2001:0db8:affe:c0c0:021d:ecff:fe03:1234]
    aus dem gesamten Internet erreichbar (Vorausgesetzt, die Firewall des Routers ist entsprechend geöffnet).

    Euer Ergebnis kann anders aussehen, die fdXX-Adressen vergibt die Fritz!Box z.B. standardmäßig nur, bis ein öffentliches Präfix vorliegt, danach wird das fd00::präfix (Die sog. ULA) als "deprecated" verworfen. Ich habe das bei mir extra umgestellt, daß die ULA dauerhaft zusätzlich vergeben wird, damit ich meine Geräte auch im Heimnetz immer über IPv6 erreichen kann. Man sollte im Heimnetz nirgendwo die öffentliche IPv6 verwenden, wo sie dauerhaft eingetragen würde. Bei einem Verbindungsausfall hat man nämlich keine, die ULA aber schon ...

    Wenn man weitere Proxies braucht, dann fügt man in /etc/haproxy/services einfach Zeilen ein:
    http2;81;;
    http2s;444;;
    z.B. würde zwei weitere Proxies namens "http2-proxy" und "http2s-proxy" erzeugen, die die Ports 81 und 444 zwischen IPv6 und IPv4 vermitteln (Wenn man z.B. beide Web-Interfaces, das alte/Dream-WebInterface und das OpenWebIf, gleichzeitig nutzen will).
    Zu beachten ist nur: Leerstellen sind nicht erlaubt!
    I think you get the idea ;)

    Die Möglichkeit, einen Ziel-Rechner und einen Ziel-Port anzugeben, hat folgenden Hintergrund:
    http-oldbox;82;192.168.1.17;80
    z.B. würde einen Proxy einrichten, der von unserer modernen, IPv6-tauglichen Box über IPv4 an eine andere Box weiterleitet, die z.B. selber kein IPv6 kann.
    Das Web-Interface (Port 80) der Box 192.168.1.17 wäre danach unter der IPv6 der Box, auf der HAproxy läuft, unter Angabe von Port 82 erreichbar.

    Also alles relativ banal. Problematisch sind nur folgende zwei Punkte:
    • Andere Images (Also Dein "Team" statt meines "OpenPLi") haben andere Start-Script-Organisationen. Evtl. würde also HAproxy beim Start der Box nicht automatisch gestartet, wenn die Box nicht die /etc/rc?.d-Verzeichnisse nach Start-Scripts durchsucht. In dem Fall müßte der Aufruf
      /etc/init.d/haproxy start
      halt irgendwie anders dem Systemstart zugefügt werden.
    • HAproxy kriegt nicht mit, wenn sich Dein Präfix ändert. Bei jedem Präfix-Wechsel müßte aber das Script so aufgerufen werden:
      /etc/init.d/haproxy reload
      Mangels Zwangstrennung sollte dieses Problem aber relativ überschaubar sein.
 
  • Kleiner IPv6-Workshop Beitrag #39
Kleiner Nachtrag:

Für meinen Topf[ield TF7700HD PVR] habe ich das natürlich auch gemacht. Das Paket gibt es .
Es paßt so wie es ist für HDMU-Images ab 11160 (Davor hatten die kein IPv6).

Folgende Dateien sind enthalten:
/usr/sbin/haproxy
/usr/lib/libpcreposix.so.3.13.1 inkl. Symlink auf /usr/lib/libpcreposix.so.3
/lib/libpcre.so.3.13.1 inkl. Symlink auf /lib/libpcre.so.3
/etc/init.d/haproxy
/etc/ownscript.sh
/etc/haproxy/haproxy.tpl
/etc/haproxy/services

Dieses Image ist so Fall, wo es keine ordentlichen Runlevel-Scripts (/etc/rc?.d/[S|K]*) gibt, sondern einfach nur die /etc/ownscript.sh , die einmalig beim Start aufgerufen wird.
Ansonsten funktioniert aber alles exakt so, wie oben beschrieben.
 
  • Kleiner IPv6-Workshop Beitrag #40
Es geht eigentlich alles:
  • WebInterface (HDMU/Dream) über haproxy auf dem Topf
  • OpenWebif über haproxy auf dem Topf

  • Könntest du bitte noch mal erläutern, wie man genau HAproxy auf der VU+ installieren muss, um das OpenWebif aufrufen zu können?

  • Ich kann es versuchen ...
    Also alles relativ banal. Problematisch sind nur folgende zwei Punkte:
    • Andere Images (Also Dein "Team" statt meines "OpenPLi") haben andere Start-Script-Organisationen. Evtl. würde also HAproxy beim Start der Box nicht automatisch gestartet, wenn die Box nicht die /etc/rc?.d-Verzeichnisse nach Start-Scripts durchsucht. In dem Fall müßte der Aufruf
      /etc/init.d/haproxy start
      halt irgendwie anders dem Systemstart zugefügt werden.
    • HAproxy kriegt nicht mit, wenn sich Dein Präfix ändert. Bei jedem Präfix-Wechsel müßte aber das Script so aufgerufen werden:
      /etc/init.d/haproxy reload
      Mangels Zwangstrennung sollte dieses Problem aber relativ überschaubar sein.

Vielen lieben Dank. Nach der Anleitung und Installation, wie von dir beschrieben, hat der Zugriff sofort geklappt. Ich musste auch keine Start-Scripte ändern.
Jetzt muss ich mich noch belesen, wie ich aus einem IPv4-Netz, zum Bsp. mein Mobilfunkanbieter, auf das Webinterface komme. Ich glaube, man braucht einen Tunnel?!
 
  • Kleiner IPv6-Workshop Beitrag #41
Vielen lieben Dank. Nach der Anleitung und Installation, wie von dir beschrieben, hat der Zugriff sofort geklappt. Ich musste auch keine Start-Scripte ändern.
Supi.
Jetzt muss ich mich noch belesen, wie ich aus einem IPv4-Netz, zum Bsp. mein Mobilfunkanbieter, auf das Webinterface komme. Ich glaube, man braucht einen Tunnel?!
Yepp, so ist es.

Auf Android fluppt SixXS am besten, am zweitbesten gogo6/freenet6.

Für SixXS benutzt Du .
Außerdem brauchst Du ein Konto bei SixXS und einen noch nicht anderweitig benutzen Tunnel. Konto anlegen und Tunnel beantragen zieht sich wohl über ein paar Stunden ... also die Wartezeit bis zur jeweiligen Genehmigung.
Ansonsten brauchst Du nur noch Deine SixXS-Benutzerdaten in Androiccu eintragen und benötigst danach Du nur noch die Buttons "Start" und "Stop" der App.

Für gogo6 benutzt Du .
Ins Feld "Configuration" trägst Du ein
Code:
server=anonymous.freenet6.net
host_type=router
Das geht auch ohne Anmeldung, dafür muß die App von Hand auf's Smartphone geschoben und installiert werden. Theoretisch müßte es auch mit einem angemeldeten Tunnel gehen, aber bei mir friert die App immer ein, wenn ich Benutzerkennungen eintrage ...
Bei GogoDroid ist es ganz wichtig, daß die App mit dem "Zurück"-Button komplett geschlossen wird, damit wäre auch der Tunnel wieder weg. Du mußt also immer brav aufpassen, daß Du die App nur durch Druck auf den "Home Screen" Button in den Hintergrund schiebst. Außerdem bricht der Tunnel auch ansonsten immer wieder mal zusammen. Von daher taugt GogoDroid eher nur für die Überbrückung der Wartezeit auf den SixXS-Tunnel ...

Bei Androiccu ist es egal ob Du den "Zurück" oder den "Home"-Button drückst. Da läuft der eigentliche aiccu so oder so im Hintergrund weiter, bis er mit "Stop" gezielt beendet wird.

Für iPhone:
Ich habe keine Ahnung.
 
  • Kleiner IPv6-Workshop Beitrag #42
Für iPhone:
Ich habe keine Ahnung.

Ich bin Besitzer eines solchen Telefons :gsicht: - hab auf die schnelle auch nichts gefunden.

Wann will die Telekom im Mobilfunk IPv6 einführen?

Ich fühle mich ehrlich, als wäre ich ein "Versuchskaninchen" von UM. Eigentlich ein interessantes Protokoll und insgesamt auch zu begrüßen, nur müssen alle mitspielen bzw. Dual Stack wäre in der Übergangsphase angebracht.

Ginge es eventuell mit deinem Beitrag im Post http://www.unitymediakabelbwforum.de/viewtopic.php?f=53&t=23008&start=140#p241481?

Könntest du das am Beispiel der VU+ noch einmal erläutern?
 
  • Kleiner IPv6-Workshop Beitrag #43
Re: AW: Kleiner IPv6-Workshop

<r><QUOTE author="thestorm"><s>
</s><QUOTE author="SpaceRat"><s>
</s>
Für iPhone:<br/>
Ich habe keine Ahnung.<e>
</e></QUOTE>

Ich bin Besitzer eines solchen Telefons <E>:gsicht:</E> - hab auf die schnelle auch nichts gefunden.<e>
</e></QUOTE>

Gibt's ziemlich sicher nicht; der große Trivialpatenttroll hat iOS hinreichend vernagelt, so dass das offenbar auch auf ge"jailbreaked"en iPhones nicht mit akzeptablem Aufwand machbar ist <E:mad:</E><br/>
<br/>
Jörg</r>
 
  • Kleiner IPv6-Workshop Beitrag #44
Für iPhone:
Ich habe keine Ahnung.
Ich bin Besitzer eines solchen Telefons :gsicht: - hab auf die schnelle auch nichts gefunden.
So wie es aussieht ist das Teil "broken by design". Kein IPv6-Support im mobilen Netzwerk, nur innerhalb eines WLANs.
Ich fühle mich ehrlich, als wäre ich ein "Versuchskaninchen" von UM. Eigentlich ein interessantes Protokoll und insgesamt auch zu begrüßen, nur müssen alle mitspielen bzw. Dual Stack wäre in der Übergangsphase angebracht.
Das wäre in der Tat angebracht.
Ginge es eventuell mit deinem Beitrag im Post http://www.unitymediakabelbwforum.de/viewtopic.php?f=53&t=23008&start=140#p241481?
Ja, wenn Du auf einen dritten Internet-Zugang (Neben dem des iPenis und der Vu+) und ein daran angeschlossenes System Zugriff hast, das über vollwertigen DualStack verfügt.
Könntest du das am Beispiel der VU+ noch einmal erläutern?
Eigentlich ganz banal, aber aufgrund der o.g. Vorbedingung nicht ganz trivial.

Die Konfiguration, die ich jetzt beschreibe, müßte auf einer Vu+ oder sonst irgendeinem System mit HAproxy vorgenommen werden, welches DualStack hat. Also nicht auf Deiner Vu+, sondern auf irgendeinem durchlaufenden Linux-System mit Dual-Stack-Anbindung!

Du würdest die haproxy.cfg - bzw., wenn mein HAproxy-Paket verwendet wird, die haproxy.tpl - um z.B. Folgendes ergänzen:
Code:
listen thestorm-proxy	bind *:85	server thestorm <IPv6-Adresse Deiner Vu+>:80

Dieser Proxy lauscht auf Port 85 aller IPv4-Adressen des Rechners auf dem dieser HAproxy läuft und leitet alle darauf eingehenden Anfragen an Port 80 der IPv6-Adresse Deiner Vu+ weiter.

Vielleicht klappt es auch so ...
Code:
listen thestorm-proxy	bind *:85	server thestorm <IPv6-DynDNS-Host Deiner Vu+>:80
... glaube ich aber eher nicht:
Der Autor von HAproxy kommt leider mit der Version 1.6 nicht aus dem Quark. Der verwendete HAproxy 1.4 ist noch relativ IPv4-fixiert, was man auch an der nicht normgerechten Angabe von IPv6-IPs sieht. Normal gehören da eckige Klammern drum. Durch diesen Makel muß man die IPv6-Adressen auch expandieren, also z.B. von fd00::0221:12ff:fe07:1234 zu fd00:0:0:0:0221:12ff:fe07:1234 oder von ::1 auf 0:0:0:0:0:0:0:1, weil HAproxy sonst nicht erkennen kann, wo die IPv6 endet und die Port-Angabe anfängt. Auch bindet "*" nicht an ALLE Adressen, sondern nur an alle IPv4-Adressen. Usw. usf.
Von daher gehe ich auch davon aus, daß der 1.4 HAproxy Hostnames nur auf IPv4-Adressen auflösen wird.

In HAproxy 1.5 ist bereits eine viel schönere Syntax implementiert, aber nach Linux-Logik sind ungerade zweite Stellen (Die "5" von "1.5") immer "unstable" (Müßte man also selber kompilieren...), so daß wir die verbesserte Syntax erst irgendwann in Version 1.6 genießen können.

Auf einem Windows-Rechner ginge es übrigens definitiv mit Hostname. Der Befehl
Code:
netsh interface portproxy add v4tov6 listenport=85 vuplus.ipv6dyndns.foo 80
auf der Kommandozeile würde den oben beschriebenen Proxy (Lauscht auf Port 85, leitet weiter an den IPV6-Host vuplus.ipv6dyndns.foo auf Port 80) einrichten.

Mit HAproxy 1.5 oder höher würde es auch so einfach gehen:
Code:
listen thestorm-proxy	bind ipv4@*:85	server thestorm ipv6@<IPv6-DynDNS-Host Deiner Vu+>:80

Durch das vorangestellte ipv4@ bzw. ipv6@ weiß HAproxy dann immer, welches Protokoll man auf welcher Seite will (So wie man es bei Windows' netsh am "v4tov6", "v6tov4", "v4tov4" oder "v6tov6" erkennt). Dann bräuchte ich auch nicht mühsam die IPv6 meines Receivers zu ermitteln, sondern könnte einfach mit ipv6@* an alle davon binden und durch das ipv6@hostname weiß der HAproxy dann auch, daß er den Host per IPv6 und nicht per IPv4 ansprechen soll ...
 
  • Kleiner IPv6-Workshop Beitrag #45
Ersteinmal vielen Dank für den tollen Workshop!!!!! Hat sicherlich sehr viel Mühe gemacht...
Bitteschön. Ja, hat er.
Ich wollte auch eigentlich noch weitermachen, aber im Moment nervt es mich, die Beiträge nicht mehr ändern zu können.
Ein kleine Anregung/ Wunsch habe ich noch, könntest Du auch einmal die DS-Lite "Technik" bzw. dieses Verfahren erläutern?
Eigentlich ganz banal:
Stell Dir vor, Du hast einen ganz "normalen" Internet-Zugang mit IPv4 und einen Router. Hinter diesen Router klemmst Du jetzt noch einen Router und schließt Deine Geräte alle am zweiten Router an.
Stelle Dir jetzt weiter vor, daß der erste Router in einen Schrank eingeschlossen ist und keine Fernwartung darauf möglich ist, desweiteren sind dort keine Port-Weiterleitungen eingerichtet. Du kannst jetzt am zweiten Router an Port-Weiterleitungen einstellen, was Du willst, Du kriegst trotzdem keine Verbindung von außen auf eines der angeschlossenen Geräte hin, weil Du eben keine Port-Weiterleitungen auf dem ersten Router einrichten kannst und Pakete von außen somit den zweiten Router niemals erreichen.
Bei dieser Konstellation funktioniert nur der Verbindungsaufbau von innen nach außen, weil dabei die von außen eintreffenden Antworten den von innen gestarteten Anfragen zugeordnet werden können.

Genau das ist CGN, also Carrier-Grade-NAT, welches auch bei DS-lite für die IPv4-Konnektivität zum Tragen kommt. Der erste Router steht in diesem Fall halt beim Provider und Du hast eben keinen Zugriff darauf, kannst somit keinen Zugriff von außen durchleiten.
Vielleicht darf ich kurz skizzieren, was ich wirklich brauche bzw. was ich vorhabe. Hinter dem Kabelmodem/ UM-Router direkt meine FB7270, daran die LAN- und WLAN-Clients. An meiner FB hängt mein ISDN und es sind zwei VoIP-Anbieter (personal-voip.de, gmx.de) eingerichtet. Schön wäre darüber hinaus der Zugriff auf die FB-Weboberfläche von aussen.

Nun zu meiner Frage, kann ich dies mit IP6/DSlite umsetzen? (Die FB zu Freezen wäre für mich okay.)
Prinzipiell geht mit IPv6 alles was mit IPv4 auch geht und das eigentlich sogar besser.

Es gibt nur zwei Probleme:
  • Die Mehrheit der Anschlüsse kann gar kein IPv6, sind also eingeschränkt in der Hinsicht, daß sie nicht das ganze Internet erreichen können, insbesondere nicht Deine Fritz!Box zuhause, die ja von außen nur per IPv6 erreichbar wäre.
    Dieses Problem ist relativ einfach lösbar, indem man den Teil der Außenwelt, von dem aus man "nach Hause telefonieren" möchte, IPv6-tauglich macht, z.B. durch einen Tunnel. Ab Fritz!Box 7270v2 und bei vielen anderen Routern kann das ganz komfortabel der Router gleich mit erledigen, ansonsten gibt es für Linux und andere *ix, Mac OS X und Windows sowie Androiden auch genug andere Möglichkeiten, um schnell einen Tunnel zu errichten. Penis-Prothesen (iPhones) hingegen sind außen vor, die kriegen IPv6 nur im WLAN, aber nicht im Mobilfunk.
  • Manche Dienste sind nach wie vor nicht IPv6-tauglich
    Hierzu habe ich schon ein paar Tips & Tricks geschrieben. Die Fritz!Box Fernwartung, die Du jetzt als einziges Beispiel genannt hast, funktioniert aber einwandfrei mit IPv6.

Wichtig ist, daß Du mindestens eine 7270v2 (oder v3) brauchst, die v1 ist nur durch freetzen IPv6-tauglich zu machen und da gibt es dann Einschränkungen, z.B. mit der Fernwartung ...

Die v1 hat Firmware-Versionen, die mit 54 beginnen, die letzte ist 54.04.86.
Bei der v2 beginnt die Firmware-Version auch mit 54, es gibt aber noch die deutlich aktuellere 54.05.50.
Firmware-Versionen für die v3 beginnen mit 74, aktuell wäre die 74.05.50.

Man kann die Version auch an der Seriennummer erkennen. Beginnt die zweite Zifferngruppe mit 2, ist es eine v1.
Siehe auch .

Bei einer v1 würde ich erst einmal Abstand von DS-lite nehmen bzw. einen neuen Router kaufen.

Information am Rande, es gibt bei Dir ganz andere Probleme:
1. Die 7270 ist zu langsam, die verdaut nur 16 MBit/s, ggf. geringfügig mehr, aber keine 50 oder gar 100 MBit/s.
2. Du erhältst bei UM i.d.R. kein reines Kabel-Modem mehr, sondern einen besch... Zwangs-Router. Die Fritte oder ein anderes Gerät dahinter als Router weiter zu nutzen ist nur mit Klimmzügen möglich.
 
  • Kleiner IPv6-Workshop Beitrag #46
Vielen Dank für die ausführliche Rückmeldung...
Eigentlich ganz banal
Ist es das nicht immer - wenn man den Sachverhalt verstanden hat. Das mußte jetzt mal sein... :zwinker:


Szenario 1
1play 100 MBit/s mit UM-Kabelmodem (Cisco EPC3208 - ohne G) und IPv4
Genau das ist CGN, also Carrier-Grade-NAT, welches auch bei DS-lite für die IPv4-Konnektivität zum Tragen kommt.
Dank Deiner Ausführungen hierzu, konnte ich nun auch den Wikipedia-Abschnitt "DS-Lite" () verstehen. Jetzt wird für mich, das Ganze schon etwas "Runder"...
Vielleicht darf ich kurz skizzieren, was ich wirklich brauche bzw. was ich vorhabe. Hinter dem Kabelmodem/ UM-Router direkt meine FB7270, daran die LAN- und WLAN-Clients.
Die 7270 ist zu langsam, die verdaut nur 16 MBit/s, ggf. geringfügig mehr, aber keine 50 oder gar 100 MBit/s.
Meine Ausführungen habe ich ehrlich gesagt etwas eingekürzt. Zwischen der UM-Modem (und meiner FB7270 v3 werde ich noch ein GigaBit Switch (http://www.amazon.de/gp/product/B004BM3M6W) schalten.

Dieser, so meine Idee, soll den LAN-Traffic direkt an das UM-Modem leiten und so die volle Geschwindigkeit bereitstellt. Der Traffic über WLAN ist, trotz max. 300 MBit/s, liegt netto sowieso drunter. Allerdings vermute ich, nach Deinem Workshop, das meine FB den Internettraffic routen muss; Stichwort interne auf externe IP-Adresse. Oder?


Szenario 2
1play 10 oder 50 MBit/s mit UM-Blackbox und IPv6/DSlite
Wichtig ist, daß Du mindestens eine 7270v2 (oder v3) brauchst, die v1 ist nur durch freetzen IPv6-tauglich zu machen und da gibt es dann Einschränkungen, z.B. mit der Fernwartung ...
Wie schon erwähnt habe ich eine FB 7270 v3.
Prinzipiell geht mit IPv6 alles was mit IPv4 auch geht und das eigentlich sogar besser.
Du erhältst bei UM i.d.R. kein reines Kabel-Modem mehr, sondern einen besch... Zwangs-Router. Die Fritte oder ein anderes Gerät dahinter als Router weiter zu nutzen ist nur mit Klimmzügen möglich.
Und hier habe ich einfach Angst, dass meine ISDN-Telefone (angeschlossen an meiner FB über VoIP-Telefonie) dann nicht funktionieren! Was meinst Du mit Klimmzügen?

Wie würde es dann aussehen? Der UM-Router stellt meiner FB über (den Switch und dann) LAN1-Port "Internet" einmal als dynamische IP4- (aus dem privaten UM Nummernkreis via DS-lite) und einmal als teilweise dynamisch IP6-Adresse (Host-Teil kommt von meiner FB) zur Verfügung. Diese IPv6-Adresse ist, wie ich hier gelernt habe, von aussen erreichbar - wenn die Gegenstelle IP6 kann.

Mit anderen Worten meine VoIP-Anbieter, namentlich personal-voip.de und gmx.de, müssen "nur" IPv6 beherrschen. Sehe ich das richtig?


Je länger ich überlege, desto kann ich mich auch mit IPv6 anfreunden - ja, wenn - wenn alle Geräte und Anbeiter (z.B. VoIP) hier mitspielen. Allerdings macht es UM unnötig schwer - indem sie den Kunden eine Blackbox an die Hand geben: weil es vermeintlich der Netzabschluss ist und so zur UM-Seite gehört; aber dies ist wieder ein anderes Thema...

Danke!
 
  • Kleiner IPv6-Workshop Beitrag #47
Eigentlich ganz banal
Ist es das nicht immer - wenn man den Sachverhalt verstanden hat. Das mußte jetzt mal sein... :zwinker:
Nun, es gibt Sachen, die bleiben kompliziert, auch wenn man das Prinzip verstanden hat :)
Szenario 1
1play 100 MBit/s mit UM-Kabelmodem (Cisco EPC3208 - ohne G) und IPv4
Dieses würde ich bevorzugen. Allerdings mit einem anderen Router. Die 7270v3 erzielt bei eBay so hohe Preise, daß Du Dir mit wenig Mehrkosten eine 7390 gönnen könntest.
Vielleicht darf ich kurz skizzieren, was ich wirklich brauche bzw. was ich vorhabe. Hinter dem Kabelmodem/ UM-Router direkt meine FB7270, daran die LAN- und WLAN-Clients.
Die 7270 ist zu langsam, die verdaut nur 16 MBit/s, ggf. geringfügig mehr, aber keine 50 oder gar 100 MBit/s.
Meine Ausführungen habe ich ehrlich gesagt etwas eingekürzt. Zwischen der UM-Modem (und meiner FB7270 v3 werde ich noch ein GigaBit Switch (http://www.amazon.de/gp/product/B004BM3M6W) schalten.
Bei dem Aufbau krieg ich Knoten im Gehirn ...

Also, der Router hinter dem 3208 kriegt seine öffentliche IPv4 über DHCP mitgeteilt, gleichzeitig hättest Du aber auch einen DHCP-Server auf der Fritte. Man setzt niemals zwei DHCP-Server gleichzeitig in einem Netzwerk auf. Es wäre reiner Zufall, wer jetzt vom DHCP-Server des 3208 die öffentliche IPv4 bekäme ... die Fritte oder irgendein anderes an den Switch angeschlossenes Gerät ...
Das Kabel-Modem gehört direkt mit dem WAN-Port des Routers (Bei einer Fritte im "Internet über LAN1"-Modus ist das LAN1) verbunden. Damit muß aber eben auch der Router in der Lage sein, den vom oder ins Internet laufenden Traffic zu handhaben, was die 7270 nicht schafft.
Dieser, so meine Idee, soll den LAN-Traffic direkt an das UM-Modem leiten und so die volle Geschwindigkeit bereitstellt. Der Traffic über WLAN ist, trotz max. 300 MBit/s, liegt netto sowieso drunter. Allerdings vermute ich, nach Deinem Workshop, das meine FB den Internettraffic routen muss; Stichwort interne auf externe IP-Adresse. Oder?
Grob gesagt: Ja.
Wenn Du hingegen hinter einen Router mit 100 MBit/s-Anschlüssen einen Gigabit-Switch hängst, dann können die Geräte im LAN untereinander durchaus mit der höheren Geschwindigkeit kommunizieren.
Szenario 2
1play 10 oder 50 MBit/s mit UM-Blackbox und IPv6/DSlite
Prinzipiell geht mit IPv6 alles was mit IPv4 auch geht und das eigentlich sogar besser.
Du erhältst bei UM i.d.R. kein reines Kabel-Modem mehr, sondern einen besch... Zwangs-Router. Die Fritte oder ein anderes Gerät dahinter als Router weiter zu nutzen ist nur mit Klimmzügen möglich.
Und hier habe ich einfach Angst, dass meine ISDN-Telefone (angeschlossen an meiner FB über VoIP-Telefonie) dann nicht funktionieren! Was meinst Du mit Klimmzügen?
Das sind jetzt zwei völlig unterschiedliche Aspekte.
Also: So oder so kannst Du die Fritte weiter nutzen, um daran Deine ISDN-Geräte zu betreiben, da gibt es zig Möglichkeiten. Wenn alle Stricke reißen, kann man die Fritte immer noch als IP-Client laufen lassen (Also wie jedes andere Gerät im LAN auch). Damit würde sie mehr oder minder zu einem VoIP-Adapter degradiert.
Zur Not kann man sogar das VoIP auch in der UM-Hardware konfigurieren (Bei Fremdanbietern natürlich nur, solange UM das nicht in der Firmware sperrt) und die 7270 über den Festnetzeingang einspeisen ...

Ein richtiger Router wird die Fritte dabei aber nicht. Damit verlierst Du z.B. die Möglichkeit, die MyFritz!-Funktionalität zu mißbrauchen, um supereinfach einen IPv6-DynDNS-Dienst für Deine Clients zu haben. Die Ironie daran: Weil Du in diesem Fall IPv6 von Unitymedia hättest, hättest Du auch ein dynamisches Präfix, bräuchtest diese Funktionalität daher auch. In Szenario 1 hingegen kriegst Du von Unitymedia ja IPv4-only und würdest Dir ggf. IPv6 über einen Tunnel-Broker beschaffen, der Dir ein statisches Präfix bietet ... bräuchtest diese Funktionalität also viel weniger dringend, hättest sie aber zur Verfügung ...
Mit anderen Worten meine VoIP-Anbieter, namentlich personal-voip.de und gmx.de, müssen "nur" IPv6 beherrschen. Sehe ich das richtig?
Nein. Die brauchen nicht einmal IPv6 zu sprechen: Richtige Konfiguration und ein STUN-Server beim Anbieter (stun.personal-voip.de:3478 und stun.gmx.net, sind also vorhanden) vorausgesetzt geht es auch über das CGN.

Und dann gibt es da noch einen Aspekt: Ich beschreibe die Abläufe im funktionierenden Normalzustand. Momentan häufen sich aber die Meldungen, daß Unitymedia das CGN nicht gebacken kriegt, die DS-lite-Anschlüsse sind also momentan stark risikobehaftet, zumindest zeitweise eher "IPv6-only" zu laufen, was wirklich total indiskutabel ist.

Im Moment würde ich von Unitymedia ganz abraten, sofern man nicht ganz sicher ein richtiges, nacktes Modem und IPv4 kriegt, also Szenario 1.
Verkrüppelte Zwangsrouter und dank CGN-Ausfall IPv6-only, das ist etwas zuviel des Guten.
 
  • Kleiner IPv6-Workshop Beitrag #48
Dieses würde ich bevorzugen. Allerdings mit einem anderen Router. Die 7270v3 erzielt bei eBay so hohe Preise, daß Du Dir mit wenig Mehrkosten eine 7390 gönnen könntest.
Keine schlechte Idee, ich werde das mal verfolgen...
Zwischen der UM-Modem (und meiner FB7270 v3 werde ich noch ein GigaBit Switch (http://www.amazon.de/gp/product/B004BM3M6W) schalten.
Bei dem Aufbau krieg ich Knoten im Gehirn ...
Meine Aussage war einfach nicht durchdacht!
Im Moment würde ich von Unitymedia ganz abraten, sofern man nicht ganz sicher ein richtiges, nacktes Modem und IPv4 kriegt, also Szenario 1.
Verkrüppelte Zwangsrouter und dank CGN-Ausfall IPv6-only, das ist etwas zuviel des Guten.
Für mich der ausschlaggebende Punkt! Auch wenn IPv6 das bessere Konzept hat, ist das Verfahren für UM (und Andere) einfach noch zu Neu. Da nehme ich doch lieber die alte, eingeschränkte – aber bekannte und bewährte Version 4.

Was überhaupt nicht geht, sind diese - wie Du schreibst - Zwangsrouter - offiziel Netzabschlusspunkte. Was ist wirklich so schlimm, die Zugansdaten dem zahlenden Kunden auf Wunsch zu übermitteln? Ich denke, wenn die Kabel- oder DSL-Netzbetreiber auf bestimmte Funktionen Zugriff benötigen, dann wird sich z.B. bei AVM auch eine Lösung dafür finden... - man muss ja nicht gleich die gesamten Router zur Blackbox machen.
 
  • Kleiner IPv6-Workshop Beitrag #49
Im Moment würde ich von Unitymedia ganz abraten, sofern man nicht ganz sicher ein richtiges, nacktes Modem und IPv4 kriegt, also Szenario 1.
Verkrüppelte Zwangsrouter und dank CGN-Ausfall IPv6-only, das ist etwas zuviel des Guten.
Für mich der ausschlaggebende Punkt! Auch wenn IPv6 das bessere Konzept hat, ist das Verfahren für UM (und Andere) einfach noch zu Neu. Da nehme ich doch lieber die alte, eingeschränkte – aber bekannte und bewährte Version 4.
Nun, für mich der ausschlaggebende Punkt ist der, daß man ja problemlos IPv6 per kostenlosem Tunnel zusätzlich kriegen kann. Man hätte damit also einen fast vollwertigen Dual-Stack-Anschluß.
Prinzipiell funktioniert DS-lite allerdings auch, nur eben nicht, wenn der Provider das CGN nicht hinkriegt.
Was überhaupt nicht geht, sind diese - wie Du schreibst - Zwangsrouter - offiziel Netzabschlusspunkte. Was ist wirklich so schlimm, die Zugansdaten dem zahlenden Kunden auf Wunsch zu übermitteln? Ich denke, wenn die Kabel- oder DSL-Netzbetreiber auf bestimmte Funktionen Zugriff benötigen, dann wird sich z.B. bei AVM auch eine Lösung dafür finden... - man muss ja nicht gleich die gesamten Router zur Blackbox machen.
Es würde ja völlig genügen, wenn UM nicht die - eigentlich vorhandenen - Möglichkeiten deaktivieren würde, um diese Geräte als reine "Modems" (Eigentlich: Bridge) zu benutzen, die Geräte können das nämlich durchaus, es ist nur auf Wunsch von UM in deren Spezial-Firmware deaktiviert. Zugangsdaten in dem Sinne gibt es ja nicht, bzw. die Provisionierung wären auch weiterhin auf dem Bridge-Gerät.
Die Zugangsdaten für VoIP müßte Unitymedia halt rausrücken ... wobei man die mit etwas Recherche auch schon rausfinden kann.

Es ist einfach nicht die Aufgabe des Internet-Providers, mir Vorschriften zu machen, daß ich deren Primitivrouter nutzen muß, wenn ich mir einen besseren Router vom eigenen Geld kaufen und/oder z.B. eine VoIP-Telefonanlage betreiben will. Als nächstes muß man dann wohl auch noch PCs, Notebooks und Telefone beim Internet Provider kaufen ...
 
  • Kleiner IPv6-Workshop Beitrag #50
Moinmoin,

nachdem ich alle Themen bezüglich obengeanannter Problematik durchgearbeitet habe, habe ich mich dazu entschlossen mal persönlich nachzufragen. Folgender Aufbau:

Unitymedia Anschluss -> Fritzbox 6360
Fritzbox IPv6 Portfreigabe -> NAS (IPv6 Adresse im lokalen Netzwerk)

1. Ich habe es bereits geschafft die ipv6 Ports für die NAS freizugeben, komme aber trotzdem nicht von draußen auf die Festplatte. Wie kriege ich das hin? https://[x:x:x:x:x:x:x:x:x:x:]..? Welche Adresse nehme ich da?

2. Wird es wohl irgendwann in naher Zukunft eine Möglichkeit geben auf das VPN der Fritzbox zuzugreifen? Der Unitymedia-mensch meinte nur: Besser Kündigen :D..

3. Nach all der Theorie, gibt es irgendeine Lösung das ganze einigermaßen machbar zu gestalten, dass man auch von ipv4 auf die Fritzbox.net Adresse von außen zugreifen kann?

ICh würde mich wirklich riesig freuen, wenn mir einer helfen könnte.

MFG
 
Thema:

Kleiner IPv6-Workshop

Kleiner IPv6-Workshop - Ähnliche Themen

Vodafone West Konfiguration für feste öffentliche IPv4 + IPv6 an LAN-Anschluss (OPNSense): Hallo, ich bin kurz vor dem Verzweifeln, weil ich bei Vodafone keine geschriebenen Informationen finde, in Foren es mehr Meinungen als fundierte...
Vodafone Täglich mehrfache Internetabbrüche: Hallo liebe Community, ich bin langsam echt verzweifelt und hoffe vielleicht habt ihr ein paar Tipps für mich. Ich bin um Juni diesen Jahres 3...
Fritzbox: IPv6 intern deaktivieren: Hallo, ich habe hier eine eigene FRITZ!Box Cable mit einem DSlite Anschluss über VF West. Es ist ja so, dass IPv4 bei einem DSlite Anschluss...
AVM veröffentlicht FRITZ!OS 8.0 für 6690 Cable: Hallo Community, anbei der Link zur Veröffentlichung. AVM Update-News
Fritzbox Bridge Modus Ipv6 kommt nicht bei Router an (Baden Württemberg): Hallo, ich versuche es seit drei Tagen erfolglos, daher hier die Bitte, ob es überhaupt möglich ist oder nicht, weil es mir keine Ruhe lässt...
Oben