Hallo v6-Liste,<br><br>> Beim Betrachten der dritten Ziffer unserer V4 Adressen<br>> (112-119 und 156-159) fällt auf, dass diese eine <br>> AND Maskierung mit 0x3F vertragen würden, ohne zu <br>> überlappen. Damit würde man 2 Bit gewinnen. Das bedeutet <br>
> also 2a02:60:3:1Cxx:: - 2a02:60:3:1Fxx:: <br>> und 2a02:60:3:30xx:: - 2a02:60:3:37xx:: /64. Man<br>> könnte jede unserer V4 Adressen viermal im „3“er Segment<br>> abbilden. Bezweifle aber selbst, ob das irgendeinen<br>
> sinnvollen Gewinn macht…<br>Würde das auch skalieren wenn wir einen dritten IPv4-Bereich bekommen? Das ist eine Frage an die Glaskugel, aber die Wahrscheinlichkeit eines Konflikts ist größer als bei der gewöhnlichen Methode (die ja weltweit angewandt wird und nicht eine Erfindung von Funkfeuer ist!).<br>
Der Gewinn von 2 Bit erscheint mir zu wenig um den Standard zu verlassen und die Komplexität zu erhöhen.<br><br>> Denken wir versuchsweise in eine ganz andere Richtung:<br>> Ein Präfix pro Node Standort. Daraus würden Router<br>
> und Interfaces IDs rausmaskiert. Welche <br>> Vor- und Nachteile hätte der Ansatz?<br>Ich glaube die wesentlichen Vorteile dieses Ansatzes wären die Effizienz in der Nutzung der IPv6-Resourcen und die Unabhängigkeit von IPv4! Die Idee hat seinen Reiz!<br>
<br>Gedankenspiel konkretisiert, wie könnte ein Design dann aussehen:<br> - man könnte je Standort einen einzelnen /64-Prefix vergeben. Diesen würde ich dann nicht mehr von einer IPv4-Adresse mappen sondern von einer anderen eindeutigen ID, da würde sich die NodeID im Redeemer anbieten. Mein Standort ist hohl28, der hat NodeID 1969 (= 0x7b1). Alternativ kann man's fortlaufend vergeben (vgl. Clemens' Bedenken bzgl. Datenschutz).<br>
 - das wäre dann zB: 2a02:60:7:7b1::/64 (sorry, habe ...:7:/48 augeborgt damit's klar ist, dass es ein neues Design ist)<br> - dann könnte man die Interface ID im LuCI automatisch über EUI-64 anhand der "eindeutigen" MAC-Adresse ableiten:<br>
   2a02:60:7:7b1:20c:29ff:fead:2a39/128 für mein Interface mit der MAC Adresse 00:0c:29:ad:2a:39<br> - falls jemand eine "schöne" (= "human readable") Adresse vergeben möchte (zB für Server, bei denen sich die Netzwerkkarte über die Zeiten ändern wird, und es daher nicht sinnvoll ist, die IPv6 aus der MAC-Adresse zu generieren), kann man immer noch frei durchzählen: 2a02:60:7:7b1::1/128, 2a02:60:7:7b1::2/128, 2a02:60:7:7b1::3/128, ...<br>
<br>Nachteil dieser Variante:<br>Entweder der User pflegt revDNS selbst, oder wir brauchen ein komplexeres Interface im Redeemer, wo der User seine benutzten IP6s eintragt, damit wir einen Namen im DNS hinterlegen können.<br>
<br>Weiterer Gedanke:<br>Die MAC-Adresse ist nach außen erkennbar und man legt somit Details zum verwendeten Equipment offen. Jedem ist klar, dass das System in meinem Beispiel oben ein VMWare Gast ist (MAC beginnt mit 00:0c:29...). Das könnte man noch scramblen, wodurch die MAC-Adresse nicht mehr erkennbar wäre und man höchstwahrscheinlich immer noch eindeutig wäre.<br>
<br>Vorteil:<br>diese Methode ist unabhängig von IPv4. Nachdem ich davon ausgehe, dass Funkfeuer in 10 Jahren dann wirklich keine IPv4-Adressen mehr zur Verfügung hat, braucht man eh eher so eine Methode als etwas, das IPv4 voraussetzt...<br>
<br>Was tun wir mit Sites, die (Sub-)netze benötigen, Annahme:<br>-) die NodeID ist 16 Bit, ermöglicht 65535 Nodes.<br>-) das Zielnetz ist ein /56, das je Standort möglich sein soll (= 256 Netze je Site), also 8 Bit.<br><br>
Da müssen wir jetzt eigentlich ein /40 für Subnetze im Adressplan vorsehen. Dadurch könnte sich das og. Design wieder ad absurdum führen weil wir 256 /48 für die Netze belegen würden. Das Design mit der NodeID lässt sich hier also nicht umsetzen.<br>
<br>Ich würde also diese Netze frei bzgl. fortlaufend vergeben und zwar aus einem /48. Damit sind mal 256 Standorte möglich, die wiederum 256 Subnetze nutzen könnten. Danach müssten wir das nächste /48 anreißen.<br><br>Fazit:<br>
Mir gefällt das eigentlich sehr gut so. <br>- Vorteil: Unabhängigkeit von IPv4, Skalierbarkeit und Effizienz. <br>- Nachteil: die Dokumentation wird leiden... Und das wird über RevDNS sichtbar werden. Aber: dieses Problem werden wir vmtl. sowieso haben, sobald wir uns von IPv4 abkoppeln. Dem könnten wir uns jetzt auch gleich "stellen". ;)<br>
<br>Ganz sicher bin ich auch noch nicht, ob man die NodeID verarbeiten soll oder einfach die Adresse fortlaufend vergeben sollte: First Come, First Serve. Sowohl für /64 als auch für /56.<br><br>Was meint ihr?<br><br>LgS<br>
<br><div class="gmail_quote">Am 30. September 2012 01:51 schrieb Clemens Hopfer <span dir="ltr"><<a href="mailto:datacop@wireloss.net" target="_blank">datacop@wireloss.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
IPV6 ist durch den großen Adresspool extrem gut geeignet um Hierarchien<br>
abzubilden und damit in normalen Netzwerken mit verschiedenen<br>
Netzwerkebenen sehr sauber die physische oder logische Netzstruktur<br>
abzubilden, was eine sehr übersichtliche Topologie schafft.<br>
<br>
Soetwas haben wir in unserem Netz allerdings nicht, damit fällt für uns das<br>
typisch übliche Subnetting weg.<br>
<br>
Natürlich kann man sich später überlegen ob man z.B. die NodeID oder deviceID<br>
in die Adresse kodieren will.<br>
Datenschutztechnisch sehe ich das etwas anders: Je weniger man aus einer<br>
einzelnen IP herauslesen kann, umso besser finde ich.<br>
<br>
Auch wenn ein renumbering nicht gerade lustig ist, ists wohl nur halb so<br>
schlimm, weil wir sie aktuell sowieso automatisch generieren. Eine neue<br>
Adresskonfiguration ist nur ein update eines Pakets bzw. ein Firmwareupdate im<br>
schlimmsten Fall.<br>
Da es vorerst nur ein Test ist und wir das v4 Routing der Geräte nicht<br>
angreifen sind sogar Fehlkonfigurationen ziemlich unproblematisch.<br>
<br>
Lg,<br>
Clemens<br>
<br>
Am Samstag, 29. September 2012, 10:20:16 schrieb Gottfried Motowidlo:<br>
<div class="HOEnZb"><div class="h5">> Hi allerseits!<br>
><br>
> Wir haben hier und jetzt die einzigartige Chance, mit einem Funkfeuer V6<br>
> Adressierungskonzept auf einer ziemlich grünen Wiese, nahe bei null zu<br>
> beginnen. Soweit ich weiß, sind in unserem riesigen /32 Adressraum<br>
> schätzungsweise zwei Dutzend Hosts wirklich online, die in unseren<br>
> Überlegungen zu beachten sind.<br>
><br>
> Ohne jemandem etwas ein- oder ausreden zu wollen plädiere ich für die<br>
> Freiheit im Kopf! Wir sollten die Gelegenheit nützen, über verschiedene<br>
> Verwaltung- und Vergabevarianten nachzudenken, deren Vor- und Nachteile<br>
> abzuwägen, um eine für uns optimale V6 Architektur zu finden. In diesem Sinn<br>
> bin ich ganz und gar nicht gegen unser V4 Mapping Modell. Es muss aber<br>
> möglich sein, auch dieses zu hinterfragen und es nicht als einzig<br>
> mögliches, in Stein gemeißeltes Dogma anzusehen.<br>
><br>
> Unter dem Stichwort "ipV6 addressing" kennt Google Berge von Literatur zu<br>
> den weiteren Schlagworten "scheme", "architecture", "plan", "assignment".<br>
> Ich werde jetzt ein bisserl nachlesen gehen...<br>
><br>
><br>
> Grüße Gottfried<br>
><br>
><br>
> -----Ursprüngliche Nachricht-----<br>
> Von: <a href="mailto:ipv6-wien@lists.funkfeuer.at">ipv6-wien@lists.funkfeuer.at</a> [mailto:<a href="mailto:ipv6-wien@lists.funkfeuer.at">ipv6-wien@lists.funkfeuer.at</a>] Im<br>
> Auftrag von Clemens Hopfer<br>
> Gesendet: Samstag, 29. September 2012 02:37<br>
> An: <a href="mailto:ipv6-wien@lists.funkfeuer.at">ipv6-wien@lists.funkfeuer.at</a><br>
> Betreff: Re: [IPv6-wien] IPv6 subnetting<br>
><br>
> Am Samstag, 29. September 2012, 01:50:47 schrieb Gottfried Motowidlo:<br>
> > Denken wir versuchsweise in eine ganz andere Richtung: Ein Präfix pro<br>
> > Node Standort. Daraus würden Router und Interfaces IDs rausmaskiert.<br>
> > Welche Vor- und Nachteile hätte der Ansatz?<br>
><br>
> Das ist Langfristig sicher das Ziel, aber die Grundidee die Adressen direkt<br>
> zu mappen ist, dass wir keiner weitere Vergabe von IP-Adressen brauchen.<br>
><br>
> Die Grundidee so einen großen Adressraum bei IPV6 zu haben ist die<br>
> Konfiguration massiv einfacher zu machen und nicht um jedes einzelne<br>
> vergeudete Subnet kämpfen zu müssen.<br>
><br>
> Wenn es noch einen Parameter zum Eintragen in Frontend und Geräten gibt,<br>
> wird das niemand machen.<br>
> Ein Paket dazu zu installieren, dass sich die Konfiguration selber macht ist<br>
> schnell getan, idealerweise später dann auch default mäßig dabei und<br>
> aktiviert.<br>
><br>
> Am Donnerstag, 27. September 2012, 08:11:51 schrieb Stefan Schultheis:<br>
> > Ich fühle mich durch den OLSR dabei bestärkt:<br>
> >  - ich habe gesehen, dass obwohl ich ein /64 auf meinen Interfaces<br>
> ><br>
> > konfiguriere, der OLSR immer nur /128 übernimmt. Wenn man /64 wirklich<br>
> > routen will, muss man ein Hna6 einrichten.<br>
><br>
> Das kommt daher, dass der OLSRd bei der main-IP und MIDs nur Adressen<br>
kennt,<br>
> keine Subnetze.<br>
><br>
> Am Donnerstag, 27. September 2012, 08:11:51 schrieb Stefan Schultheis:<br>
> > Heißt: IPv6 /64 für jeden IPv4 /32 automatisch mitvergeben, für Netze<br>
> > gibt's eine zusätzliche Registrierungsmöglichkeit, die wird aber auch<br>
> > weiterhin mit einem zusätzlichen Konfigurationsschritt auf den Routern<br>
> > verbunden sein.<br>
><br>
> Jep, wollte nur die Frage in den Raum stellen, ob es Sinn macht von Anfang<br>
> an größere Subnetze zu vergeben, die manuelle Vergabe wirds langfristig<br>
> sowieso geben.<br>
><br>
> Aber wenn mans genau nimmt ist ein /64 eh irrwitzig, um jede Adresse davon<br>
> abbilden zu wollen würde bräuchte man einen Adresstable von<br>
> 16*2^64/(10^18)=295 Exabyte.<br>
><br>
> Lg,<br>
> Clemens<br></div></div></blockquote></div><br>