<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.E-MailFormatvorlage17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=DE-AT link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hallo Clemens, Stefan und Liste!<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Moment, ich stehe auf der Leitung.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Clemens, das „alte“ Modell des partiellen Mapping unserer V4 Adressen in den V6 Raum habe ich verstanden. So weit so gut und alles klar.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Aber was genau ist nun Dein Verbesserungsvorschlag???<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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…<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Grüße Gottfried<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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…<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span lang=DE style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>Von:</span></b><span lang=DE style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> ipv6-wien@lists.funkfeuer.at [mailto:ipv6-wien@lists.funkfeuer.at] <b>Im Auftrag von </b>Stefan Schultheis (home)<br><b>Gesendet:</b> Donnerstag, 27. September 2012 08:12<br><b>An:</b> Clemens Hopfer<br><b>Cc:</b> ipv6-wien@lists.funkfeuer.at<br><b>Betreff:</b> Re: [IPv6-wien] IPv6 subnetting<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'>Hallo Clemens,<o:p></o:p></p><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><p class=MsoNormal>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.<o:p></o:p></p></blockquote><p class=MsoNormal>find' ich super, weil's eine langfristig sinnvolle Sache ist!<o:p></o:p></p><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><p class=MsoNormal>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.<o:p></o:p></p></blockquote><div><p class=MsoNormal>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> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><p class=MsoNormal>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?<o:p></o:p></p></blockquote><div><p class=MsoNormal>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> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><p class=MsoNormal>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.<o:p></o:p></p></blockquote><div><p class=MsoNormal style='margin-bottom:12.0pt'>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?<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><p class=MsoNormal>Lg,<br>Clemens<o:p></o:p></p></blockquote><div><p class=MsoNormal style='margin-bottom:12.0pt'>LgS<o:p></o:p></p></div></div></div></body></html>