<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><br>
Hallo!<br>
<br>
Vorab: ersetze bitte das PDF gegen eines, bei dem man problemlos
Copy-n-paste in einer Zeile machen kann...Zitieren wir sonst
erschwert...<br>
<br>
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:<br>
<br>
Am 2013-03-25 13:44, schrieb Stefan Schultheis (home):<br>
</div>
...<br>
<blockquote
cite="mid:CAHanXmH6L+LOTp=+x1ybgX17PV4p_OcH47+GDJvqWqo=iuE_Fw@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div> Hinsichtlich der Transition-Netzwerke besteht daher
kein Bedarf an Verteilung weiterer Hostnetze
(network-specific prefix).<br>
</div>
</div>
</blockquote>
<div>OK, bestätigt das vorliegende Konzept.<br>
</div>
</div>
</blockquote>
Im Gegenteil, denn das sieht Teil 2 ja vor "/112".<br>
Im Übrigen gibt es bereits bei jeder unserer bestehenden
IPv4-Adressen ein vollständiges Transition-Konzept: 6to4.<br>
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. <br>
<br>
<blockquote
cite="mid:CAHanXmH6L+LOTp=+x1ybgX17PV4p_OcH47+GDJvqWqo=iuE_Fw@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div> Die Nutzung des "well-known prefix" /96 erscheint für
die in unserem Netz vorherrschende Problemstellung aus
Erwägungsgründen eher zweckmäßig:<br>
</div>
</div>
</blockquote>
<div>/96 verhindert die künftige Nutzung der 8 Bits, die im
vorigen Mail "u" genannt wurden.<br>
</div>
</div>
</blockquote>
Laut der Tabelle des RFCs sind sie dann gerade nicht reserviert.
IPv4 hat nur 32 Bit. 128-32=96.<br>
Worin besteht der Vorteil eines größeren Prefixes, wenn es um nur
eine und genau eine Adresse geht?<br>
Weiterer Vorteil: für Dotted-Quad-Notation brauche ich keinen
Rechner...<br>
<br>
<blockquote
cite="mid:CAHanXmH6L+LOTp=+x1ybgX17PV4p_OcH47+GDJvqWqo=iuE_Fw@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>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.<br>
</div>
</div>
</blockquote>
Ein Teil dieser Gruppe, darunter auch Joe, hatte anscheinend
unterschiedliche Auffassungen vom Begriff und dem Zweck des
Mappings.<br>
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.<br>
<br>
<blockquote
cite="mid:CAHanXmH6L+LOTp=+x1ybgX17PV4p_OcH47+GDJvqWqo=iuE_Fw@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div> 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. <br>
</div>
</div>
</blockquote>
<div>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.<br>
</div>
</div>
</blockquote>
<br>
Definiere "Automatische Adressierung", ist das das, was Du mir in
einem privaten Mail vom 30.01.2013<br>
so beschrieben hast, ohne die konkrete Umsetzung zu benennen?<br>
"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)."<br>
<br>
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?<br>
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. <br>
"Weiter" kann daher auch weiter hinten sein, denn das was Du mit dem
Schema beschrieben hast, passt damit hinten und vorne nicht
zusammen:<br>
<br>
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.<br>
Siehe- Präsentationsunterlagen: "Skalierbar für andere
0xFF-Communities (Option)", sowie Konzept.<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAHanXmH6L+LOTp=+x1ybgX17PV4p_OcH47+GDJvqWqo=iuE_Fw@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div> 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.<br>
</div>
</div>
</blockquote>
<div>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.<br>
</div>
</div>
</blockquote>
Siehe 3.<br>
<br>
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.) <br>
Gerade Markus hat mir gegenüber Bedenken diesbezüglich geäußert,
insbesondere hinsichtlich NAT generell.<br>
<blockquote
cite="mid:CAHanXmH6L+LOTp=+x1ybgX17PV4p_OcH47+GDJvqWqo=iuE_Fw@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div> 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.<br>
</div>
</div>
</blockquote>
<div>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.<br>
</div>
</div>
</blockquote>
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.<br>
<br>
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).<br>
Die Mappings sind entgegen dem Anforderungsprofil auch nicht
standortorientiert, sondern orientieren sich rein an vorhandenen
IPv4-Adressen, zur Problematik siehe auch weiter unten.<br>
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.<br>
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.<br>
<br>
Den Punkt "IPv4-Adressen sollen im Host-Teil des IPv6-Adressraumes
gemappt sein", habe ich schon nach der Erstellung des Papieres
scharf kritisiert.<br>
Dazu besteht nur dann eine Veranlassung, wenn sonst keine Prefixes
delegiert werden und nur aufgrund des Mappings Vergaben erfolgen.<br>
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.<br>
Ich ging davon aus, dass Du das Ergebnis der Diskussion
eingearbeitet hättest.<br>
<br>
<br>
Führen wir uns noch einmal vor Augen wofür ich "IPv6 Addressing of
IPv4/IPv6 Translators" genau brauche:<br>
<ul>
<li> Wenn IPv4-only Geräte vorhanden sind:</li>
<li>
<pre>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.</pre>
</li>
</ul>
<p>Also in Kombination entweder mit Umsetzern (NAT-PT, NAT64, ...)
oder Proxies oder Gateways.<br>
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.<br>
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.<br>
</p>
<p>Warum solltest Du für eine einzelne IPv4-Adresse rDNS delegieren
wollen? Das machen wir doch momentan auch schon nicht.<br>
Sinnvoll ist das für Hostnetze, die pro Knoten vergeben werden und
die RFC6177 eher entsprechen.<br>
</p>
<p>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.<br>
<br>
</p>
<blockquote
cite="mid:CAHanXmH6L+LOTp=+x1ybgX17PV4p_OcH47+GDJvqWqo=iuE_Fw@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div> 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.<br>
</div>
</div>
</blockquote>
<div>Bestätigt das Konzept der Gruppe.<br>
</div>
</div>
</blockquote>
Wozu vergibst Du dann /112er, wenn meine Aussage das Konzept der
Gruppe bestätigt?<br>
<br>
<blockquote
cite="mid:CAHanXmH6L+LOTp=+x1ybgX17PV4p_OcH47+GDJvqWqo=iuE_Fw@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div> Darüber hinaus steht es jedem Nodebetreiber frei, ein
abweichendes 4-to-6-Mapping innerhalb seiner eigenen
Hostnetz selbst umzusetzen, wenn daran Bedarf besteht.<br>
</div>
</div>
</blockquote>
<div>Das ist in jeder Variante so.<br>
</div>
</div>
</blockquote>
Dann benötigen wir keine Vorgabe dafür. -> streichen.<br>
<br>
<blockquote
cite="mid:CAHanXmH6L+LOTp=+x1ybgX17PV4p_OcH47+GDJvqWqo=iuE_Fw@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div> Ich stelle weiterhin den Antrag, den das Mapping
betreffenden Teil des Konzepts vorerst einmal zu streichen
und ans Reißbrett zurück zu verweisen.<br>
</div>
</div>
</blockquote>
<div>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.<br>
</div>
</div>
</blockquote>
<br>
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.<br>
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?<br>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:CAHanXmH6L+LOTp=+x1ybgX17PV4p_OcH47+GDJvqWqo=iuE_Fw@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>
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.<br>
<br>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
Das ist ohnedies schon gelebter Pragmatismus.<br>
Bedenke, dass auch Leute da sein müssen, die im laufenden Betrieb
Wartungen vornehmen werden müssen.<br>
<br>
<blockquote
cite="mid:CAHanXmH6L+LOTp=+x1ybgX17PV4p_OcH47+GDJvqWqo=iuE_Fw@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>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.<br>
</div>
</div>
</blockquote>
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. <br>
<br>
<blockquote
cite="mid:CAHanXmH6L+LOTp=+x1ybgX17PV4p_OcH47+GDJvqWqo=iuE_Fw@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>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.<br>
</div>
</div>
</blockquote>
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.<br>
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.<br>
<br>
<blockquote
cite="mid:CAHanXmH6L+LOTp=+x1ybgX17PV4p_OcH47+GDJvqWqo=iuE_Fw@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>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!<br>
</div>
</div>
</blockquote>
<br>
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.<br>
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. <br>
<br>
Eine weitere, *(Du weißt, was ich meine - pardon)-Aktion nur um des
Weiterkommens Willen ist sicher nicht das, was wir jetzt brauchen.<br>
<br>
Not amused<br>
Grüße<br>
Erich<br>
</body>
</html>