[IPv6-wien] IPv6 subnetting

Sun Sep 30 16:58:11 CEST 2012

Hi,

bitte lies das:

http://www.ripe.net/lir-services/training/material/IPv6-for-LIRs-Training-Course/IPv6_addr_plan4.pdf

In dem Text ist sowohl das partielle V4 Mapping als auch standort- und VLAN/VPN basierende Adressierungsansätze beschrieben.

Ja, genau, die NodeID zu verwenden, liegt geradezu auf der Hand! Nein, so schnell würde ich diese Variante nicht als unrealisierbar verwerfen. In meinen Augen, hätte das schon Charme.

OK, gebe zu, ich habe keine Ahnung, in wie weit der Redeemer mit V6 umgehen kann. Dass hier Anpassungen gebraucht werden, scheint klar. Seit dem ich bei Funkfeuer dabei bin, wird vom Redeemer2 gesprochen. Never ending Story... 

Habe mir gerade überlegt, Deine Ausführungen in einer Tabelle darzustellen. Hast Du einen Account, um auf Google Docs zuzugreifen?

Gottfried 

Von: (spam-protected) [mailto:(spam-protected)] Im Auftrag von Stefan Schultheis (home)
Gesendet: Sonntag, 30. September 2012 10:54
An: (spam-protected)
Betreff: Re: [IPv6-wien] IPv6 subnetting

Hallo v6-Liste,

> 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?
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!

Gedankenspiel konkretisiert, wie könnte ein Design dann aussehen:
 - 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).
 - 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)
 - dann könnte man die Interface ID im LuCI automatisch über EUI-64 anhand der "eindeutigen" MAC-Adresse ableiten:
   2a02:60:7:7b1:20c:29ff:fead:2a39/128 für mein Interface mit der MAC Adresse 00:0c:29:ad:2a:39
 - 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, ...

Nachteil dieser Variante:
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.

Weiterer Gedanke:
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.

Vorteil:
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...

Was tun wir mit Sites, die (Sub-)netze benötigen, Annahme:
-) die NodeID ist 16 Bit, ermöglicht 65535 Nodes.
-) das Zielnetz ist ein /56, das je Standort möglich sein soll (= 256 Netze je Site), also 8 Bit.

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.

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.

Fazit:
Mir gefällt das eigentlich sehr gut so. 
- Vorteil: Unabhängigkeit von IPv4, Skalierbarkeit und Effizienz. 
- 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". ;)

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.

Was meint ihr?

LgS

Am 30. September 2012 01:51 schrieb Clemens Hopfer <(spam-protected)>:

Hi,

IPV6 ist durch den großen Adresspool extrem gut geeignet um Hierarchien
abzubilden und damit in normalen Netzwerken mit verschiedenen
Netzwerkebenen sehr sauber die physische oder logische Netzstruktur
abzubilden, was eine sehr übersichtliche Topologie schafft.

Soetwas haben wir in unserem Netz allerdings nicht, damit fällt für uns das
typisch übliche Subnetting weg.

Natürlich kann man sich später überlegen ob man z.B. die NodeID oder deviceID
in die Adresse kodieren will.
Datenschutztechnisch sehe ich das etwas anders: Je weniger man aus einer
einzelnen IP herauslesen kann, umso besser finde ich.

Auch wenn ein renumbering nicht gerade lustig ist, ists wohl nur halb so
schlimm, weil wir sie aktuell sowieso automatisch generieren. Eine neue
Adresskonfiguration ist nur ein update eines Pakets bzw. ein Firmwareupdate im
schlimmsten Fall.
Da es vorerst nur ein Test ist und wir das v4 Routing der Geräte nicht
angreifen sind sogar Fehlkonfigurationen ziemlich unproblematisch.

Lg,
Clemens

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