[IPv6-wien] IPv6 subnetting

[Stefan Schultheis (home)]

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/20120927/a1adfce2/attachment.html>