<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hallo!<br>
<br>
Am 2017-03-15 um 12:33 schrieb Wolfgang Nagele:<br>
</div>
<blockquote
cite="mid:CAK6j62yF5Vv3pxc7p217RcjiRRxwSUWpueXOROH+6OjxiEgd4g@mail.gmail.com"
type="cite">
<pre wrap="">Das Problem bietet sich nur fuer Knoten die auch ueber den tunnel6
angebunden werden wollen.</pre>
</blockquote>
Also <a class="moz-txt-link-freetext" href="http://tunnel6.funkfeuer.at/">http://tunnel6.funkfeuer.at/</a>, richtig?<br>
<blockquote
cite="mid:CAK6j62yF5Vv3pxc7p217RcjiRRxwSUWpueXOROH+6OjxiEgd4g@mail.gmail.com"
type="cite">
<pre wrap=""> Insofern kann man diese dort ablesen.</pre>
</blockquote>
Das wäre dann:<br>
<a class="moz-txt-link-freetext" href="http://tunnel6.funkfeuer.at/tunnel6.php">http://tunnel6.funkfeuer.at/tunnel6.php</a><br>
<blockquote
cite="mid:CAK6j62yF5Vv3pxc7p217RcjiRRxwSUWpueXOROH+6OjxiEgd4g@mail.gmail.com"
type="cite">
<pre wrap=""> Es
handelt sich im Moment nach einem schnellen Check um 15 die
entsprechend gerouted werden muessten. Zusaetzliche einfuegen ist auch
super easy.</pre>
</blockquote>
1. Bitte - Könnt Ihr das bitte formularbasiert teilautomatisieren?<br>
<font size="-1">Es müssten ja im Grunde nur geprüfte Parameter
(devicename, local endpoint, remote endpoint, prefix) zur
Ausführung von "ip" abgelegt werden, die dann ein Cronjob
verarbeitet. Der Device-Name könnte dabei den Username oder den
Knotennamen beinhalten, damit es übersichtlich bleibt.<br>
</font><br>
2. Problemstellungen, die zu erörtern sind.<br>
<font size="-1">Problematisch ist aber weiterhin, dass nicht jede
Firewall Protokoll 41 durchlässt, falls dieser Tunnel zur
Verbindung mit einer „echten“ Funkinsel mit statischer IP dienen
würde - was ja momentan nicht vorgesehen ist, aber grundsätzlich
praktisch wäre.<br>
„Echte“ Funkinseln mit dynamischer IP oder bei „mobilem Breitband“
als Hauptanbindung sind hier weiter im Nachteil, weil diese in den
meisten Fällen (kein „Open IP“ beim Gros der Angebote) zwar
Protokol 41 eventuell nützen könnten, aber keinen öffentlich
erreichbaren Endpunkt bieten. Hier bleibt weiterhin nur die
Alternative von UDP-Tunneln, die entweder über OpenVPN oder etwa
mittels socat realisiert werden könnten. Für letzteres bräuchte
man allerdings für den statischen Endpunkt noch eine Art
„Triggermechanismus“.<br>
Ich denke, wenn man das jetzt noch einbaute, sparte man sich
später Administrationsaufwand für andere Tunnellösungen.<br>
</font><br>
3. Alternativen?<br>
<font size="-1">Aber darf ich eine andere provokative Frage in den
Raum stellen? Anstelle von Transitionsmechanismen, die im worst
case über andere Tunnel laufen und so Overhead und in der Folge
MTU-Probleme aufwerfen (@Wolfgang wir beide haben darüber ja schon
ein paar wenige Gedanken ausgetauscht), könnte man doch auch
gleich Layer2-Tunnel nützen und so nativen Dual-Stack-Betrieb
ermöglichen. <br>
</font><br>
<br>
Ich würde Euch ersuchen, in den Punkten 2+3 nichts aus zu
überhasten, auch, wenn zum kommenden Mitgliederversammlung, die ja
recht bald stattfinden wird, Vorzeigbares schon nett wäre - aber das
darf nicht ausschlaggebende Kriterium sein.<br>
<br>
<blockquote
cite="mid:CAK6j62yF5Vv3pxc7p217RcjiRRxwSUWpueXOROH+6OjxiEgd4g@mail.gmail.com"
type="cite">
<pre wrap="">
Ich persoenlich finde das der Vorteil das Leute beim Umstellen auf
v642 nicht renumbern muessen wesentlich hoeher ist als ein paar Routen
bei uns flippen zu muessen. Das braucht 5 Sekunden.</pre>
</blockquote>
<br>
Sprichst Du dabei den Aufwand für die User oder den Aufwand für die
Routingadministration an?<br>
Gerade im von mir angesprochenen Szenario mit v1+v2 könnte es zu
unerwartetem Fehlverhalten kommen, das durch unterschiedliche
Adressbereiche weitestgehend ausgeschlossen wäre. (Ansonsten sind
die Anforderungen an die Handhabung von Policy Routing weitaus
größer - womit die Komplexität stiege).<br>
Man sollte mE die Hürden für die Knotenbetreiber stets niedriger
halten.<br>
<blockquote
cite="mid:CAK6j62yF5Vv3pxc7p217RcjiRRxwSUWpueXOROH+6OjxiEgd4g@mail.gmail.com"
type="cite">
<pre wrap="">
lg</pre>
</blockquote>
LG<br>
Erich<br>
<blockquote
cite="mid:CAK6j62yF5Vv3pxc7p217RcjiRRxwSUWpueXOROH+6OjxiEgd4g@mail.gmail.com"
type="cite">
<pre wrap="">
2017-03-15 12:23 GMT+01:00 Christoph Loesch <a class="moz-txt-link-rfc2396E" href="mailto:mail@chil.at"><mail@chil.at></a>:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
woher wisst ihr, welche prefixes bereits "vergeben" sind?
Wir haben das bisher über den v6 calculator berechnet und einfach auf den
Routern eingetragen wobei es (seit bekanntmachung des v642 projekts) auch
Router geben könnte, wo wir das (noch) nicht eingetragen haben, daher
prefixes für diese Knoten nicht pingbar sind und somit nicht "vergeben"
obwohl normal n Verwendung.
Lg
Am 15. März 2017 08:59:05 MEZ schrieb David Hopfmueller
<a class="moz-txt-link-rfc2396E" href="mailto:david@hopfmueller.at"><david@hopfmueller.at></a>:
</pre>
<blockquote type="cite">
<pre wrap="">
Guten Morgen ipv6-wien,
Ich schreibe Euch, um Euch um Eure Meinung und Zustimmung zu bitten:
Der derzeitige IPv6-Betrieb laeuft ja derzeit laut dem Konzept-2013 [1]
als 6-in-4 ueber den tunnel6.
Im Rahmen des v642-Projekts, das ja bei einem v6-Treffen Anfang 2016
geboren wurde, haben wir das bestehende Konzept in ein paar Punkten
ueberarbeitet, um IPv6 als natives Protokoll optimal nutzen zu koennen.
Das Ergebnis wurde um den Mai 2016 herum ausgeschickt und ist unter [2]
einsehbar. Die wesentlichen Punkte wurden uebernommen, insbesondere die
User-Prefixes (nnnnri), denn ein wichtiges Ziel war, dass die bisherigen
IPv6-User beim Wechsel auf v642 nicht um-adressieren muessen
(renumbering).
Wir sind jetzt mit v642 soweit, dass die ersten OLSRv2-Nachbarschaften
stehen [3]. Damit das Netz nutzbar wird, wuerden wir gerne das Routing
des Prefixes 2a02:60:100::/40 aendern, das ist der Bereich, in dem alle
bisher genutzten Adressen liegen. Davon ausgenommen waeren alle bereits
vergebenen Knoten-Prefixes sowie das IPv4-Mapping (Seite 4 in [1]).
Diese Bereiche wuerden weiterhin zum tunnel6 geroutet.
Fuer Euch ergaebe sich dadurch keine Aenderung. Die bisher genutzten
Tunnel + die gemappten IPv4-Adressen bleiben, wie sie sind. Ihr koenntet
sogar parallel dazu OLSRv2 in Betrieb nehmen, da fuer das grundlegende
Routing andere Adressen genutzt werden (die Loopback-Adressen in [2]).
Sobald v642 bei Euch stabil laeuft, gebt ihr Bescheid, damit wir fuer
Euer Knoten-Prefix (nnnnri) die Route zum tunnel6 raus nehmen. Ab diesem
Zeitpunkt bekommt ihr dieselben IPv6-Adressen, nur eben nativ ueber IPv6
und nicht mehr via tunnel6.
Am Status Quo wuerde sich fuer Euch also nichts aendern. Ich schreibe
Euch trotzdem, weil ihr viel Arbeit in den IPv6-Aufbau gesteckt habt und
ich nicht will, dass der Eindruck entsteht, dass da "einer kommt und
alles aendert". Die Alternative ist, dass wir fuer v642 ein komplett
neues Prefix nutzen (z.B. 2a02:60:200::/40), das wuerde aber eben bei
einer Migration auf v642 ein Renumbering nach sich ziehen.
Bitte gebt mir Bescheid, wie ihr das seht und ob ihr damit einverstanden
waeret.
Danke,
David
P.S. Fuer Interessenten an v642: Die Koordination findet ueber Matrix
[4] statt, hier kommt ihr direkt zum Raum:
<a class="moz-txt-link-freetext" href="https://riot.im/app/#/room/#0xff-v642:hopfmueller.at">https://riot.im/app/#/room/#0xff-v642:hopfmueller.at</a>
[1] <a class="moz-txt-link-freetext" href="http://www.ipv6.wien.funkfeuer.at/download/konzept20130321.pdf">http://www.ipv6.wien.funkfeuer.at/download/konzept20130321.pdf</a>
[2] <a class="moz-txt-link-freetext" href="https://wiki.funkfeuer.at/wiki/IP-Adresskonzept">https://wiki.funkfeuer.at/wiki/IP-Adresskonzept</a>
[3] MailScanner warning: numerical links are often malicious:
<a class="moz-txt-link-freetext" href="http://78.41.119.44/olsrv2status/">http://78.41.119.44/olsrv2status/</a>
[4] <a class="moz-txt-link-freetext" href="https://wiki.funkfeuer.at/wiki/Chat">https://wiki.funkfeuer.at/wiki/Chat</a>
</pre>
</blockquote>
<pre wrap="">
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
_______________________________________________
IPv6-wien mailing list
<a class="moz-txt-link-abbreviated" href="mailto:IPv6-wien@lists.funkfeuer.at">IPv6-wien@lists.funkfeuer.at</a>
<a class="moz-txt-link-freetext" href="https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien">https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
IPv6-wien mailing list
<a class="moz-txt-link-abbreviated" href="mailto:IPv6-wien@lists.funkfeuer.at">IPv6-wien@lists.funkfeuer.at</a>
<a class="moz-txt-link-freetext" href="https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien">https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien</a>
</pre>
</blockquote>
<br>
</body>
</html>