[IPv6-wien] IPv6 subnetting

Sun Sep 30 20:21:03 CEST 2012

Hi,

ja, kein Problem, wobei ripe-552 eher die Vergabe zwischen den
Einrichtungen im Internet regelt (RIR (-> NIR) -> LIR) und weniger was die
Provider (= LIRs) damit in ihrem Netz tun um die Adressen den Usern zur
Verfügung zu stellen; was unserer Situation mehr entsprechen würde. Aber
wenn sinnvolle Punkte drinnen sind, die uns beim Konzept helfen, sollten
wir darauf referenzieren.

Ich würde aber noch gerne weiterdiskutieren, wie unser *konkretes Design*
aussehen könnte. Ein /64 je Site und optional /56 je Site zum Endbenutzer
oder /64 je IPv4-Host und /56 optional. Über RFCs ist das ja alles
nochvollziehbar.

LgS

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

> Hi,****
>
> OK, RFC6177 soll eine der Grundlagen unserer Überlegungen sein.****
>
> Erkennen wir das auch als relevante Richtlinie an?
> http://www.ripe.net/ripe/docs/ripe-552****
>
> ** **
>
> Warum ich das frage: ich möchte unsere Arbeit durch zitierfähige Literatur
> absichern.****
>
> ** **
>
> Gottfried****
>
> ** **
>
> *Von:* Stefan Schultheis (home) [mailto:(spam-protected)]
> *Gesendet:* Sonntag, 30. September 2012 17:17
> *An:* Gottfried Motowidlo
> *Cc:* (spam-protected)
>
> *Betreff:* Re: [IPv6-wien] IPv6 subnetting****
>
> ** **
>
> 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/8385bcb0/attachment.html>