Hallo Clemens,<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

kurzes Update: Ich hab beschlossen den Tunnelserver als v6-Roofnode und<br>
Tunnelkonzentrator zu verwenden, nachdem der eh einen Serveradmin braucht<br>
und genau diese Aufgabe auf lange Zeit gesehen sowieso bekommen wird.<br></blockquote>find' ich super, weil's eine langfristig sinnvolle Sache ist!<br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Allerdings bin ich mit dem v6 Subnetting nicht wirklich voll zufrieden, mehr<br>
als ein /64 für 1-IP nodes wäre schon nett. Da wir später wohl nur relativ<br>
schwer ein renumbering machen können werden hätt ich das gern vorher<br>
diskutiert.<br></blockquote><div>Gemäß <a href="http://tools.ietf.org/html/rfc6177">http://tools.ietf.org/html/rfc6177</a> 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]<br>
<br>Es sollte mindestens zwei Möglichkeiten geben:<br> a) /64 sollte die kleinste vergebene Einheit bleiben (tun wir jetzt auch schon so)<br> 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).<br>
<br>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]<br>
/56 erfüllt IMHO die Kriterien.<br><br>Mit /56 hat ein Benutzer/in die Möglichkeit 8 Bit in Netzen zu nutzen = 256 Netze am Standort.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Zugewiesen ist uns 2a02:60::/32, assigned haben wir momentan 2a02:60:1::/48<br>
bis 2a02:60:5::/48<br>
Davon für das Funknetz:<br>
2a02:60:3::/48<br>
    2a02:60:3:7000::/55 = 2a02:60:3:(112.0/23)::/64<br>
    2a02:60:3:9c00::/54 = 2a02:60:3:(156.0/22)::/64<br>
printf "2a02:60:3:%02x%02x::1" $(echo $MY_IP | cut -d. -f3,4 | tr . ' '); echo<br>
<br>
Ist relativ simpel, aber lässt sich das eventuell besser nutzen?<br></blockquote><div>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.<br>
<br>Ich werf' mal folgende Idee in die Diskussion:<br>Es soll zwei mögliche IPv6-Bereiche geben, die Benutzer über den Redeemer registrieren können:<br> - /64 als Pendant zu den jetzigen IPv4-Host-Adressen, wird automatisch zu jeder IPv4-/32 vergeben.<br>
 - /56 optional wenn jemand ein Netz möchte.<br><br>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:<br>
 - 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.<br> - es ist optisch besser erkennbar: ::6/48 sind Netze ::3/48 sind Hosts, Interfaces, Linknetze etc.<br>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

IMHO wäre es auch nicht schlimm ein /44 her zu nehmen und mit selbigem<br>
Mechanismus somit jeder IP ein /60 zuzuweisen, nachdem das eh nur 1/4096<br>
des /32 ist.<br></blockquote><div>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.<br><br>Ich fühle mich durch den OLSR dabei bestärkt:<br>
 - 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.<br> - 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. ;)<br>
<br>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.<br>
<br>Was meint ihr?<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Lg,<br>
Clemens<br></blockquote><div>LgS<br><br></div></div>