<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hallo Liste!<br>
Gottfrieds und Manfreds E-Mails zeigen mir, dass nur wenige der
ihrerseits Kritik übenden Listenteilnehmer den Kern meiner Kritik
verstanden haben:<br>
<br>
<b><u>Gegenstand der Kritik:</u></b><br>
<big><u><b>Seite 3 des </b></u><u><b><a
href="http://www.ipv6.wien.funkfeuer.at/download/konzept20130321.pdf">Konzepts</a></b></u><u>
"</u><u><i>Adressgestaltung mittels </i></u><u><i><b>Node-ID
Adressierung</b></i></u><u><i>"</i></u><u> wird von mir </u><u><b>nicht
beanstandet</b></u><u>.</u></big><br>
<b>Beanstandet wird Seite 4</b> des Konzeptes <i>"Adressgestaltung
mittels </i><i><b>IPv4-Mapping</b></i><i>"</i>. Dieses ist wohl
kein integraler Bestandteil, sondern ein Add-on.<br>
<br>
<b><u>Begründung:</u></b><br>
Der Inhalt von Seite 4 <b>widerspricht</b> einer <b>einheitlichen</b>
und <b>eindeutigen</b>, sowie <b>skalierbaren</b> <b>Adressierung</b>,
die als Vorgabe <b>bereits im</b> <b>Arbeitspapier</b>
ausdrücklich genannt ist und aus den in früheren Mails genannten
Gründen und stellt eine <b>Doppelgleisigkeit</b> dar. Der
konkrete <b>Zweck</b> des Mapping-Schemas ist weiter unklar, für
die angedeuteten Fälle "automatische Adressierung, SW-Update", mag
es zureichend sein oder könnte sogar über das Ziel hinaus
schießen. In der aktuellen Fassung bedeutet es Mehraufwand. Der
Nutzen des Mappings in dieser Form ist daher zu hinterfragen.<br>
<br>
<b><u>Kompromiss:</u></b><br>
Den Inhalt von Seite 4 <b>sinngemäß</b> auf <b>Router-ID 0 des
jeweiligen Nodes abzubilden</b>, könnte die Probleme
(insbesondere Skalierbarkeit, EUI64, Standortbezogenheit, etc.)
lösen, ohne allzu tief ins das bisher Erarbeitete einzugreifen.
Die Konfiguration würde dadurch auch für andere Projektgruppen
vereinfacht und es sind weiter alle Optionen offen. Diesfalls wäre
noch zu klären, welchen Sinn die Vergabe von Hostnetzen statt
einzelner IPs für gemappte Geräte ergibt, die nur mit einer
einzelnen Adresse umgehen können.<br>
<br>
<b><u>Bewertung der Auswirkungen einer Änderung:</u></b><br>
Zu diesem Zeitpunkt hätte eine Änderung kaum technische oder
projektbezogene, organisatorische Auswirkungen.<br>
Eine spätere Änderung würde bei diesem und anderen Projekten einen
erhöhten Aufwand bewirken und zur Verunsicherung der User
beitragen.<br>
<br>
Ich hoffe, dass ich mich jetzt präziser und verständlicher
ausgedrückt habe und hoffe auf sachbezogene Kritik.<br>
Bei Rückfragen stehe ich prinzipiell zur Verfügung.<br>
<br>
SG<br>
Erich<br>
<br>
Am 2013-03-27 02:31, schrieb Gottfried Motowidlo:<br>
</div>
<blockquote
cite="mid:!&!AAAAAAAAAAAYAAAAAAAAAKr214NBDHNGrBzHhcVW0NICgQAAEAAAAAd0VVwhgpZLuOhuEu2+CFIBAAAAAA==@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.E-MailFormatvorlage17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Lieber Erich!<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Ich bedaure, dass Du zu den Testtagen so
spät dazu gestoßen bist. Dadurch hast Du leider Stefans
hervorragend vorbereiteten IP-V6 Vortrag und eine ausgiebige
Diskussion samt Erläuterung der komplizierten Materie
verpasst. Kompliziert ist es u.a. deshalb, weil sich RFCs bei
Details z.T. widersprechen, sich gegenseitig aufheben oder
etwas vorgeben, ohne diese Vorgaben nachvollziehbar zu
begründen etc.<o:p></o:p></p>
<p class="MsoNormal">Ich verweise an dieser Stelle nur auf die
beinahe abartig anmutende Diskussion über die wirklich exakte
Auslegung von „::“. Beinahe 15 Jahre nach dessen Definition
gibt es da noch immer Interpretationsspielraum! Unglaublich...<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Aber zurück zur Sache:<o:p></o:p></p>
<p class="MsoNormal">Wesentlich ist, dass jedem 0xFF Standort
(siehe Node-ID im Redeemer oder auf der Map) ein 56 Bit
Site-Präfix zugewiesen wird. Darüber hinaus bekommst Du eine
Empfehlung, wie die Bits 57-63 vorzugsweise verwendet werden
sollten. Details siehe Konzept. Somit bleiben jedem Knoten-
bzw. Standortbetreiber 256 Adressräume zu je 64 Bit, die er
eigenverantwortlich gestalten und vergeben kann. Das müsste
genügend Platz für jedwede Kreativität bieten, oder? <o:p></o:p></p>
<p class="MsoNormal">Zusätzliche Regelungen werden dann
ausgearbeitet, wenn diese auf Grund konkreter Projekte
zwingend erforderlich erscheint. Bis dahin verstehen wir uns
als Experimentalnetz mit so wenigen Einschränkungen, als sie
zum Zweck der störungsfreien Zusammenarbeit unbedingt
notwendig sind.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Grüße Gottfried<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<br>
</body>
</html>