[IPv6-wien] Neue Inhalte auf www.ipv6.wien.funkfeuer.at

[Erich N. Pekarek]

Hallo!

Vorab: ersetze bitte das PDF gegen eines, bei dem man problemlos 
Copy-n-paste in einer Zeile machen kann...Zitieren wir sonst erschwert...

Da Du mich aufgefordert hast, die inhaltlichen Bedenken über die Liste 
zu senden, obgleich wir "in der Gruppe" übereinkommen sind, dass dies in 
breiter aufgestellten Listen nicht getan werden sollte (soviel zum Wert 
der Beschlüsse "der Gruppe"), sende ich diese nun:

Am 2013-03-25 13:44, schrieb Stefan Schultheis (home):
...
>
>     Hinsichtlich der Transition-Netzwerke besteht daher kein Bedarf an
>     Verteilung weiterer Hostnetze (network-specific prefix).
>
> OK, bestätigt das vorliegende Konzept.
Im Gegenteil, denn das sieht Teil 2 ja vor "/112".
Im Übrigen gibt es bereits bei jeder unserer bestehenden IPv4-Adressen 
ein vollständiges Transition-Konzept: 6to4.
Wenn wir uns also einbilden, dass wir ein 4to6/6to4 Mapping-Schema 
brauchen: hier ist es....mitsamt /48-Präfix pro Adresse und somit in der 
weiteren Vergabe wieder der Best practice von RFC6177 entsprechend.

>     Die Nutzung des "well-known prefix" /96 erscheint für die in
>     unserem Netz vorherrschende Problemstellung aus Erwägungsgründen
>     eher zweckmäßig:
>
> /96 verhindert die künftige Nutzung der 8 Bits, die im vorigen Mail 
> "u" genannt wurden.
Laut der Tabelle des RFCs sind sie dann gerade nicht reserviert. IPv4 
hat nur 32 Bit. 128-32=96.
Worin besteht der Vorteil eines größeren Prefixes, wenn es um nur eine 
und genau eine Adresse geht?
Weiterer Vorteil: für Dotted-Quad-Notation brauche ich keinen Rechner...

> Die Gruppe hat sich dagegen entschieden. Es gibt Argumente dafür und 
> dagegen und immer mehrere gültige Ansätze, die Gruppe hat sich 
> entschieden.
Ein Teil dieser Gruppe, darunter auch Joe, hatte anscheinend 
unterschiedliche Auffassungen vom Begriff und dem Zweck des Mappings.
Ich stelle aufgrund dieses Irrtums diese (Nicht-)Entscheidung und den 
Wert dieser (Nicht-)Entscheidung, sowie das gewählte Forum in der Folge 
die Bindungswirkung der (Nicht-)Entscheidung  (=Nullum) somit in Frage.

>     1. Die Vergabe erfolgt aus Gründen der Kompatibilität u.z. jeweils
>     um ein einzelnes, bestehendes IPv4-only-Interface aus Sicht des
>     IPv6-Netzes erreichbar zu machen. (Ein Hostnetz ist daher
>     sinnlos). Das IPv4-only-Gerät benötigt nur eine Adresse und kein
>     Hostnetz; Es versteht auch nicht damit umzugehen. Auch gibt es in
>     der Regel somit keine zusammenhängenden Blöcke in unserem Netz.
>
> Das Konzept der Gruppe ermöglicht in der Zukunft auch das automatische 
> Adressieren zB. im Zuge eines SW-Updates der Router, was wir sonst 
> fallen lassen müssten. Wir sind da gedanklich schon einen Schritt weiter.

Definiere "Automatische Adressierung", ist das das, was Du mir in einem 
privaten Mail vom 30.01.2013
so beschrieben hast, ohne die konkrete Umsetzung zu benennen?
"Die Idee ist, mit einem der nächsten Backfire-Releases IPv6 automatisch 
zu konfigurieren: auf den 0xFF-Interfaces werden die IPv6-Adressen per 
Script aus den IPv4-Adressen generiert und OLSR auch für IPv6 gestartet. 
Die LANs bleiben unberührt, auch die FW-Regeln weitreichend (OLSR muss 
man schon zulassen)."

Im Firmware-Konzept ist sie bislang nicht bekannt. Von welchen Routern 
sprichst Du genau? Beziehst Du auch ältere Geräte mit ein? Was nützt die 
beste Autoconfig, wenn alle Nachbarn eines Knotens alte Buffalos und 
alte Linksys sind?
Außerdem war eine Autoconfig schon länger auch unter IPv4 geplant und 
ist bis jetzt nicht ernsthaft Realität geworden. Zudem halte ich das 
generell für keine gute Idee in einem freien Netz. Wir sind schließlich 
kein Provider der die CPEs mit TR069 "bearbeitet" und die bisherigen 
"Configger" sind nicht gerade intelligent.
"Weiter" kann daher auch weiter hinten sein, denn das was Du mit dem 
Schema beschrieben hast, passt damit hinten und vorne nicht zusammen:

Wenn es die Vergabe von IPv6-Hostnetzen an bestehende Router anbelangt, 
so ist dies auch innerhalb des Node-basierten Addressraumes möglich und 
verhindert Adresskollisionen besser, nämlich insbesondere im Falle der 
Netzzusammenlegung mit anderen Communities, wenn RFC1918-Adressen im 
Spiel sind. Auch das sollte bedacht werden. RFC1918 würde natürlich 
obigem 6to4-Einwand widersprechen und eine automatische Adressierung 
behindern.
Siehe- Präsentationsunterlagen: "Skalierbar für andere 0xFF-Communities 
(Option)", sowie Konzept.



>     2. Sobald das Gerät Dual-Stack beherrscht, hat es bereits ein
>     ausreichend großes Hostnetz aus der Node-Zuteilung und ist daher
>     nativ in IPv6 vertreten; Wozu also unnötigerweise nicht nutzbare
>     Adressräume hierfür vergeben? Bloß deshalb, weil es geht?! Bei
>     Verwendung von network-specific prefixes ist, wie Du richtig
>     festgestellt hast, ein Adressraum in der Größe von 8 Bit Länge
>     reserviert, was beim "well-known prefix" gerade nicht der Fall ist.
>
> Du kannst gerne /128 adressieren. Ich mache das auch so (mit v4 
> gemappt ab Bit 72). Jemand, der's anders machen will, kann das tun. 
> Mit unserem Konzept gibt es hier mehrere Möglichkeiten und keine 
> Einschränkung. Wir wollen ja auch Gestaltungsfreiheiten lassen, das 
> lässt ja IPv6 sehr gut zu und wird auch in den Design Guides empfohlen.
Siehe 3.

Gestaltungsfreiheiten hinsichtlich der Adressierung widersprechen dem 
specific-network-prefix-Grundsatz, den ich im Falle von automatisierter 
Umsetzung wie NAT64, DNS64 brauche. In dem Fall würde ich ja als Admin 
gerade die Basisadresse einheitlich geregelt haben wollen, sonst brauche 
ich ja gerade keinen RFC6052, der mir ja gerade statische Elemente 
vorschreibt. Zudem ist noch nicht einmal klar ist, wie die Umsetzung der 
Transition "Präsentation: Mapping-Mechanismus für IPv4->IPv6" ausschauen 
soll. (Momentan ist es ein Schema ohne Mechanismus. Beim Mechanismus 
hängt es davon ab, wo dieser implementiert werden soll. Zentral für das 
Mesh oder pro Node - dort wo er gebraucht wird.)
Gerade Markus hat mir gegenüber Bedenken diesbezüglich geäußert, 
insbesondere hinsichtlich NAT generell.
>
>     3. Vereinfachung: Die Umrechnung ist bei /96 irrelevant, denn es
>     gibt die Dotted-Quad-Notation z.B.: "2001:db8::193.238.157.16";
>     die Konfiguration wird vereinfacht und daher überschaubarer - auf
>     beiden Seiten.
>
> Du erzeugst mit deiner Idee aber eine compatibilty-address, die nicht 
> alle unsere Anforderungen erfüllt. Vgl. dazu den Abschnitt 
> "Anforderungsprofil" im Adresskonzept. ZB. eine Delegation für rDNS 
> etc. sind damit nicht möglich oder nur unter speziellen Aufwand. Das 
> wäre eine ziemliche Einschränkung, ist aber hier auch nur ein 
> Beispiel. Du darfst nicht aus den Augen verlieren, dass wir die 
> gemappte Adresse nicht ausschließlich für Transition-Technologien 
> nutzen, sondern als vollwertige IPv6-Adresse ohne Einschränkung.
Dafür hast Du bereits die Node-basierten Hostnetze. Es ist nicht 
sinnvoll neben einem Hostnetz pro Interface auch noch ein Mapping-Netz 
zu vergeben, respektive, dann, wenn Du das dennoch tust, hast Du den 
doppelten Verwaltungsaufwand. -> Tunnelserver und/oder Device plus 
Nameserver * 6 bei kleinem Node mit einem Device/2 Interfaces.

Die von Dir erzeugten Mappings entsprechen nicht der Anforderung der 
RFC6177-Konformität laut Anforderungsprofil. (zumindest /64; aber 8 
reserviert + /72 ist noch nicht /64 gemäß 6177).
Die Mappings sind entgegen dem Anforderungsprofil auch nicht 
standortorientiert, sondern orientieren sich rein an vorhandenen 
IPv4-Adressen, zur Problematik siehe auch weiter unten.
Durch die Delegation von /56-Hostnetzen ist das Mapping auch nicht 
erforderlich. Sollte Mapping erforderlich sein, so erfüllt es innerhalb 
des delegierten Netzes jedoch beide vorgenannten Anforderungen - ganz im 
Gegensatz zum bisherigen.
Da jede nicht RFC1918-IPv4-Adresse von 6to4 erfasst ist, steht ein 
alternatives Mapping zur Verfügung, jedoch nicht für Communities mit 
privaten Adressbereichen. Beim Mapping im eigenen Hostnetz stellt dies 
jedoch kein Problem dar.

Den Punkt "IPv4-Adressen sollen im Host-Teil des IPv6-Adressraumes 
gemappt sein", habe ich schon nach der Erstellung des Papieres scharf 
kritisiert.
Dazu besteht nur dann eine Veranlassung, wenn sonst keine Prefixes 
delegiert werden und nur aufgrund des Mappings Vergaben erfolgen.
Wir sind damals überein gekommen, dass das kein sinnvoller Weg ist, da 
sonst der (eigene) IPv4-Adressraum aufgrund vorhandener Engpässe 
innerhalb des Mappings überschritten  werden müsste.
Ich ging davon aus, dass Du das Ergebnis der Diskussion eingearbeitet 
hättest.


Führen wir uns noch einmal vor Augen wofür ich "IPv6 Addressing of 
IPv4/IPv6 Translators" genau brauche:

  *      Wenn IPv4-only Geräte vorhanden sind:
  *

    Zitat des Abstracts von RFC6052:
        This document discusses the algorithmic translation of an IPv6
        address to a corresponding IPv4 address, and vice versa, using only
        statically configured information.  It defines a well-known prefix
        for use in algorithmic translations, while allowing organizations to
        also use network-specific prefixes when appropriate.  Algorithmic
        translation is used in IPv4/IPv6 translators, as well as other types
        of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios.

Also in Kombination entweder mit Umsetzern (NAT-PT, NAT64, ...) oder 
Proxies oder Gateways.
Von wo nach wo und überhaupt wo, soll dieser denn zum Einsatz kommen? Es 
wäre wichtig das vorher zu wissen, denn davon hängt das Schema ab.
Bedenke, dass es sich um ein Funknetz handelt und wir unnötigen Overhead 
tunlichst vermeiden sollten. Ebenso sollte die Abhängigkeit vom 
Tunnelserver nicht verstärkt werden.

Warum solltest Du für eine einzelne IPv4-Adresse rDNS delegieren wollen? 
Das machen wir doch momentan auch schon nicht.
Sinnvoll ist das für Hostnetze, die pro Knoten vergeben werden und die 
RFC6177 eher entsprechen.

Damit das mit "automatischen Übersetzern" funktioniert - und das ist in 
unserem Netz der einzig legitime Grund für ein Mapping - braucht es nur 
ein /96 Prefix, weil ja nur exakt eine IP-Adresse eines bestehenden 
Gerätes (oder einer HNA) nach außen hin (IPv6) erreichbar sein soll. Für 
alles andere sind die Hostnetze da, die natives IPv6 vermitteln.

>     Vom Privacy-Standpunkt ergeben sich hierbei keine Probleme, da ein
>     IPv4-only-Interface beim Mapping ohnedies statisch ausgelegt ist
>     und daher keine Verschlechterung gegenüber dem bisherigen Zustand
>     eintritt.
>
> Bestätigt das Konzept der Gruppe.
Wozu vergibst Du dann /112er, wenn meine Aussage das Konzept der Gruppe 
bestätigt?

>
>     Darüber hinaus steht es jedem Nodebetreiber frei, ein abweichendes
>     4-to-6-Mapping innerhalb seiner eigenen Hostnetz selbst
>     umzusetzen, wenn daran Bedarf besteht.
>
> Das ist in jeder Variante so.
Dann benötigen wir keine Vorgabe dafür. -> streichen.

>     Ich stelle weiterhin den Antrag, den das Mapping betreffenden Teil
>     des Konzepts vorerst einmal zu streichen und ans Reißbrett zurück
>     zu verweisen.
>
> Da du aus meiner Sicht nur Alternativen aufgezeigt hast und keine 
> Probleme mit dem bestehenden Konzept bleibt alles beim alten - sonst 
> drehen wir uns ja im Kreis. Es wird immer jemand kommen, der noch eine 
> Idee hat, wie man's anders machen kann.

Wenn Dir die zusätzliche Komplexität nicht Grund und der Widerspruch zu 
RFC6177 und die sonst fehlende Schlüssigkeit nicht selbst Grund genug 
sind, kann ich Dir nicht helfen.
Diesen Teil trotz bestehender Bedenken vor Beginn der Evaluierungsphase 
- und da sind wir - auf Biegen und Brechen durchzudrücken, ist ein 
Bärendienst an der Community - denn warum sollte man ein fragwürdiges 
Konzept umsetzen, dass die schnelle Einführung dadurch verhindert, dass 
es die Dinge verkompliziert?

Streichen wir dieses überkommene Relikt aus den ersten Überlegungen weg, 
haben ein stabiles Konzept, mit dem wir zumindest einmal im IPv6- und 
Dual-Stack- Mode einmal starten können.


> Es macht keine Sinn weiterhin über Alternativen zu diskutieren. Das 
> Konzept steht in Version 1.0. Sofern keine Punkte gefunden werden, die 
> im aktuellen Konzept explizit fehlerhaft sind, ergeben die 
> Diskussionen keinen Sinn.
>

Ich sehe durch aus auch fehlende Schlüssigkeit in der Vergabe von /56 im 
ersten Teil des Konzeptes, da der Ansatz von he.net meines Erachtens der 
richtigere ist, aber die Diskussion darüber würde tatsächlich das 
gesamte Schema über den Haufen werfen.

Meiner Ansicht nach ist das  Konzept weder ausgereift, noch wirksam 
beschlossen; da ich selbst an einer schnellen Umsetzung interessiert 
bin, ist mein Kompromiss die Streichung des strittigen Teils, der uns 
noch Probleme bereiten wird.
Das ist ohnedies schon gelebter Pragmatismus.
Bedenke, dass auch Leute da sein müssen, die im laufenden Betrieb 
Wartungen vornehmen werden müssen.

> Ich möchte hiermit nochmal bekräftigen, dass ich hoffe, dass du das 
> vorliegende Konzept akzeptieren kannst, weil es gut ins Netz passt und 
> wir einen Punkt erreicht haben, an dem wir wirklich etwas damit machen 
> können. Ich glaube, dass dieser "zurück ans Reißbrett"-Ansatz die 
> Initiative zerstören wird.
Lieber Stefan, im Gegenteil: ich hoffe, dass Du akzeptieren kannst, dass 
der Mapping-Teil unausgegoren und fehlerhaft durchdacht ist, und das 
Belassen dieses Teils die Evaluierungsphase gefährdet.

> Du warst mehrfach eingeladen (sogar persönlich, nicht nur durch die 
> Mailingliste) an dem Konzept mitzuwirken und hast ja auch guten Input 
> geliefert. Die Gruppe hat sich halt gegen diese Ideen entschieden und 
> das Konzept in der vorliegenden Form für sinnvoll erachtet.
Die wirklichen Eckpunkte hast Du stets bei Treffen entscheiden lassen, 
bei denen Du von vornherein um meine terminliche Verhinderung (wegen 
Abendkursen oder Krankheit) gewusst hast. Eine Chance, die Kritikpunkte 
somit persönlich darzulegen war mir nicht gegeben und Du hast diese auch 
stets negiert oder herunter gespielt. Sich nun hinter der Gruppe, wie 
auch immer diese nun konstituiert gewesen sein mag, zu verstecken, halte 
ich nicht für besonders demokratisch.
Dass die Testtage keine ordnungsgemäß ausgeschriebene Generalversammlung 
sind und ein derartig weitgreifendes Konzept an sich einer höheren 
Legitimation bedürfte, und somit bestenfalls informellen Charakter hat, 
muss nicht weiter ausgeführt werden.

> Bist du an einem Tunnel interessiert? Dann könntest du die Technologie 
> gleich ausprobieren und wir kommen voran!? Bzgl. der Use-Cases und 
> natürlich der Tests würden wir deine Unterstützung und exakte 
> Vorgehensweise gerne einsetzen!

Hinsichtlich des Tunnels habe ich Dir gegenüber bereits erwähnt, dass 
ich hohl28 für nicht geeignet halte und dass Markus sich um eine Lösung 
im Housing kümmern wird.
Bedenke auch hier, dass der IPv6-Traffic auf anderen Knoten als unseren 
beiden normalerweise mehrfach über das Funknetz Richtung Tunnelserver 
und zurück abläuft. Funkinseln und Tunnelserver für dieses Projekt 
sollten entsprechend robust sein und nicht bereits jetzt schon an 
Airtime-Mangel leiden.

Eine weitere, *(Du weißt, was ich meine - pardon)-Aktion nur um des 
Weiterkommens Willen ist sicher nicht das, was wir jetzt brauchen.

Not amused
Grüße
Erich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.funkfeuer.at/pipermail/ipv6-wien/attachments/20130326/f777e989/attachment.html>