AWS-Kunden können sich nicht von IPv4 lösen

 (tty.neveragain.de)
1 Punkte von GN⁺ 2023-09-24 | 1 Kommentare | Auf WhatsApp teilen
  • AWS berechnet seit Februar 2024 für jede dedizierte öffentliche IPv4-Adresse 0,005 $ pro Stunde, aber wegen Einschränkungen bei AWS-Services ist es für Kunden schwierig, die Kosten durch einen Wechsel zu IPv6 zu vermeiden
  • Die Gebühren betreffen viele Dienste, darunter Elastic Load Balancer, EC2/Elastic IP, ECS-Fargate-Tasks mit öffentlicher IP, Global Accelerator, Site-to-Site VPN, RDS und Managed NAT Gateway
  • EC2, VPN, Transit Gateway, Direct Connect und Network Firewall funktionieren zwar auf IPv6-Basis, aber zentrale Services wie API Gateway, Lambda, ECS und App Runner lehnen IPv6-only-Subnetze ab oder unterstützen sie nicht richtig
  • Selbst bei einer internen Dual-Stack-Konfiguration unterstützen mehr als 90 % der Service-API-Endpunkte kein IPv6, sodass sich S3, Systems Manager oder SQS aus einer VPC ohne öffentliche IPv4 nur schwer nutzen lassen
  • Für große Kunden macht das oft weniger als 1 % der Rechnung aus, wodurch der Anreiz zur Umstellung gering ist; KMU, Hobby-Nutzer und Startups können dagegen Kostensteigerungen von 10–30 % erleben und sind stärker belastet

Ab Februar 2024 werden dedizierte öffentliche IPv4-Adressen berechnet

  • AWS berechnet seit Februar 2024 für jede dedizierte öffentliche IPv4-Adresse 0,005 $ pro Stunde
    • Das entspricht fast 4 $ pro Monat und mehr als 40 $ pro Jahr
    • Die Gebühr gilt für IPs im Besitz von AWS; BYOIP-Adressen, bei denen Kunden eigene routbare öffentliche IPv4-Blöcke mitbringen, werden nicht berechnet
  • Die Gebühren betreffen einen breiten Bereich zentraler Ressourcen, die öffentliche IPv4 direkt verwenden
    • Elastic Load Balancer
      • Verwendet eine Adresse pro Availability Zone
      • Mindestens 2 werden benötigt, und IPv4 lässt sich nicht deaktivieren
    • EC2-Instanzen und Elastic IP
    • ECS-Fargate-Tasks mit konfigurierter öffentlicher IP
    • Global-Accelerator-IPs
    • Site-to-Site-VPN-IPs
    • RDS
    • Managed NAT Gateway
  • Geteilte IPv4-Adressen sind ausgenommen
    • Geteilte Adressen, die für CloudFront-Distributionen oder API-Gateway-Endpunkte verwendet werden, sind nicht gebührenpflichtig
    • Öffentliche IPv4-Adressen, die von Lambda-Funktionen außerhalb einer VPC verwendet werden, sind ebenfalls ausgenommen

Konfigurationen mit deutlich höheren Kosten

  • Ein öffentlicher Elastic Load Balancer, der über 3 Availability Zones verteilt ist, erhöht den Grundpreis um mehr als 50 %
  • Bei Managed NAT Gateway steigt der Grundpreis um rund 10 %
    • NAT Gateway bietet keine Redundanz pro Availability Zone
    • Wenn ausgehende Verbindungen wichtig sind, wird in jeder Availability Zone ein NAT Gateway benötigt
  • Besonders stark betroffen sind zwei Muster, bei denen viele Adressen verschwendet werden
    • Eine Konfiguration mit mehreren Load Balancern pro VPC
      • Das entsteht beim Kombinieren mehrerer CloudFormation-Templates oder Terraform-Module oder wenn ein Kubernetes-Ingress-Controller für jeden Service einen Load Balancer erstellt
      • Ein einzelner Load Balancer kann mehrere URLs und Services bedienen
    • Eine Konfiguration, bei der absichtlich öffentliche IPv4-Adressen an EC2-Instanzen und Fargate-Tasks vergeben werden, um Managed NAT Gateway zu vermeiden
      • Ironischerweise ist dieser Ansatz weiterhin günstiger, solange man nicht auf ungefähr 10 öffentliche IPv4-Adressen pro Availability Zone kommt

So prüft man die aktuelle Nutzung

  • Die Nutzung öffentlicher IPv4-Adressen wird im Konto bereits erfasst
    • Derzeit wird sie mit 0 $ angezeigt, aber seit Februar 2024 werden 0,005 $ pro Stunde berechnet
  • Die Nutzung lässt sich an folgenden Stellen prüfen
    • Billing Dashboard > Bills
      • Im Abschnitt Virtual Private Cloud erscheint sie als PublicIPv4:InUseAddress
    • Cost Explorer
      • Wenn nur nach PublicIPv4:InUseAddress gefiltert wird, lässt sich die tägliche und stündliche Nutzung sehen
      • Eine Gruppierung nach Mitgliedskonten ist ebenfalls möglich
    • VPC > VPC IP Address Manager > Public IP insights
      • Dort gibt es eine Übersicht über die Nutzung öffentlicher IPv4-Adressen
      • Dieser Teil von IPAM ist kostenlos
      • Angezeigt werden aber nur Daten auf Konto- und Regionenebene; temporär genutzte Adressen werden nicht erfasst, daher sind die Daten unvollständig

Zwei Wege zur Einführung von IPv6

  • Da IPv4-Adressen kostenpflichtig sind und IPv6-Adressen kostenlos, wirkt ein Wechsel zu IPv6 auf den ersten Blick wie die natürliche Wahl
  • Bei IPv6 gibt es kein Konzept privater Adressen, sodass sich Managed NAT Gateway und dessen Kosten vermeiden lassen
  • Grundsätzlich gibt es zwei Wege zur Einführung von IPv6
    • Dual Stack
      • Auf allen Systemen werden sowohl IPv4- als auch IPv6-Adressen konfiguriert
    • Internes IPv6-only
      • Intern wird nur IPv6 verwendet, und IPv4-Konnektivität wird nur am Edge oder CDN bereitgestellt, das mit Endnutzern in Kontakt steht
  • Ein Memorandum des Weißen Hauses stellt fest, dass der Betrieb von Dual Stack für den laufenden Betrieb zu komplex und unnötig geworden ist und dass Standardisierungsgremien sowie große Technologieunternehmen beginnen, auf IPv6-only-Bereitstellungen umzusteigen
  • AWS bietet für IPv6-Netzwerke selbst eine vergleichsweise gute Grundunterstützung
    • IPv6-only-EC2-Instanzen lassen sich in IPv6-only-Subnetzen konfigurieren
    • Lokales DNS, Zeitdienste, Host-Konfiguration und Sicherheit funktionieren wie in einem IPv6-Netzwerk zu erwarten
    • VPN, Transit Gateway, Direct Connect und Network Firewall unterstützen ebenfalls IPv6

IPv6 scheitert bei der Nutzung von AWS-Services

  • Der Engpass liegt weniger im Netzwerk selbst als bei der Anbindung an andere AWS-Services
  • Zentrale Services wie API Gateway, Lambda, ECS und App Runner lehnen IPv6-only-Subnetze ab oder werfen Fehler
    • Elastic Load Balancer kann Fehler wie Not enough IP space available ausgeben
  • Auch eine interne Dual-Stack-Konfiguration reicht nicht aus
    • Viele Services ignorieren IPv6 selbst dann, wenn es im Subnetz konfiguriert ist
    • Häufig können sie nur Ziele mit IPv4 erreichen
  • In vielen Fällen ist es schwierig oder unmöglich, Service-APIs aus einer VPC ohne öffentliche IPv4-Adresse zu verwenden
    • Auf einer EC2-Instanz schlägt aws s3 ls fehl
    • Systems Manager, der empfohlene Weg für Zugriff und Verwaltung von Instanzen, funktioniert nicht
    • Ein ECS-Task kann nicht auf SQS zugreifen
  • Laut AWS IPv6 Support Status unterstützen mehr als 90 % der Service-API-Endpunkte kein IPv6
  • Auch SES SMTP und ECR-Repository-Endpunkte funktionieren nicht, und CloudFront kann keine Verbindung zu einem IPv6-Origin herstellen
    • ECS-Tasks lassen sich dadurch nicht aus ECR starten, aber mit Docker Hub, das IPv6 unterstützt, schon
    • Docker Hub wendet Rate Limits auf Pulls an

PrivateLink ist eine Alternative, aber durch Kosten eingeschränkt

  • Viele Services lassen sich über PrivateLink anbinden
    • Es verbindet direkt mit der Kunden-VPC, sodass keine öffentliche IP-Adresse nötig ist
    • Allerdings werden nicht alle Services unterstützt
  • PrivateLink wird pro Service und pro Availability Zone berechnet
    • Pro Endpoint fallen etwa 9 $ pro Monat an
    • Wenn zum Beispiel Secrets Manager, EC2, SSM und SSM-Messages über 3 Availability Zones angebunden werden, kostet das pro VPC mehr als 1.200 $ pro Jahr
    • Hinzu kommen zusätzliche Traffic-Gebühren

Warum IPv4-Gebühren kaum zu einer IPv6-Umstellung führen dürften

  • Für größere Kunden liegen die IPv4-Gebühren meist bei weniger als 1 % der Rechnung, sodass sie kaum als große Veränderung wahrgenommen werden
    • Allein diese Kosten werden kaum sinnvolle Engineering-Investitionen auslösen
  • Für KMU, Hobby-Nutzer und Startups können die Gebühren die Rechnung dagegen um 10–30 % erhöhen
    • Sie haben einen starken Anreiz, IPv6 einzuführen, um Kosten zu vermeiden
    • Wegen der Lücken in der IPv6-Unterstützung bei AWS-Services gibt es aber nur begrenzte Möglichkeiten, die IPv4-Kosten zu umgehen
  • Angesichts der jüngsten Kosten für die Beschaffung von IPv4-Adressen kann eine Bepreisung von IPv4 an sich notwendig sein
  • Wenn die IPv6-Unterstützung über AWS-Services hinweg ausgereifter wäre, könnten deutlich mehr Kunden in IPv6-only-Umgebungen wechseln
  • Derzeit ist IPv6 bei AWS kaum ein Bürger erster Klasse, und unter diesen Bedingungen macht die IPv4-Bepreisung die Nutzung von AWS für private Konten, Lernen, Zertifizierungsvorbereitung und Open-Source-Unterstützung unattraktiver

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-09-24
Meinungen auf Hacker News

  • Als ich vor langer Zeit Junior-Entwickler bei Amazon war, gab es ein großes internes Projekt, bei dem alle internen Systeme in regionsspezifische Versionen aufgeteilt wurden und Aufrufe zwischen Regionen nur noch über begrenzte Gateways erlaubt waren.
    Der Grund war, dass die internen IPv4-Adressen erschöpft waren.
    Auf die Frage „Hätte man nicht einfach auf IPv6 umstellen können?“ antwortete der zuständige Principal PM sinngemäß: „Zu viele unserer vorhandenen internen Netzwerkgeräte unterstützen kein IPv6; um sie zu ersetzen, hätten wir nahezu die gesamte weltweite Jahresproduktion solcher Geräte kaufen und überall installieren müssen.“
    Es ist leicht, Amazon beim Thema IPv4 böswilliges Verhalten zu unterstellen, aber angesichts der Größenordnung der AWS-Systeme ist es durchaus glaubhaft, dass der vollständige Austausch alter Netzwerkhardware in kurzer Zeit ein viel zu großes Projekt gewesen wäre.

    • Ich frage mich, ob du dich erinnerst, in welchem Jahr das war.
      Ich habe den Verdacht, dass das etwas Unsinn war oder zumindest eine kreative Verpackung der Wahrheit. Zum Beispiel könnte es in Wirklichkeit überall IPv6-Unterstützung gegeben haben, aber von Angst, Unsicherheit und Zweifel geprägte Netzwerkingenieure wollten sie vielleicht nicht aktivieren.
      Die meisten Netzwerkgeräte, die ich gesehen habe, waren schon lange Dual Stack, bevor IPv6 in ihrer Umgebung tatsächlich genutzt wurde; ich dachte immer, das sei wegen Anforderungen der US-Regierung oder des Militärs eingebaut worden.
    • An diese Regionalisierung erinnere ich mich. Von außen betrachtet war das auch eine „interessante“ Sache. Ich war auf der Seite eines neuen Dienstes, der von Anfang an regionsweise gebaut wurde.
      Ich weiß nicht mehr, wer der PM dieses Projekts war, aber damals habe ich wirklich gelernt, welchen Wert ein TPM schaffen kann.
      Es stimmt, dass Kosten und die Notwendigkeit, Netzwerkgeräte auszutauschen, einer der starken Gründe waren, nicht auf IPv6 zu gehen. Amazon nutzte aus verschiedenen Gründen selbst entworfene und gefertigte Netzwerkgeräte, und tut das vermutlich auch heute noch.
      Diese Geräte hatten alle eine feste Speicherkapazität, sodass sie hätten ersetzt werden müssen, um genug Speicher für IPv6-Routingtabellen usw. zu haben. Selbst wenn man IPv6-only gewählt hätte, hätten die vorhandenen Geräte nicht gereicht, und ohne IPv4/IPv6-Dual-Stack wäre man ohnehin kaum durchgekommen.
    • Der PM war vermutlich Laura Grit, und ich denke, tatsächlich war sie TPM. Laura ist inzwischen Distinguished Engineer.
      Sie scheint immer Projekte in enormem Maßstab zu machen, und IPv4 gehört heute eher zu den kleineren davon. Einige ihrer aktuellen großen Projekte kann ich leider nicht teilen.
      Sie hat sich ein paar Mal Zeit genommen und mir kluge Ratschläge gegeben, wofür ich dankbar bin.
    • Wenn der Austausch der gesamten alten Netzwerkhardware in kurzer Zeit ein zu großes Projekt ist, sollte Amazon die IPv4-Gebühren nicht mit einem knappen Zeitplan durchdrücken, bevor der Austausch abgeschlossen ist, damit IPv6 überall intern unterstützt werden kann.
    • Das heißt aber nicht, dass man auf eine schrittweise Einführung von IPv6 verzichten kann. Dieses Problem lässt sich nicht ewig aufschieben.
      Sicher haben sie den Prozess bereits gestartet.
      Oder? Es ist schwer vorstellbar, dass AWS den Kopf in den Sand steckt und das ignoriert.

  • Dass AWS korrekt funktionierendes IPv6 anbietet, scheint offensichtlich gegen seine Anreize zu laufen. Die Einflussinstrumente von AWS, etwa die Well-Architected-Kriterien oder Zertifizierungen, drängen stark dazu, nicht internetartige Architekturen mit End-to-End-Adressierung zu bauen, sondern Labyrinthe aus vage adressierten 10.x-RFC1918-Netzen.
    In der Welt der AWS-Empfehlungen ist schon das Konzept einer „öffentlichen IP-Adresse“ ein Warnsignal, und AWS empfiehlt sogar Tools, die gegen Aufpreis solche Adressen anzeigen und „abmildern“.
    Wenn man Kunden dazu bringt, unter dem Vorwand der Sicherheit Aufwand in komplexe Infrastruktur zu stecken, entsteht ein starker Lock-in-Effekt. Und das, obwohl es in Wirklichkeit durch unnötige Komplexität, Adressierungsunklarheit usw. der Sicherheit schadet.

    • Azure macht das komplett nach.
      Es ist kaum noch zu zählen, wie viele Produkte wie „Private Endpoints“, „Private Links“, „Service Endpoints“, „Private Resolvers“ und „Virtual WAN“ erschienen sind, und sie dienen alle dazu, IPv4 in großem Maßstab zu betreiben.
      Wenn IPv6 richtig funktionieren würde, bräuchte man buchstäblich keines dieser Produkte.
      Stattdessen betreibt Azure auch bei IPv6 NAT, sodass man IPv6 nicht einmal nutzen kann, um dem durch IPv4 erzwungenen NAT zu entgehen. Selbst 2023 bringt Azure neue Produkte heraus, die IPv6 nicht unterstützen und das wahrscheinlich auch künftig nicht tun werden.
      In der Dokumentation gibt es immer noch eine ganze Seite mit Einschränkungen: https://learn.microsoft.com/en-us/azure/virtual-network/ip-s...
      Wie absurd das ist, sieht man, wenn man sich vorstellt, es ginge um den Übergang von IPX zu IPv4. Auf dieser Seite stünde dann sinngemäß: „IPv4-Einschränkungen: Jede VM muss mindestens eine IPX-Adresse enthalten.“
      Klingt das nicht seltsam? 1999 migrierte man Kunden von IPX auf IPv4, und IPv6-Unterstützung tauchte ungefähr 2001–2003 auf. Jahrzehnte später fühlt es sich immer noch an wie die Zeit vor der Migration von Novell NetWare, als es hieß: „Noch unterstützt nicht alles IPv4, also brauchen wir IPX+IPv4.“
      Diese Liste ist keinesfalls vollständig. Da die meisten PaaS-Produkte kein IPv6 unterstützen, müssen IaaS+PaaS-Lösungen am Ende größtenteils IPv4 verwenden.
    • Das ist kein reines AWS-Problem. Microsoft, Sicherheitsauditoren, Penetrationstester, Cyberversicherer usw. verlangen im Allgemeinen ebenfalls, keine öffentlich adressierbaren Endpunkte zu haben.
      Ich verstehe nicht, warum, aber bis ein großes Technologieunternehmen End-to-End-Adressierung als Best Practice vorantreibt, bleibt einem nichts anderes übrig, als der herrschenden Meinung zu folgen, um keine Warnsignale zu erzeugen.
    • Ich arbeite bei Azure, und meiner Erfahrung nach wollen Kunden das, und sie haben auch gute Gründe dafür.
      Kunden wollen ihre eigenen privaten Netzwerke, um auch auf Maschinen, die ihnen nicht gehören, Einbrüche und Datenabfluss zu verhindern. Darüber hinaus möchten sie auch gut ausgestattete PaaS-Dienste im Rundum-sorglos-Paket in dieses Netzwerk einbinden.
    • Ich bin nicht überzeugt, dass diese beiden Dinge zusammenhängen. Wenn AWS gewollt hätte, hätte es IPv6 als Allheilmittel für alle internen Netzwerkprobleme bewerben können, und wenn es tatsächlich funktioniert hätte, wäre es für Wettbewerber schwer gewesen, aufzuholen.
      Meine Vermutung ist banaler: Angesichts der Zahl der AWS-Dienste ist IPv4-Unterstützung einfach leichter.
    • Ich verstehe nicht, inwiefern es der Sicherheit schadet, externen Zugriff auf interne Dienste zu verhindern.

  • Als AWS-Kunde möchte ich von IP selbst wegkommen. Es ist Zeitverschwendung, komplexe Netzwerksysteme zu verwalten, die aus veralteten Protokollen wie IP, BGP und DNS bestehen.
    Man sollte Workloads mit einer starken Identität verknüpfen und nur per Policy festlegen müssen, welche Workloads mit welchen Workloads Daten austauschen dürfen.
    Wie Daten von einem Workload zum anderen gelangen, sollte mich nicht interessieren müssen; es sollte einfach funktionieren.

    • Stimme vollkommen zu. Nebenbei: Genau wegen dieses Gefühls entstehen derzeit viele Cloud-„Plattformen“, die so etwas übernehmen.
      Statt in einem virtualisierten Rechenzentrum, also einem Komponentenzoo aus nachgebautem Networking, zu versinken, abstrahieren sie einfach alles weg.
    • Das Gefühl ist berechtigt, aber diese Argumentation ähnelt der Logik, die Leute bei Low-Code-Lösungen anführen.
      In der Realität hat das nie richtig funktioniert und wird es auch nicht. Um echte Workloads auszuführen und zu optimieren, gibt es viel zu viele Nuancen und Details zu berücksichtigen.
    • Auch „Big-Picture-Leute“ fangen plötzlich an, sich um Details zu kümmern, wenn das große Ganze die Details nicht löst.
    • So etwas wie Heroku? Ich habe Heroku seit Jahren nicht mehr benutzt und weiß nicht, wie der aktuelle Stand ist.
    • Du willst also das Internet ohne Internetprotokoll?

  • Aus meiner Erfahrung ist das größte Problem beim Wechsel zu IPv6-only auf AWS, dass GitHub immer noch kein IPv6 kann. Sehr viel Software setzt voraus, dass sie GitHub erreichen kann, um irgendetwas herunterzuladen.
    Man kann öffentliche NAT64-Dienste nutzen, aber für ernsthafte Zwecke sind sie nicht besonders vertrauenswürdig: https://nat64.xyz/
    AWS verlangt enorme Gebühren für NAT-Gateway-Traffic, und ich weiß nicht, ob man es so konfigurieren kann, dass nur Traffic zu IPv4-only-Hosts abgefangen wird. Falls ich falsch liege, lasse ich mich gern korrigieren.
    Abgesehen davon funktioniert IPv6-only auf AWS tadellos und ist günstiger. Egress-Gateways für private Netzwerke sind kostenlos. Natürlich unter der Voraussetzung, dass einem IPv4 egal ist.

    • Schade, dass GitHub nicht mit dem IPv6-Rollout seiner Muttergesellschaft Microsoft Schritt gehalten hat.
    • Wenn man auf AWS ein Dual-Stack-Netzwerk verwendet, bevorzugt DNS dann nicht IPv6, während IPv4 weiterhin funktioniert? So habe ich die meisten Dinge konfiguriert, die normalen Internet-Egress brauchen.

  • Meiner Meinung nach ist das eigentliche Problem, dass Lambda und S3 IPv6 nicht unterstützen. AWS hätte diese Dienste zuerst Dual-Stack-fähig machen und über IPv6 erreichbar machen sollen, bevor es die Preise ändert.
    Technisch gesehen gibt es für S3 zwar separate Dual-Stack-Endpunkte, aber das hilft nicht wirklich, weil man zur Reaktion auf diese Änderung ohnehin die Anwendungskonfiguration ändern muss.

  • Die Hälfte des Grundes, warum AWS bei der IPv6-Unterstützung überhaupt vorne liegt, ist ein politisches Mandat der US-Regierung, mit der Umstellung zu beginnen.
    Aus Kostensicht stimmt es, dass die neuen Gebühren für Großkunden nebensächlich sind, aber man sollte die Macht der politischen Vorgaben der größten Kunden nicht unterschätzen. Allein die Drohung, zur Compliance eigene Alternativen zu bauen, kann AWS letztlich dazu bringen, die Unterstützung höher zu priorisieren.

    • Stimmt. Der Gedanke gefällt mir nicht besonders, aber es scheint immer weniger andere Wege zu geben, IPv6 auf der „Server-Seite“ zu fördern.
      Auf der Client-, also Endnutzerseite, scheint es gut zu laufen. Google meldet heutzutage fast 50 % IPv6-Traffic von Endnutzern, was dafür spricht.

  • Persönlich finde ich am schlimmsten, dass CloudFront IPv6 für benutzerdefinierte Origins nicht unterstützt.
    Wenn man viele separate Fargate-Container als Origins betreibt, muss man öffentliche IPv4-Adressen aktivieren, und die Kosten kleiner Container werden sich bald verdoppeln.
    Amazon sollte erst einmal dafür sorgen, dass seine eigene Infrastruktur tatsächlich IPv6 unterstützt, bevor es Zusatzgebühren für die Nutzung von Legacy-IPv4 erhebt.

    • Stimmt. Seltsamerweise tut genau das am meisten weh.
      Ich verstehe, dass Amazon ein riesiges Monster gebaut hat und die Einführung von IPv6 über Unmengen von Diensten hinweg eine gewaltige Aufgabe ist. Aber ich sehe keinen Grund, warum CloudFront nicht schon jetzt, eigentlich schon seit gestern, IPv6-Origins unterstützen kann.
      Es wirkt im Vergleich nicht einmal so schwierig und könnte ein gutes Werkzeug sein, um andere Einschränkungen zu umgehen.
      Ehrlich gesagt hatte ich bisher das Gefühl, dass Amazons Entscheidungen am Ende die besten Interessen der Kunden im Blick haben. Jetzt nicht mehr. Ich sehe das als schlechtes Zeichen für die Zukunft.

  • Es hätte sehr geholfen, wenn es in den USA echten ISP-Wettbewerb gäbe.
    Wo ich zur Miete wohne, in einem Vorort nahe Seattle, gibt es trotz allem nur einen echten Breitband-ISP. Nach keiner Definition ist das ländlich, aber Comcast ist die einzige Option. Preise und Service spiegeln diese Realität genau wider.

    • Dafür darf man dem endlosen Lobbying danken, das in diesem Bereich gesetzlich erzwungene Monopole möglich gemacht hat. Bei den Telefongesellschaften lief es genauso.
      Es ist nicht zufällig „nur Comcast“, sondern durch Regulierung rechtlich zu „nur Comcast“ gemacht worden.
    • Comcast unterstützt IPv6. 2016 erreichten sie 98 % IPv6-Unterstützung.
    • Verbraucher kennen IPv6 weder noch interessiert es sie, daher wird Wettbewerb die Implementierung durch ISPs nicht vorantreiben.
      Das Lustige an Beschwerden über Comcast ist: Als ich Comcast nutzte, hatte ich natives IPv6. Mein aktueller Anbieter hat IPv6 nur über NAT46.
    • Starlink könnte eine weitere Option sein.
      Es gibt Nachteile wie Leistungseinbußen bei starkem Regen, aber ich habe auch einige positive Erfahrungsberichte gesehen.
    • Die IPv6-Einführung wird Kunden noch stärker zu den großen Monopolisten treiben, weil nur sie sich dedizierte Network-Engineering-Teams leisten können, die dafür sorgen, dass es zuverlässig funktioniert.
      Die meisten wissen nicht, dass es derzeit zwei IPv6-Internets gibt: eines auf der Cogent-Seite und eines auf der Hurricane-Electric-Seite. Beide sind ähnlich groß und weigern sich, sich miteinander zu verbinden. Man muss das also wissen und Transit von beiden kaufen oder bei einem Netzwerk kaufen, das Transit von beiden bezieht.
      Mindestens ein großer Anbieter, den ich kenne, betreibt v6 immer noch über Tunnel. An vielen Orten nimmt v6-Traffic suboptimale Routen, und Unternehmensnetzwerke haben vielleicht in jedem Rechenzentrum v4-Konnektivität, schicken aber v6 komplett über „die Kiste unter Daves Schreibtisch“.
      Trotzdem messen Orte wie Google oder Cloudflare, die dedizierte Teams haben, die die Zustellung von Paketen sicherstellen, die v6-Einführung und klopfen sich dafür selbst auf die Schulter.

  • Die Formulierung „nicht von IPv4 loskommen“ ist treffend. Man kann zwar eine IPv6-only-VPC erstellen, aber von zahlreichen AWS-Services bis hin zu Paket-Repositories geht dabei viel zu viel kaputt: https://blog.devopstom.com/ipv6-only-ec2/
    Am Ende muss man entweder IPv4 aktivieren, selbst ein NAT64-Gateway betreiben oder einem von jemand anderem betriebenen NAT64 vertrauen: https://nat64.net und http://v4-frontend.netiter.com

  • Die Aussage „Da es bei IPv6 kein Konzept privater Adressen gibt, kann man sich vom Managed NAT Gateway und seinen majestätischen Preisen verabschieden“ mag innerhalb von AWS zutreffen, aber bei IPv6 gibt es Unique Local IPv6 Addresses in fc00::/7, und wenn man NAT wirklich liebt, gibt es auch NAT66

    • Stimmt, das bezog sich auf AWS, und das hätte klarer gesagt werden müssen
      Allerdings wird ULA häufig nicht empfohlen, und NAT66 ist … einfach keine gute Idee
      Nach dem, was ich kürzlich gehört habe, soll Microsoft IPv6 in Azure komplett NAT-zentriert aufgebaut haben. Wirklich seltsam