[IPv6-wien] IPv6 subnetting

Sat Sep 29 01:50:47 CEST 2012

Hallo Clemens, Stefan und Liste!

Moment, ich stehe auf der Leitung.

Clemens, das „alte“ Modell des partiellen Mapping unserer V4 Adressen in den V6 Raum habe ich verstanden. So weit so gut und alles klar.

Aber was genau ist nun Dein Verbesserungsvorschlag???

Beim Betrachten der dritten Ziffer unserer V4 Adressen (112-119 und 156-159) fällt auf, dass diese eine AND Maskierung mit 0x3F vertragen würden, ohne zu überlappen. Damit würde man 2 Bit gewinnen. Das bedeutet also 2a02:60:3:1Cxx:: - 2a02:60:3:1Fxx:: und 2a02:60:3:30xx:: - 2a02:60:3:37xx:: /64. Man könnte jede unserer V4 Adressen viermal im „3“er Segment abbilden. Bezweifle aber selbst, ob das irgendeinen sinnvollen Gewinn macht…

Noch ein anderes Fallbeispiel. Stellen wir uns einen kleinen Transit Knoten vor, bestehend aus einem Bullet2 und einem Bullet 5. In traditioneller V4 Architektur würde so ein Konstrukt 4 IP Adressen benötigen. Wollen wir für derartige Kleinanlagen in V6 (auf Grund unserer Mapping Formel) dafür tatsächlich vier /64 Adressräume belegen? Ich verstehe schon, es ist cool verschwenden zu können, aber innovativ finde ich das nicht.

Denken wir versuchsweise in eine ganz andere Richtung: Ein Präfix pro Node Standort. Daraus würden Router und Interfaces IDs rausmaskiert. Welche Vor- und Nachteile hätte der Ansatz?

Grüße Gottfried

PS: @Stefan: Joe hat das RouterBoard mit einem neuen Image geflasht. Funktioniert leider noch immer nicht, obwohl genau gleich konfiguriert wie am AirRouter, wo es funktioniert. Blöde G’schicht…

Von: (spam-protected) [mailto:(spam-protected)] Im Auftrag von Stefan Schultheis (home)
Gesendet: Donnerstag, 27. September 2012 08:12
An: Clemens Hopfer
Cc: (spam-protected)
Betreff: Re: [IPv6-wien] IPv6 subnetting

Hallo Clemens,

kurzes Update: Ich hab beschlossen den Tunnelserver als v6-Roofnode und
Tunnelkonzentrator zu verwenden, nachdem der eh einen Serveradmin braucht
und genau diese Aufgabe auf lange Zeit gesehen sowieso bekommen wird.

find' ich super, weil's eine langfristig sinnvolle Sache ist!

Allerdings bin ich mit dem v6 Subnetting nicht wirklich voll zufrieden, mehr
als ein /64 für 1-IP nodes wäre schon nett. Da wir später wohl nur relativ
schwer ein renumbering machen können werden hätt ich das gern vorher
diskutiert.

Gemäß http://tools.ietf.org/html/rfc6177 hast du damit auch recht! ;) [Jeder sollte die Möglichkeit haben, allein durch Aufzeigen/Anfragen eine Anzahl an IPv6-Adressen zu erhalten, die auch langfristig ausreichen, eher in Jahren als in Monaten gedacht, frei aus dem RFC übersetzt]

Es sollte mindestens zwei Möglichkeiten geben:
 a) /64 sollte die kleinste vergebene Einheit bleiben (tun wir jetzt auch schon so)
 b) es sollte die Möglichkeit geben, Netze zu erhalten; die alte Empfehlung (rfc3177) dafür war /48, aktuell dürfte man über /56 sprechen (rfc6177).

Zu berücksichtigen wäre: wollen wir zukünftig Reverse-DNS-Zonen delegieren? Wenn jemand mehrere Netze bekommt, soll er/sie dann die Möglichkeit haben eigene Reverse DNS-Server dafür zu betreiben? Das würde sich auf's Subnetting auswirken, weil man nicht beliebig zwischen den Bits delegieren kann. [Vgl. IPv4: wenn man ein /29 delegiert, wird reverse DNS immer noch auf /24-Basis gefahren]
/56 erfüllt IMHO die Kriterien.

Mit /56 hat ein Benutzer/in die Möglichkeit 8 Bit in Netzen zu nutzen = 256 Netze am Standort.

Zugewiesen ist uns 2a02:60::/32, assigned haben wir momentan 2a02:60:1::/48
bis 2a02:60:5::/48
Davon für das Funknetz:
2a02:60:3::/48
    2a02:60:3:7000::/55 = 2a02:60:3:(112.0/23)::/64
    2a02:60:3:9c00::/54 = 2a02:60:3:(156.0/22)::/64
printf "2a02:60:3:%02x%02x::1" $(echo $MY_IP | cut -d. -f3,4 | tr . ' '); echo

Ist relativ simpel, aber lässt sich das eventuell besser nutzen?

Schwer zu sagen. Ich finde das Modell recht praktisch, es ist über ein /55 und /54 auch gut abgegrenzt und lässt sich gut umsetzen.

Ich werf' mal folgende Idee in die Diskussion:
Es soll zwei mögliche IPv6-Bereiche geben, die Benutzer über den Redeemer registrieren können:
 - /64 als Pendant zu den jetzigen IPv4-Host-Adressen, wird automatisch zu jeder IPv4-/32 vergeben.
 - /56 optional wenn jemand ein Netz möchte.

Die /56 kann ein User bei Bedarf beantragen und die werden aus einem separaten Pool genommen. Entweder wir reißen ein neues /48 dafür an (zB. 2a02:60:6::/48) oder wir nutzen das restliche 2a02:60:3::/48. Ich wäre eher für ein neues /48, weil:
 - sobald wir ein weiteres IPv4-Assignment bekommen, können wir (mit etwas Glück) im :3::/48 wieder einen Block haben, aus dem wir weitere /64 vergeben.
 - es ist optisch besser erkennbar: ::6/48 sind Netze ::3/48 sind Hosts, Interfaces, Linknetze etc.

IMHO wäre es auch nicht schlimm ein /44 her zu nehmen und mit selbigem
Mechanismus somit jeder IP ein /60 zuzuweisen, nachdem das eh nur 1/4096
des /32 ist.

Wäre auch gültig, ich würde aber vielleicht trotzdem nur denen ein Netz (/56 wäre dazu meine Empfehlung; vgl. Reverse DNS) vergeben, die's wirklich haben wollen.

Ich fühle mich durch den OLSR dabei bestärkt:
 - ich habe gesehen, dass obwohl ich ein /64 auf meinen Interfaces konfiguriere, der OLSR *immer* nur /128 übernimmt. Wenn man /64 wirklich routen will, muss man ein Hna6 einrichten.
 - wenn jemand in Zukunft ein Netz /56 möchte, wird man um diesen manuellen Konfig-Schritt (Hna6) nicht herumkommen. Das Schöne daran: müsste bereits heute über LuCI, als elegant über's Webinterface, funktionieren. ;)

Heißt: IPv6 /64 für jeden IPv4 /32 automatisch mitvergeben, für Netze gibt's eine zusätzliche Registrierungsmöglichkeit, die wird aber auch weiterhin mit einem zusätzlichen Konfigurationsschritt auf den Routern verbunden sein.

Was meint ihr?

Lg,
Clemens

LgS

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.funkfeuer.at/pipermail/ipv6-wien/attachments/20120929/baf97271/attachment.html>