<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hallo!<br>
<br>
Am 2014-09-09 um 14:19 schrieb Matthias Šubik:<br>
</div>
...<br>
<blockquote
cite="mid:B481610E-59DC-4DAC-AAF5-CCF71629A800@matthias.subik.de"
type="cite">
<pre wrap="">Also wer von Euch UPC nutzt, anscheinend kann diese Konfiguration bei fast allen Modems ausgeteilt werden, überlegt es Euch.
Ich will nicht mehr zurück, Laptop dran, plopp alles online. Kein NAT mehr!</pre>
</blockquote>
Aufgrund dessen, dass bei weitem noch nicht alle Provider ipv6
unterstützen, hätte ich derzeit noch Bedenken (v.a. wegen
Wartungszugang), mache mir dazu aber auch meine Gedanken:<br>
Ein Workaround in solchen Fällen könnte Teredo sein, das unter Linux
in der Implementierung "miredo-client" verfügbar ist. Es ist auch im
Repository von Barrier Breaker 14.07 rc3 (OpenWRT) verfügbar, unter
Windows sowieso.<br>
<blockquote
cite="mid:B481610E-59DC-4DAC-AAF5-CCF71629A800@matthias.subik.de"
type="cite">
<pre wrap="">Da es jetzt IPv6 nativ beim größten Provider der Stadt gibt, sollten wir vielleicht auch mal überlegen, ob wir nicht auch einen Stichtag für IPv6 als Standard überlegen sollten (auch bei ggf. Verzicht auf natives v4.). DSLite oder ähnliche Verfahren könnten hier zum Einsatz kommen. Weil CGN kann ja auch 1:1 angewendet werden.</pre>
</blockquote>
Da bleibt immer noch das Problem der alten WRTs/Buffalos und nicht
so perfekt gewarteter (auch anderer) Router. Eine solche Umstellung
kann daher -je nachdem- ein Befreiungsschlag oder ein Desaster
werden. Zwar gibt es inzwischen ein besseres 5GHz-Backbone mit zu
nativem v6 befähigten Geräten als bei unserer letzten Diskussion
darüber verfügbar, lückenlos ist dieses aber noch nicht und wird es
ohne Masterplan und flächendeckende Beteiligung der Community nicht
werden.<br>
Carrier Grade NAT ist nicht zwangsläufig erforderlich: Theoretisch
könnte man mit Tayga, kmod-nat46, totd (je nach Bedarf) arbeiten, um
innerhalb des eigenen Prefix einzelne oder alle v4-Ranges
abzubilden. Andere Möglichkeiten gibt es auch:<br>
<br>
Varianten zur Umsetzung:<br>
a) Teredo am Client<br>
Zuweisung aus dem Range 2001:0::/32; externe v6-IP des
jeweiligen Teredo-Servers; subsidär gegenüber nativem v6. Probleme
mit OLSR, daher nur am <br>
Client.<br>
b) Teredo abseits der Spezifikation mit eigenen Teredo-Servern
(entweder 1x zentral, oder Anycast von eigenen Teredo-Servern auf
performanten v6-Nodes) mit <br>
einem eigenen Prefix z.b: 2a02:61:feed::/32 (Standard:
2001:0::/32).<br>
<blockquote><small><i>Wobei dieser Betriebsmodus für OLSR ungeeignet
ist, -obwohl eine /128 theoretisch als Routingadresse
ausreichend wäre (der zugewiesene Node-Prefix, respektive das
Node-Device-Interface-Prefix wäre per HNA zu announcen)- da
leider der Miredo Server selbst eine Art Nat64 und Nat46
betreibt und daher keine OLSR-Kommunikation auf seinem
Tunnel-Interface selbst möglich ist. Zudem sind diese
"transition mechanisms" meist subsidiär ausgelegt, d.h. sie
treten aufgrund ihrer gewählten Metrik hinter native
v6-Verbindungen zurück (und die hätten wir mit der Zuweisung
aus 2a02:60/29 dem Router vorgegaukelt) . Soweit meine
Erkenntnisse aus abgebrochenen Experimenten und Recherchen
dazu. </i></small><br>
</blockquote>
c) Auf allen Backbone-Strecken, die über roofnode/krypta/(nessus)
erreichbar sind v6 implementieren und zusätzlich <a
href="http://www.litech.org/tayga/">Tayga</a> und OLSRv4 fahren,
um die v4-only Teilstrecken innerhalb des eigenen Prefix zu
bedienen. Wächst der Strecke ein neuer v6 Node an, der noch Kontakt
zu v4 halten muss, muss dieser ebenso verfahren.<br>
<br>
c2) Für Endgeräte sollte 0xFF-Firmware denselben Mechanismus ohne
OLSR bereitstellen.<br>
Ich spiele mich gerade mit einer Firmware dieser Art basierend auf
OpenWRT BB14.07rc3 - Benutzung auf eigene Gefahr. Ich stehe damit
noch am Anfang, und die Sources sind freigeben und oder
dokumentiert. Es soll Jeder, der das möchte, wahlweise den
ImageBuilder nutzen oder den Tree nach Belieben selbst kompilieren -
es wird also eine echte Community Firmware.<br>
DNSmasq und Totd konkurrieren in 0.1.0 auf Port 53, d.h. die
Namensauflösung klappt noch nicht.
<a class="moz-txt-link-freetext" href="https://drive.google.com/folderview?id=0B4y0xd6CC7JtaC0xY2stcVNOTTg&usp=sharing">https://drive.google.com/folderview?id=0B4y0xd6CC7JtaC0xY2stcVNOTTg&usp=sharing</a><br>
Ich wäre über Feedback jeder Art dankbar. Die Erkenntnisse aus
diesem Zweig sollen in 0xFF-OS einfließen.<br>
Diese Firmware hat zram-swap aktiviert, um so auch auf älteren
Bullet, Nanostations, etc ohne "M", mit nur wenig Ram funktioniert.<br>
<br>
d) Sonstiges Tunneling: möchte ich vermeiden, da es
Teilinformationen über den Zustand des Netzes verschleiert.<br>
<blockquote
cite="mid:B481610E-59DC-4DAC-AAF5-CCF71629A800@matthias.subik.de"
type="cite">
<pre wrap="">
bG
Matthias
</pre>
</blockquote>
LG<br>
Erich<br>
</body>
</html>