[IPv6-wien] Umfang unseres IPv6-Vorhabens

Erich N. Pekarek (spam-protected)
Thu Oct 11 12:10:28 CEST 2012


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.funkfeuer.at/pipermail/ipv6-wien/attachments/20121011/f2828fb3/attachment.html>


More information about the IPv6-wien mailing list