[IPv6-wien] IPv6 subnetting

Sun Sep 30 17:16:44 CEST 2012

Hallo Gottfried,

Am 30. September 2012 16:58 schrieb Gottfried Motowidlo <(spam-protected)>:

> 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.
>
Das RFC6177 vom März 2011 hebt die Empfehlung auf, /48 zu verwenden, so
wie's in deinem Dokument vom Dez 2010 steht.

Beim Mapping von VLANs, gehen sie von einer Organisation aus, was
impliziert, dass revDNS zentral gemacht wird. Dann können wir's nicht mehr
delegieren.

Ich tu' mir leichter, wenn du schreibst, was du gut findest. Aus meiner
Sicht sind die Punkte aus dem Dokument großteils in unseren Überlegungen
enthalten? Was würdest du konkret vorschlagen?

> ****
>
> 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.
>
Oder einfach fortlaufend vergeben...

****
>
> 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...
>
Sollte irgendwie machbar sein. Davon gehe ich aus. Wir müssen halt mal
festlegen, wie wir's anpacken wollen.

> ****
>
> Habe mir gerade überlegt, Deine Ausführungen in einer Tabelle
> darzustellen. Hast Du einen Account, um auf Google Docs zuzugreifen?
>
= meine Email-Adresse

> ****
>
> Gottfried
>
LgS

> ****
>
> ** **
>
> *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/4d9352dd/attachment.html>