[IPv6-wien] V6 Diskussion
Simon Schwendemann
(spam-protected)
Wed Mar 27 15:45:46 CET 2013
Hallo!
Bezüglich Seite 4:
Dies ist ein integraler Bestandteil des Konzepts und sollte meiner
Meinung nach auch so gelassen werden, da es einen einfacheren Umstieg
für bestehende User ermöglichen kann.
Dieses Konzept ist schon als Final anzusehen, finde es schade, dass du
nun nachträglich hier herumflamst. Ich denke es hat vorher genug
Möglichkeiten sich einzubringen.
lg
Simon
Ps.: Funkfeuer braucht meiner Meinung nach Leute die bemüht sind Sachen
vorwärtszubringen (z.B Personen wie z.B in diesem Fall Stefan) und nicht
Leute denen es nur darum geht zu diskutierern bzw die eigene Person ins
Rampenlicht zu stellen!
Am 27.03.2013 13:18, schrieb Erich N. Pekarek:
> Hallo Liste!
> Gottfrieds und Manfreds E-Mails zeigen mir, dass nur wenige der
> ihrerseits Kritik übenden Listenteilnehmer den Kern meiner Kritik
> verstanden haben:
>
> *_Gegenstand der Kritik:_*
> _*Seite 3 des *__*Konzepts
> <http://www.ipv6.wien.funkfeuer.at/download/konzept20130321.pdf>*__"__/Adressgestaltung
> mittels /__/*Node-ID Adressierung*/__/"/__wird von mir __*nicht
> beanstandet*__._
> *Beanstandet wird Seite 4* des Konzeptes /"Adressgestaltung mittels
> //*IPv4-Mapping*//"/. Dieses ist wohl kein integraler Bestandteil,
> sondern ein Add-on.
>
> *_Begründung:_*
> Der Inhalt von Seite 4 *widerspricht* einer *einheitlichen* und
> *eindeutigen*, sowie *skalierbaren* *Adressierung*, die als Vorgabe
> *bereits im* *Arbeitspapier* ausdrücklich genannt ist und aus den in
> früheren Mails genannten Gründen und stellt eine *Doppelgleisigkeit*
> dar. Der konkrete *Zweck* 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.
>
> *_Kompromiss:_*
> Den Inhalt von Seite 4 *sinngemäß* auf *Router-ID 0 des jeweiligen
> Nodes abzubilden*, 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.
>
> *_Bewertung der Auswirkungen einer Änderung:_*
> Zu diesem Zeitpunkt hätte eine Änderung kaum technische oder
> projektbezogene, organisatorische Auswirkungen.
> Eine spätere Änderung würde bei diesem und anderen Projekten einen
> erhöhten Aufwand bewirken und zur Verunsicherung der User beitragen.
>
> Ich hoffe, dass ich mich jetzt präziser und verständlicher ausgedrückt
> habe und hoffe auf sachbezogene Kritik.
> Bei Rückfragen stehe ich prinzipiell zur Verfügung.
>
> SG
> Erich
>
> Am 2013-03-27 02:31, schrieb Gottfried Motowidlo:
>>
>> Lieber Erich!
>>
>> 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.
>>
>> 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...
>>
>> Aber zurück zur Sache:
>>
>> 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?
>>
>> 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.
>>
>> Grüße Gottfried
>>
>
>
>
> _______________________________________________
> IPv6-wien mailing list
> (spam-protected)
> https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien
More information about the IPv6-wien
mailing list