<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
Hallo!<br>
<br>
Kurzfassung an die Liste, private Mail an Stefan.<br>
<br>
<br>
Am 2013-03-25 08:40, schrieb Stefan Schultheis (home):<br>
<blockquote
cite="mid:CAHanXmHnfRyrvRrctv7KhjN46r2Wq86DCMCjOdLaF_Tp2DtOBA@mail.gmail.com"
type="cite">Guten Morgen,<br>
<div class="gmail_quote"><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> Hier wird das Mapping 4
to 6 beschrieben.<br>
Abweichend von den Vorschlägen des Punktes 2.2 des RFC6052
(NAT64) <a moz-do-not-send="true"
href="http://tools.ietf.org/html/rfc6052" target="_blank">http://tools.ietf.org/html/rfc6052</a>,
verwendest Du ein <br>
ein /80-Prefix.<br>
</div>
</blockquote>
<div>Als Netzwerk-Prefix kommt /64 zur Anwendung. Da die
folgenden 8 Bit reserviert sind und auf 0 gesetzt sein müssen
(unten als "u" gekennzeichnet), beginnt bei Bit 72 das Mapping
der IPv4-Adresse. Siehe auch Konzept + Beispiele.<br>
<br>
</div>
</div>
</blockquote>
Danke für die Erläuterung des Missverständnisses! <br>
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
class="moz-txt-link-freetext"
href="http://tools.ietf.org/html/rfc6144">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 class="newpage">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>
Hinsichtlich der Transition-Netzwerke besteht daher kein Bedarf an
Verteilung weiterer Hostnetze (network-specific prefix).<br>
Die Nutzung des "well-known prefix" /96 erscheint für die in unserem
Netz vorherrschende Problemstellung aus Erwägungsgründen eher
zweckmäßig:<br>
<br>
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>
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>
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>
<br>
Im alternativen Konzept, bei dem bestehende Mappings für die
Vergabepraxis hergezogen worden wären, welches ich mittlerweile als
nicht zweckmäßig erkannt habe, hätte das Sinn ergeben, nicht jedoch
im vorliegenden Konzept. Es ist nicht aus einem Guss.<br>
<br>
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>
<br>
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>
<br>
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>
<br>
LG<br>
Erich<br>
</body>
</html>