QVINTVS · SCRIBET

Die RFC ist falsch

Das Ergebnis einer Auseinandersetzung mit IPv6 und SLAAC.

Seit geraumer Zeit habe ich mein Netzwerk auf IPv6 aufgerüstet, wobei ich ein /64er-Netzwerk verwende, das mir von SixXS zugeteilt wurde. Zu diesem Zweck gibt es bekanntermaßen drei Ansätze:

  1. Vollständige Autokonfiguration mittels Router Advertsisement (SLAAC) und RDNSS (sog. stateless-Modus)
  2. Adressautokonfiguration mit Router Adverstisement (SLAAC), DNS und anderes per DHCPv6
  3. Alles über DHCPv6 bis auf die Routinginformationen (sog. stateful-Modus)

Der konservative Ansatz ist Nummer 3, da er weitestgehend (bis auf die Routinginformationen) dem entspricht, was heute schon DHCPv4 macht. Das ist auch das Setup, das ich momentan in meinem eigenen Heimnetzwerk nutze.

Heute kam der Tag, an dem ich dachte, ich gebe SLAAC in Form der zweiten Variante mal eine ernsthafte Chance. Der IPv4-Teil meines Netzwerks ist seit jeher aufgeteilt in vier Subnetze, von denen eines für das Kabelnetz und ein anderes für das WLAN-Netz verwendet wird, die zwei anderen Subnetze werden anderweitig verwendet. Das IPv6-Netz hatte ich im Wege der stateful-Konfiguration ebenfalls in Subnetze eingeteilt, von denen ein /80 für das Kabelnetz und ein /80 für das WLAN-Netz in Benutzung waren. Trotzdem waren noch immer Millionen von IPv6-Adressen übrig, für die ich keine Verwendung hatte. Es ist ausgesprochen selten, dass bei mir mal mehr als 20 Clients gleichzeitig online sind, daher erschien mir schon das als unnötige Verschwendung. Eigentlich hätte ich noch kleinere Subnetze wählen sollen.

Der logische Schritt war es nun also, meine bestehende /80er-Konfiguration auf SLAAC zu übetragen. Liebevoll fertigte ich folgende Konfiguratiosdatei für radvd:

interface eth0 {
  # Advertise
  AdvSendAdvert on;

  # Maximum time between RAs
  MaxRtrAdvInterval 60;

  # Instruct clients to query a DHCPv6 server for configuration
  # other than addresses
  AdvOtherConfigFlag on;

  # This would clients make query a DHCPv6 server for an address.
  # They may *additionally* do SLAAC if not disabled by "AdvAutonomous off"
  # on a prefix!
  # AdvManagedFlag on;

  # The prefix to advertise here.
  prefix XXXXXXX:8918:1::/80 {
    # Allow SLAAC for this prefix
    AdvAutonomous on;

    # We are the only router. If we shut down, nobody else can route
    # this prefix -- tell clients about this.
    DeprecatePrefix on;
  };
};

Das sah einleuchtend aus. Die Clients sollten per SLAAC sich selbst eine Adresse konfigurieren und sich Infos wie den DNS-Server beim DHCPv6-Server, in meinem Falle dnsmasq, abholen. Doch alles kam anders. Statt Router Advertisements zu senden, spammte radvd mein Syslog zu:

radvd[27045]: [Jan 17 23:16:04] radvd: prefix length should be 64 for eth0
radvd[27045]: [Jan 17 23:16:45] radvd: prefix length should be 64 for eth0
radvd[27045]: [Jan 17 23:17:23] radvd: prefix length should be 64 for eth0
radvd[27045]: [Jan 17 23:18:15] radvd: prefix length should be 64 for eth0
radvd[27045]: [Jan 17 23:18:53] radvd: prefix length should be 64 for eth0
radvd[27045]: [Jan 17 23:19:19] radvd: prefix length should be 64 for eth0

Bitte was? Ich will keine /64er-Subnetze. Abgesehen davon, dass es eine ungeheure Verschwendung von noch vielen Millionen mehr an IP-Adressen wäre, habe ich auch nur ein einziges /64er-Netz zur Verfügung. Was soll ich damit?

Internetrecherche brachte dabei Dinge zu Tage, die ich nicht für möglich gehalten hätte. Als hätte man aus der Adressknappheit von IPv4 und der großzügigen Vergabe von IPv4-Adressen in den ersten Tagen nichts, aber auch gar nichts gelernt, zwingt die IETF die Implementatoren von SLAAC dazu, Subnetze kleiner als /64 schlicht nicht anzuerkennen. In RFC5375 gibt die IETF in meinen Augen eine absolute Bankrotterklärung ab:

Using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts of Mobile IPv6 [RFC4866], Protocol Independent Multicast - Sparse Mode (PIM-SM) with Embedded-RP [RFC3956], and Site Multihoming by IPv6 Intermediation (SHIM6) [SHIM6], among others. A number of other features currently in development, or being proposed, also rely on /64 subnet prefixes.

Die IETF erkennt hier also ernstlich an, dass sie Protokolle designed hat, die kaputt sind, unfähig, andere Präfixe als /64 zu verwalten, leistet mit offenen Armen der nächsten Adressverschwendung Vorschub. Mir hat es die Sprache verschlagen. Noch haben wir die Adressen ja. Statt wie weiland Klasse-A-Netze verteilen wir jetzt halt /48er einfach so, ohne Not. Es lässt sich also eindeutig sagen: Es ist nicht etwa so, dass die IPv6-SLAAC-Implementierungen kaputt sind. Nein, das Übel liegt viel tiefer: Die RFC ist zutiefst falsch designed, ist verantwortungslos. Ganz allein scheine ich mit dieser Auffassung nicht zu sein, dieser Mensch hier ist über dasselbe Problem gestolpert, hat dann aber resiginiert:

I was doing v4 networks before CIDR, when it was all classful, and this looks to me like the same stupid idea […]. […] we can parcel up the network in gigantic chunks (class A, anyone?) […], because hey, address space is huge, we’ll never run out. A /64 holds over ten billion billion IPv6 addresses. It’s rampant fucking insanity to assume that’s the “basic unit” of networking, that noone would ever want to split up a v6 network any smaller than that. This smacks of MicroSoft and Apple […]. Thanks guys.

Ich werde das jedenfalls nicht mittragen. Da bleibe ich doch lieber bei meiner stateful-Konfiguration, die auch ganz hervorragend mit kleineren Präfixlängen klarkommt. Das kann dnsmasq sogar ganz allein, sodass ich radvd wieder deinstallieren kann.

Valete.