IPv4-Adressen werden immer knapper, der aktuelle Stand der Dinge lässt die komplette Erschöpfung des alten IP-Protokolls mit sich bringen.

Es ist eine Frage der Zeit bis auch das alte Protokoll nicht mehr so im „VIP“ Segment mehr sein wird, wie es jetzt noch zurzeit ist.

IPv4-Adressen sind nämlich noch sehr bares gut, aufgrund dessen gibt es bereits Angebote mit dem sogenannten Slogan „IP-Lease“.

IPv4-Adressen mieten und monatlich um 100+ Euro zu bezahlen und das Netz z. B. zum eigenen ASN hierzu announcen, ist nicht unbekannt.

Warum nicht auf IPv6 setzen?

Nun, die Idee finde ich zumindest überhaupt nicht verkehrt, aber es gibt Nachteile.

Warum der eigentliche Umstieg schon ein paar Jahrzehnte andauert, ist mit folgenden Begründungen zu verstehen:

• Anwendungen gehen z.B. nur auf IPv4 bzw. schlimmer, wenn es für die jeweilige Software keine Updates für das neue Protokoll geben kann.
• Der Umstieg bedeutet für Firmen eins: Kosten und komplexere Strukturen innerhalb des Netzwerkes.
• Oder auch der eigenen Überzeugung, dass IPv4 noch Zukunft hat, EDIT: sicherlich nicht.

Denn wie oben beschrieben ist IPv4 geradezu enorm erschöpft und die Frage ist als Hauptthema zu besprechen: Warum nicht jetzt bereits beginnen, zukunftsorientiert zu handeln im IT-Segment?

Baust Du Webseiten? Meine Idee, wie wir das umsetzen

6to4, eine Art von Begriff eine IPv6 zu IPv4 zu tunneln, Routen oder einfach mit einer IPv4 Proxy im backend Bereich her nur IPv6 Container zu verknüpfen.

Wie ich mir das Vorstelle, dass erkläre ich Euch kurz:

URL ist z.B. mein Blog und dieser hostet auf beispielsweise auf einem LXC-Container / Docker und hat eine Only-IPv6 Backend IP.

Der Client verbindet sich aber zuerst mit der Reverse Proxy und diese ruft die Webseite vom Backend auf.

Was und wo ist da genau der Sinn?:

Wir haben nur 1x IPv4 für alle unsere Webseiten, zur Stütze damit alle jeweils Connecten können, siehe oben der Erzählung des schweren Umstiegs.

Und wir als Betreiber sparen somit für jeden Webserver, der extern liegt, eine IPv4-Adresse.

Bei größeren Projekten ist dieses Verfahren auch überhaupt kein Problem es umzusetzen oder auch Load Balancer einzurichten.

Denn IPv6-Subnetze bieten eine enorme und fast nie erreichbare Anzahl an einzelnen IP-Adressen, innerhalb des IP-Netzes.

Deswegen hat das auch ein Vorteil für mehrere Container oder auch Virtualisierungsmöglichkeiten.

Caddy Konfigurationen als Beispiel:

Caddy kann als Webserver, Proxy oder mit Erweiterungen mehr Möglichkeiten erzielen.

Ich nutze hierzu den Proxy Modus um meine Webseiten alle vom Backend her, sei es vom Internen Docker Netzwerkes oder auch zu extern mit IPv6-Only LXC / KVM Virtualisierte Webserver.

Ein wirklich simples Beispiel eines Caddy Reverse Proxys:

# Redirect HTTP to HTTPS
http://example.eu {
    redir https://example.eu{uri} permanent
}

# Main site
example.eu {
    encode zstd gzip

    reverse_proxy https://[IPv6-Hier-Eintragen]:443 {
    # Optional transport http {
    #    tls
    #    tls_insecure_skip_verify # nur Optional / Self-Signed backend SSL
    #    tls_server_name example.eu
    }
}

    # Headers
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
        X-Frame-Options "DENY"
        X-Content-Type-Options "nosniff"
        Referrer-Policy "no-referrer-when-downgrade"
        Permissions-Policy "geolocation=(), microphone=(), camera=()"
    }

    # Media caching
    @static_assets {
        path_regexp static \.(?:jpg|jpeg|png|gif|webp|svg|ico|css|js|woff2?|ttf|eot)$
    }
    header @static_assets {
        Cache-Control "public, max-age=31536000, immutable"
    }

    log {
        output file /var/log/caddy/example-access.log {
            roll_size 10mb
            roll_keep 10
            roll_keep_for 720h
        }
        level INFO
    }
}

# Redirect HTTP to HTTPS
http://example.eu {
    redir https://example.eu{uri} permanent
}

# Main site
example.eu {
    encode zstd gzip

    reverse_proxy https://[IPv6-Hier-Eintragen]:443 {
    # Optional transport http {
    #    tls
    #    tls_insecure_skip_verify # nur Optional / Self-Signed backend SSL
    #    tls_server_name example.eu
    }
}

    # Headers
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
        X-Frame-Options "DENY"
        X-Content-Type-Options "nosniff"
        Referrer-Policy "no-referrer-when-downgrade"
        Permissions-Policy "geolocation=(), microphone=(), camera=()"
    }

    # Media caching
    @static_assets {
        path_regexp static \.(?:jpg|jpeg|png|gif|webp|svg|ico|css|js|woff2?|ttf|eot)$
    }
    header @static_assets {
        Cache-Control "public, max-age=31536000, immutable"
    }

    log {
        output file /var/log/caddy/example-access.log {
            roll_size 10mb
            roll_keep 10
            roll_keep_for 720h
        }
        level INFO
    }
}

Damit wäre Folgendes möglich:

• Reverse Proxy
• Media Caching
• Secure HSTS Header
• Individuellen Log File
• Auto-SSL (Let’s Encrypt)

Probier’s aus!

Wenn Dich diese FAQ Dein Interesse geweckt hat, so freut mich das natürlich sehr 🙂

Ich wollte Euch damit ein Fragen und Ideen erklären, wie man das eben am besten umsetzen kann.