Telekom Dual-Stack Verbindungsaufbau

Bis neulich hatte ich einen normalen DSL-Anschluss von 1&1: Per PPPoE eingewählt und eine IPv4-Adresse bekommen – fertig. Das kann neben der FRITZ!Box natürlich auch jeder vernünftige Router oder Firewall.

Jetzt habe ich endlich einen richtigen Dual-Stack (IPv4 und IPv6) Anschluss der Telekom (Glasfaser “MagentaZuhause M” ohne Fernsehen, siehe hier). Juchu! ;) Bevor ich jedoch den mitgelieferten Speedport durch diverse andere Testgeräte ersetze, wollte ich mal vernünftig mitschneiden, welche Protokolle denn bei einem Verbindungsaufbau genau eingesetzt werden. Vor allem die Prefix Delegation über DHCPv6 interessierte mich…

Note that this post is one of many related to IPv6. Click here for a structured list.

Bis jetzt findet man im Netz leider wenig Details über die genauen Einstellungen eines solchen Verbindungsaufbaus. Lediglich dieser Artikel auf Heise gibt ein paar Hinweise.

Ich verwende aktuelle noch den mitgelieferten Speedport W 724V. Zwischen diesem und dem Glasfasermodem habe ich einen 100 MBit Hub (ja, Hub!) geklemmt, um an einem weiteren Port passiv alles mitschneiden zu können. Hier ein paar Infos dazu, die zukünftig hoffentlich noch mal irgendwem anders helfen. ;)

VLAN 7

Ganz wichtige Info am Anfang: Das komplette Internet findet im VLAN 7 statt! Das heißt, zwischen dem Ethernet Frame und PPPoE hängt noch ein 802.1Q Tag. Er hat standardmäßig die Priorität 0. Der Voice Traffic (SIP) läuft ebenfalls über VLAN 7, allerdings mit Priority 6. So ergibt sich eine ganze Reihe an “Encapsulations“, die sich in Wireshark so darstellt (im Beispiel eines DNS Requests):

PPP with VLAN 7

Verbindungsaufbau

Protokollmäßig sieht der Verbindungsaufbau chronologisch wie folgt aus:

  1. PPPoE Discovery
  2. PPP LCP (RFC 1661) Configuration Request und Ack
  3. PPP PAP Login
  4. PPP IPCP (RFC 1332) um IPv4 Adresse + IPv4 DNS Server zu erhalten. (Die IP Adresse erscheint im ersten Nak Paket, was laut RFC korrekt ist: “The peer can provide this information by NAKing the option, and returning a valid IP-address.”)
  5. PPP IPV6CP (RFC 5072) Configuration Request und Ack. Hier informieren sich beide Seiten über ihre IPv6 Interface Identifier, in meinem Fall eine …ff:fe… Adresse, also durch EUI-64/MAC gebaute ID.
  6. Router Advertisement mit Präfix vom Transfersegment (/64er)
  7. DHCPv6 mit Prefix Delegation (DHCPv6-PD) fürs LAN (/56er) und IPv6 DNS Server

Folgende Sachen sind mir darüber hinaus noch aufgefallen:

  • Die ganzen IPv6 Multicast Listener Reports (sehr viele!) habe ich nicht weiter beachtet. Sie spielen für meine Seite des Routers ja auch keine Rolle.
  • Was ich aber vermisse: Die Duplicate Address Detection für die IPv6 Adressen auf dem Transfersegment zwischen Router (CPE) und dem Glasfasersegment der Telekom. Oder wird das hier nicht benötigt?
  • Was aber im Stream mehrmals auftaucht, ohne dass es dafür Verwendung gibt, ist ein DHCPv4 Discover, welches der Speedport per Broadcast verschickt, und zwar im VLAN 8, in welchem sonst gar nichts stattfindet. Dieser DHCPv4 Discover wird auch nie beantwortet.

Hier ein paar Screenshots von den interessanten Nachrichten. (Ich würde ja auch das Wireshark Capture zum Download stellen, wenn dort nicht in der PPP PAP Nachricht mein Benutzername/Passwort im Klartext stehen würde… ;))

Habe ich etwas vergessen oder falsch interpretiert? Dann bitte melden! Ich kenne die PPP Sachen auch nicht im Detail und habe hier nur etwas reverse engineered. ;)

Speedport durch Firewall ersetzen

Interessant wird es für mich jetzt im nächsten Schritt, wenn ich den Speedport durch eine vernünftige Firewall ersetzen möchte. Das könnte eng werden, da ja diverse Techniken unterstützt werden MÜSSEN. Hier mal eine verläufige Tabelle:

Cisco
ASA
v. 9.2.3
Fortinet
FortiGate
v. 5.2.3
Juniper
ScreenOS
v. 6.3.0r18.0
Palo Alto
v. 6.1.4
PPPoE über VLAN
(Subinterface o. Trunk)
PPP IPV6CP
DHCPv6
Prefix Delegation

Tja, das war’s dann wohl. Schade. Sehr schade sogar. Ich kann auch keinen Router dazwischen hängen (der das ja alles könnte), solange ich den Präfix nicht vernünftig durchgereicht bekomme. Hmpf. Eine Möglichkeit könnte sein, zwischen die Juniper SSG und dem Glasfasermodem einen Switch zu hängen, welcher aus dem Access Port einen Trunk mit VLAN 7 macht.

[NACHTRAG] Ich habe mittlerweile eine Juniper SSG 5 Firewall für die Internetverbindung eingerichtet. Infos dazu siehe hier.[/NACHTRAG]

Ansonsten sieht man recht schön, dass diese Klasse an Firewalls nicht mit dem dynamischen Präfix im Small Office / Home Office (SOHO) kompatibel ist. :(

Featured image “Stacks” by Tim Hynes is licensed under CC BY-NC-ND 2.0.

24 thoughts on “Telekom Dual-Stack Verbindungsaufbau

  1. Hallo,
    Ich weis Mikrotik und RouterOS spielen in einer anderen Klasse aber evtl kann RouterOS
    diese Anforderungen.
    Und besser als eine Speedport Router ist RouterOS alle mal.

    1. Hallo Jan,

      mich würde gern deine pfsense DTAG Dual-Stack Konfig interessieren.
      Kannst Du die entsprechenden Settings posten?

      Danke

      1. Hat schon jemand die DTAG Dual-Stack Konfig mit einem Glasfasermodem und der pfSense probiert und kann kurz beschreiben, ob und wie es geklappt hat?

  2. Die Cisco Router sollten eigentlich PPPoE, IPV6CP und DHCPv6-PD unterstützen. Z.B. 881, 1921. Die haben oft auch eine IOS Firewall.

  3. Hallo,
    ich versuche gerade einen Telekom Dual-Stack Anschluss mit einer FGT 60C OS 5.2.5 ans laufen zu bringen. Die Fortigate als auch Dual-Stack ist erstmal Neuland für mich
    Der IPv4 Teil ist relativ problemlos, aber dann ging es los.

    – Benötige ich DHCPv6-PD, wenn ich ein festes Prefix habe, wenn ja, kann ich den Versuch hier gleich beenden.
    – Wie muss ich das wan1-Inferface konfigurieren, und wie sehe ich, ob ich dann hier auch die eine IPv6 zugeordnet bekomme.
    – Wie setzte ich die VLAN 7 für das wan1-Interface? Wenn ich ein VLAN anlege, funktioniert darin pppoe nicht. Sollte das so gehen?

    Von der Telekom habe ich ein Prefix für das WAN (ein /64) bekommen, und das /56 für das LAN.
    Wäre für Hilfe Dankbar.

    1. Hey Ingo.
      Hast du ein statisches Präfix von der Telekom? SEHR GUT! In welchem Tarif bist du denn drin?

      – Wenn du einen statischen Präfix hast, brauchst du (wahrscheinlich) kein DHCPv6-PD. Aber nur dann, wenn die Telekom den Präfix an die vorgegebene IPv6 Adresse aus dem /64 WAN Link routed, die du auf deiner Firewall konfigurieren must. Frage: Ist die Adresse für deine Firewall dort fest vorgegeben? Das vermutlich gut. (Oder du kannst bei der Telekom angeben, an welche Adresse der Präfix gerouted werden soll?)
      – Die WAN Adresse musst du entsprechend aus dem /64er belegen. Die Frage ist nur, welche. Hängt vom Routing ab, siehe oben.
      – PPPoE in einem VLAN lässt sich bei meiner FortiGate konfigurieren. Einfach “Create New” auswählen, dann “VLAN” auswählen, dort das Interface (WAN1) angeben und die VLAN ID 7. Und dann halt IP Adresse per PPPoE beziehen. Geht das nicht???

      Ciao,
      Johannes

      1. Hallo,

        Vertrag ist ein DeutschlandLAN IP Voice/ Data S (aktuell nur ein ADSL Anschluss) Was soweit ich bisher herausgefunden habe, wohl der Grund sein dürfte, das die Sache mit dem VLAN nicht funktioniert. Das scheint man wirklich nur ab VDSL zu brauchen bzw. da funktioniert es hoffentlich dann, wobei ich hier auch andere Informationen dazu gefunden habe, deswegen der Versuch.

        Die Adresse für den WAN-Teil ist nicht vorgegeben, ich kann hier auch auf Telekom-Seite nichts konfigurieren. Hier muss also irgendeine Art der Autokonfiguration erfolgen, das versuch ich gerade heraus zu bekommen. Ein Draytek Vigor 130 ist in Anmarsch, der soll dann zwar nur als Modem dienen. Aber hier kann ich soweit ich das sehe, diesen auch für Dual-Stack einrichten. Ich werden diesen dann mal als Router konfigurieren, um zu sehen, was hier wo zugewiesen wird. Die Fortigate möchte ich in jedem Fall benutzen, da ich da eine echte Firewall haben möchte.

        1. so Teilerfolg zu vermelden.

          Das WAN-Interface noch auf “autoconf” setzen. Damit bekomme ich jetzt via SLAAC das WAN-Prefix auf das WAN-Interface(auch für ipv6 pppoe setzen) zugeordnet.
          Ich habe jetzt aus dem LAN-Prefix ein /64 aus dem /56 genommen, und den dem internen Interface zugeordnet. Die xxxx::1 hab ich jetzt auf der Fortgate gesetzt. Die anderen Rechner im Netzwerk bekommen via SLAAC aus dem /64 Prefix eine IP.
          Was geht jetzt:
          ich kann von der Fortgate aus nach extern Pingen, ich kann nach Intern Pingen. Was jedoch nicht passiert, ist, das vom intern der Traffic nach außen gerouted wird, zumindest kommt kein ok zurück, auch wenn es so aussieht, als würden ipv6 Pakete das Netzwerk verlassen. Gleiches von extern nach “intern”. Logfiles zeigen auch kein Blockieren an.
          Was funktioniert, wenn ich im Regelsatz für Intern->Extern NAT einschalte. Habe ich zumindest via IPv6 zugriff nach aussen, allerdings mit dem WAN-Prefix, bzw der dem WAN-Interface zugeordneten IP.
          Was noch meiner fehlenden Kenntnis von ipv6 geschuldet sein dürfte ist, das für mich merkwürdige setzen der Gateways. Die Fortigate wird über eine FE80… aus dem internen Netz angesprochen, genauso dann spricht das WAN-Interface mit seinem gegenüber über FE80… IP.

          Der Versuch mit dem Draytek hat ein für mich nicht ganz nachvollziehbares Bild ergeben. Und zwar wurde hier auf dem WAN-Interface schon das erste /64 Netz (7300) aus dem mir zugeteilten /56 zugeordnet, auf dem LAN-Interface dann das nächste(7301) . Das WAN-Prefix war hier nicht weiter sichtbar, habe das ganze aber nur mal kurz angetestet.

          Jetzt stellt sich für mich die Frage, ob ich hier irgend ein wie auch immer geartetes Routing manuell setzen muss. Oder ist das einfach schlichtweg mit der Fortgate so nicht möglich.
          FortiOS 5.4 kann ich leider nicht einsetzen, das die Fortigate 60c nicht mehr unterstützt wird. Da steht also dann eine Neuanschaffung an.

    2. In den Release-Notes von FortiOS 5.4 (oder 5.4.1?) habe ich etwas von DHCPv6-PD (Prefix Delegation) gelesen. Vielleicht hilft das bei dem einen oder anderen Problem für Testumgebungen. Produktiv einsetzen würde ich 5.4.x Stand Feb.2016 noch nicht.

      1. Das kann ich bestätigen. FortiOS 5.4 unterstütz durch das anschalten eines Parameters Prefix Delegation via DHCP:

        config sys interface
        edit [interface_name]
        config ipv6
        set ip6-mode dhcp
        set dhcp6-prefix-delegation
        end

        Über die GUI lässt sich das übrigens nicht machen, dort kann man nur DHCP für 6 einschalten, aber kein PD.

        1. sorry, kleine Korrektur:

          der Befehl innerhalb der IPv6 Konfiguration lautet vollständig:

          set dhcp6-prefix-delegation enable

  4. Ich wollte nur kurz erwähnt haben, das ich bei 1und1 bereits seit April 2014 mit IPv6 versorgt wurde. Lediglich auf der FB musste IPv6 Aktiviert werden.

  5. Versuche gerade IPv6 an einem Cisco RV340W an einem Telekom Business-Anschluss zu konfigurieren, bislang leider erfolglos. Bei der Fehlersuche bin ich auf diesen Blog gestoßen. Gibt es Erfahrungswerte zur Konfiguration von Cisco-Geräten der RV-Serie im Hinblick auf Telekom IPv6?

    1. Hi Bastian,
      mir sagt diese Cisco Serie leider gar nichts. Kann dir da also leider nicht helfen.
      (Oder läuft da das normale Cisco IOS drauf? Dann müsstest du mal bei dem Link aus dem Kommentar über dir schauen.)
      Cu,
      Johannes

  6. Hallo Johannes,

    ich schreibe mir gerade eine Art “DHCPv6-Client” in C.
    Leider bekomme ich von der Telekom keine Antwort auf meine “SOLICIT”-Anfrage.
    Deswegen wäre es für mich extrem hilfreich, wenn Du mir Deine “SOLICIT”-Anfrage als Hexdump zukommen lassen würdest.

    Das geht so (ich hab bei mir die englische Version von Wireshark installiert, deswegen sind die Begriffe in englisch):

    Rechtsklick auf Paket Nr. 31 –> Copy –> …as Hex Dump

    Danach befindet sich der Hexdump in der Zwischenablage und sieht ungefähr so aus (dieser Hexdump ist ein ARP-Paket von mir):

    0000 d8 cb 8a 9a ce ac b8 27 eb fb 1c ee 08 06 00 01
    0010 08 00 06 04 00 02 b8 27 eb fb 1c ee c0 a8 01 64
    0020 d8 cb 8a 9a ce ac c0 a8 01 66 00 00 00 00 00 00
    0030 00 00 00 00 00 00 00 00 00 00 00 00

    Diesen Hexdump dann als Datei abspeichern (z.B. als “hexdump1.txt”) und in Wireshark im Menü folgendes aufrufen:

    File –> Import from Hexdump… –> Filename –> hexdump1.txt –> OK

    Und schon kann man sich das eben importierte Paket in Wireshark mit all seien Details ansehen.

    Könntest Du mir bitte Dein Paket Nr. 31 als Hexdump schicken?

    Danke und schöne Grüsse

    Thomas

    1. Klar:
      0000 44 2b 03 19 03 44 d4 21 22 76 5b 79 81 00 00 07
      0010 88 64 11 00 1f 3d 00 8b 00 57 60 00 00 00 00 61
      0020 11 40 fe 80 00 00 00 00 00 00 d6 21 22 ff fe 76
      0030 5b 79 ff 02 00 00 00 00 00 00 00 00 00 00 00 01
      0040 00 02 02 22 02 23 00 61 14 e8 01 c9 2c 99 00 01
      0050 00 0e 00 01 00 01 1c d0 bf 26 d4 21 22 76 5b 79
      0060 00 0e 00 00 00 14 00 00 00 08 00 02 00 00 00 06
      0070 00 04 00 17 00 1f 00 19 00 29 00 00 00 0b 00 00
      0080 00 00 00 00 00 00 00 1a 00 19 00 00 00 00 00 00
      0090 00 00 38 00 00 00 00 00 00 00 00 00 00 00 00 00
      00a0 00 00 00

      Einfach per copy-paste als Textdatei abspeichern und dann in Wireshark wie von dir beschrieben importieren. Imponiert mir! ;)

      1. Wow, das war ja eine wirklich schnelle Antwort!
        Vielen Dank!
        Dein “SOLICIT”-Paket hat mehr Optionen als mein bisheriges und auch in der “Client Identifier”-Option sind ein paar Felder anders gesetzt.
        Das im Detail zu analysieren und den Telekom-DHCPv6-Server zu einer Antwort überreden wird wohl ein paar Tage dauern, aber wenn es dann final funktioniert werde ich mich hier wieder melden.

        Vielen Dank nochmal

        Thomas

          1. Hier die versprochene Rückmeldung:

            Das entscheidende Detail, um den Telekom-DHCPv6-Server zu einer Antwort zu bewegen ist die “Identity Association for Prefix Delegation Option” (siehe https://datatracker.ietf.org/doc/html/rfc8415#section-21.21)
            versehen mit einer “IA Prefix Option” (siehe https://datatracker.ietf.org/doc/html/rfc8415#section-21.22).

            Dies herauszufinden hätte ich nach längerem Suchen wahrscheinlich auch geschafft, aber durch Deine schnelle Hilfe hast Du mir schon einiges an Zeit gespart!
            Also nochmal vielen Dank von meiner Seite and Dich!

            Schöne Grüsse

            Thomas

Leave a Reply

Your email address will not be published. Required fields are marked *