Hallo,<br><br><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>
Danke für die Erläuterung des Missverständnisses!<br></div></div></blockquote><div>Gerne.<br><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>
Auch, wenn das Schema somit konform ist, sind dabei noch Fragen
offen:<br>
<br>
Wie bereits erwähnt, und im anderen E-Mail ergänzt, soll <b>dieser
Teil des Konzepts</b> die Interoperabilität von bestehenden IPv4
nach den RFCs 6052 und dem zu errichtenden IPv6-Netzwerk
gewährleisten. Zweckmäßig wird dafür die Verwendung von NAT64 (6146)
und DNS64, für Beispiele siehe auch <a href="http://tools.ietf.org/html/rfc6144" target="_blank">http://tools.ietf.org/html/rfc6144</a>.<br>
<br>
Gegen den <b>ersten Teil </b>- die Neuzuteilung von reinen
IPv6-Adressen - <b>habe ich keinen Einwand</b>, jedoch hinsichtlich
des "Transitition"-Konzepts erscheinen folgende Punkte unausgegoren:<br>
<br>
RFC6177, im Status der "Best current practice" empfiehlt in Punkt 2:<br>
<pre>Hence, this document still recommends
giving home sites significantly more than a single /64, but does not
recommend that every home site be given a /48 either.
</pre>
<br>
Dieser Punkt ist mit Zuteilung von /56-Hostnetzen für unsere
IPv6-only und Dual-Stack-Geräte gemäß RFC6177 bereits erfüllt.<br></div></div></blockquote><div>Danke, sehe ich als Bestätigung des Konzepts.<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>
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><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><br>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><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>
<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>
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>
<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>
<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>
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><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><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>
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>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>
<br>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>
<br>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>
<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>
</div>
LG<span><font color="#888888"><br>
Erich<br>
</font></span></div>
</blockquote></div>LgS<br><br>