[IPv6-wien] Umfang unseres IPv6-Vorhabens

Thu Oct 11 13:00:33 CEST 2012

Also ich werd nachdem die Wurscht unten schon so lang geworden ist,
und ich von der Hälfte die ihr da so schreibt eh nichts verstehe, mal
so böse sein und meine Antwort als "TOFU" gestalten:

Ich bin der Meinung, dass es durchaus Sinn macht, eine Möglichkeit zu
schaffen, IPv4 Adressen auf IPv6 Adressen map-bar zu machen, und zwar
deswegen, dass es möglich ist, einen Node mit kleinst möglichem Update
von IPv4 auf IPv6 upzugraden. Also dass es möglich ist mit einem
einfachen Firmwareupdate ohne Konfigurationsreset + einem Script dass
aus den IPv4 Adressen IPv6 Adressen berechnet und setzt auf IPv6
umzusteigen.

Allerdings bin ich weiters der Meinung, dass man dafür den geringst
möglichen IPv6 Adressraum verwenden sollte, um für die Zukunft und für
Leute die sich gerne ein bischen damit beschäftigen wollen den Platz
für einen hübsch strukturierten Adressraum bewahren. Sprich meiner
Meinung nach sollte man für jede IPv4 adresse nur genau eine IPv6 /128
Adresse reservieren, ohne Subnetting möglichkeiten, Auch brauchen wir
nicht ALLE IPv4 adressen des GESAMTEN IPv4 Adressraums in unsrem IPv6
Adressraum abbilden, es reicht wenn wir durchnummerieren.

Datenschutz als Argument gegen einen strukturierten Adressraum finde
ich blödsinnig. Ein Traceroute kann ich auch in IPv6 machen, wenn ich
die Netzstruktur rausfinden will, insofern schütze ich keine Daten
wenn ich die Struktur aus den IP-Adressen weglassen würde. Es sagt ja
keiner dass wir geo-Koordinaten in die Adressen reinkodieren sollen,
bloß dass es einen gemeinsame Sub-Adressraum für einen Node gibt,
anstatt einen eigenen Raum für jedes eigene ethernet-device jedes
funkfeuer routers der sich in unsrem Netz befindet. Information die
man auch aus einem traceroute rauslesen kann, aber angenehm wäre wenn
mans direkt aus den adressen sehn würde, welche 2 adressen zum selben
node gehören.

LG, Thomas

Am 11. Oktober 2012 12:10 schrieb Erich N. Pekarek <(spam-protected)>:
> Am 2012-10-11 08:04, schrieb Stefan Schultheis (home):
>
> Hi,
>
>>>  e) weitere Übergangstechnologien im globalen Sinn: wie erreicht ein
>>> reiner IPv6-User reine IPv4-Seiten, etc.
>>>
>>> Den Punkt (e) hat Erich vorhin angeschnitten wenn ich das richtig
>>> verstanden habe.
>>
>> Das ist sicher ein wichtiges Thema, aber mir ging es zunächst einmal um
>> das Adressierungsschema. Wer eine bestehende Adresse hat, soll daraus sein
>> Hostnetz ableiten können, wenn er das Funkfeuer-Präfix kennt.
>
> Wieso soll man ein Hostnetz aus bestehenden Adressen ableiten können?
> (Argumente und Erklärung aus meiner Sicht siehe unten - wir gehen in der
> Diskussion aktuell eher den Weg nicht zu mappen; falls du schlagende
> Argumente für IPv4-Mapping hast, ist das jetzt der richtige Zeitpunkt
> dafür!)
>
>
> Argument 1: Einfachheit:
>     Im Falle von /64: siehe Argument 2
>     Im Falle von /128: Notationen können gemischt werden:
> 2a02:60::78.41.112.66/64 (RFC 4291)
>
> Argument 2: Nachvollziehbarkeit
>     /64: Ich kenne mein IPv4, ich kenne mein IPv6. Streiche bei ip6calc das
> "2002" vorne weg, ersetze durch "2a02:60" und mach aus /48, /64.
>     /128: Siehe Argument 1
>
> Argument 3: Per Node Hostnetze versus Per Device Hostnetze
>      (bei ersteren hat Clemens auch Vorbehalte, wenn ich das richtig
> verstanden habe.)
>
> Argument 4: Es gibt immer noch ausreichend Adressraum.
>     Selbst unter Einbeziehung der Grazer offiziellen IPv4 Subranges
> verbrauchen wir gerade einmal 7 /48 Netze.
>
> Argument 5: IPv4 erschöpft - was dann?
>     Dann brechen wir mit dem Schema und vergeben IP6 only. Im Moment ist das
> noch wenig relevant.
>     Wir reservieren lediglich etwas mehr Space und aber wir haben zwischen
> den Bits 48-64 immer noch genug Adressraum über, ohne andere Adressen
>     den Bereich im Bitraum 32-47 zu berühren.
>
>
> Das Adressierungsschema ist ein wesentlicher Bestandteil des Designs. Nach
> Gottfried's richtungsweisendem Aufruf zur "Freiheit im Kopf"
> (https://lists.funkfeuer.at/pipermail/ipv6-wien/2012-September/000027.html)
> bin ich in mich gegangen, habe etwas mehr Freiheit im Kopf erlangt und bin
> mittlerweile auch der Meinung, dass wir besser fahren, wenn wir uns von IPv4
> und Mapping-Gedanken lösen. Das ist nicht die Zukunft. In der Zukunft ist
> IPv6 autonom.
>
> Nur weil wir bestehende IPv4-Adressen zu Beginn heranziehen, heißt das
> nicht, dass die Freiheit eingeschränkt wäre.
> So wie ich das verstanden habe, ging es vor allem um einzelne Adressen mit
> Präfix /128. Der Mapping-Gedanke ist hier nicht gegeben. Wir wählen
> lediglich ein vereinfachtes Schema zur Erstausstattung.
> Um besser zu differenzieren werden neue Adressräume in ipv6-only nur noch im
> Hexadezimalsystem angegeben.
>
>
>
>
> Weiters benötigt ein IPv4 Mapping 32 Bit, wodurch wir wieder eine
> Einschränkung erfahren. Andere Varianten wie NodeID oder eine neue
> fortlaufende Nummerierung auf 16 Bit-Basis ermöglichen uns 65536 Subnetze
> und benötigen nur die Hälfte an Adressraum.
>
> Nicht zwangsläufig. Die offiziellen Ranges sind bei Wien und Graz in den
> ersten /48 Bit für sich invariabel.
>
> Die Frage, wieviel wir an Adressraum benutzen, ob 1 oder 7  /48 Subnetze,
> ist vernachlässigbar. -> Freiheit im Kopf. Wieviele Hosts/Devices wird das
> Netz einmal haben? Für geroutete Subnetze bei Bedarf (/56) gehen sich immer
> noch fast 16 Millionen aus...
>
>
>
>>>
>>> Vom großen Bild ("big picture") her sehe ich das so:
>>> .... Mit der Zeit werden die IPv6fähigen Nodes mehr, die Tunnel weniger
>>> und irgendwann ganz verschwinden. An diesem Tag in ferner Zukunft ist das
>>> gesamte Netz nativ IPv6 fähig.
>>
>> Das ist der globale Migrationspfad auf IPv6: Inseln bilden, Inseln
>> zusammenwachsen lassen.
>
> In der großen weiten Welt funktioniert das technisch ein bißerl anders
> (andere Technologien und Protokolle) als in unserem Bereich, aber die
> Methode ist die selbe.
>
> Es gibt verschiedene Roullout-Strategien und Mechanismen dafür. Das ist
> gegenwärtig für uns noch nicht von Relevanz und es bleibt genug Adressraum
> zum "Spielen" hinsichtlich späterer Einsatzbereiche.
>
>
>
>>>
>>> Ich würde dann nämlich zwei weitere Richtungen verfolgen:
>>>  1) wir brauchen ein DESIGN als Basis für's weitere Handeln! Da gibt's ja
>>> schon super Input, das sollten wir weiterdiskutieren und finalisieren. Ich
>>> liebäugle mit einem persönlichen Treffen in der nächsten Woche bei einem
>>> Bier und SpareRibs oder ähnlichem. ;) Außerdem würd' ich euch alle sooo gern
>>> mal persönlich kennenlernen! ;)
>>>
>>>  2) in der og. Umgebung könnten wir dann auch besser koordinieren, für
>>> welche Themen sich die einzelnen Teilnehmer interessieren und wer bereit
>>> ist, konkrete Punkte zu übernehmen.
>>
>> Warum nicht eigene IPv6-Testtage dafür schaffen? Dann könnte auch ein
>> weiteres interessiertes Publikum erschlossen werden.
>
> Gute Idee, aber mir fallen im Moment viele Punkte ein, warum ich _jetzt_
> noch keine Testtage machen würde:
> -) wir haben noch kein Design. Das lässt sich in der aktuellen Runde von 10
> Personen besser zum Ziel bringen als im großen Chaos bei Testtagen.
>
> Ack, aber 10 Leute haben auch nur eine eingeschränkte Sicht der Dinge.
>
> -) wir haben nicht wirklich etwas Sinnvolles zum Testen. Die aktuellen
> Entwicklungen sind durch Tests von Gottfried und mir inkl. Feedback an Joe
> entstanden, der dann ein Image gegossen hat. Das Ergebnis der Testtage wird
> also sein, dass es noch nicht funktioniert. Diese Erkenntnis haben wir jetzt
> auch schon.
>
> Testtagen können auch Konzepttage vorangehen, wo Gruppen von drei Personen
> jeweils ein Projekt planen.
>
>
> -) bei den Testtagen wollen die Leute Ergebnisse haben, also etwas, das man
> benutzen kann. Das gibt es noch nicht und wird auch noch ein bißerl dauern.
>
> Dann sind es Projekttage, Konzepttage, Case Studies, ...
>
> Wir werden dort also zerlegt mit Fragen, wieso man jetzt den radvd noch
> nicht verwenden kann und wieso der Marvin noch keine Adressen ausspuckt und
> wieso's kein OpenVPNv6 und kein DNS6 gibt und dass das alles blöd ist,
> weil's noch keine Verbindung zwischen IPv6-Welt und Funkteil von 0xFF gibt
> und man eh nix damit machen kann usw.
>
> Bei meiner Adressierung kommt Marvin eine Gnadenfrist zu, weil es eh
> nachvollziebar ist. Die Umrechnung zu implementieren erfordert vorerst keine
> Änderung des DB-Schemas und kauft uns Zeit.
>
>
> Fazit: ich glaube, v6-Testtage sind zum jetzigen Zeitpunkt verfrüht und
> kontraproduktiv.
>
> Das sehe ich anders, denn es geht auch um die Botschaft, die damit
> verbreitet wird. Vielleicht kennen sich einfach viele Leute auch noch nicht
> damit aus und wären dankbar für einen Kontakt "face-to-face".
>
>
> Ich möchte das aber unbedingt machen, sobald IPv6 einsatzbereit ist, bzw.
> die ersten Use-Cases funktionieren und wir eine Verbindung ins v6-Internet
> anbieten können. Dann machma gleich einen Workshop für alle interessierten
> daraus und jeder kann idF gleich zu Hause mit IPv6 online gehen. Jetzt
> würden wir eher nur Frust über nicht vollendete Sachen produzieren.
>
> Das glaube ich nicht. Wer will kann auch 6to4 oder sixxs/aiccu verwenden und
> dort rumspielen. Workshops können das Basiswissen auch so vermitteln und das
> wird nötig sein, wenn Provider mit dem Rollout en masse beginnen. (Funkinsel
> ipv4 über Provider-ipv6?)
>
>
> Ich glaube sogar, dass man zwei Workshops braucht:
>  1) IPv6 Kennenlernen und erklärt bekommen,
>
> Das ist ein Workshop.
>
>  2) IPv6 konkret im Funkfeuer-Netz inkl. Anwendungsfälle und Konfiguration
>
> Das sind Testtage.
>
>
>>>
>>> Wie seht ihr das? Reden wir da von den gleichen Zielen? Was habe ich
>>> übersehen?
>>
>> Äh, eine Kleinigkeit vielleicht, aber da muss ich selber erst einmal
>> nachrechnen. :)
>
> Jetzt machst du's aber spannend... ;)
>
> Nein, es passt eh. ;-)
>
>
>>
>> LG
>> Erich
>
> LgS
>
> LG
> Erich
>
> _______________________________________________
> IPv6-wien mailing list
> (spam-protected)
> https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien
>