[IPv6-wien] Neue Inhalte auf www.ipv6.wien.funkfeuer.at

[Stefan Schultheis (home)]

Hallo,

Danke für die Erläuterung des Missverständnisses!
>
Gerne.

 Auch, wenn das Schema somit konform ist, sind dabei noch Fragen offen:
>
> Wie bereits erwähnt, und im anderen E-Mail ergänzt, soll *dieser Teil des
> Konzepts* 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
> http://tools.ietf.org/html/rfc6144.
>
> Gegen den *ersten Teil *- die Neuzuteilung von reinen IPv6-Adressen - *habe
> ich keinen Einwand*, jedoch hinsichtlich des "Transitition"-Konzepts
> erscheinen folgende Punkte unausgegoren:
>
> RFC6177, im Status der "Best current practice" empfiehlt in Punkt 2:
>
> 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.
>
>
> Dieser Punkt ist mit Zuteilung von /56-Hostnetzen für unsere IPv6-only und
> Dual-Stack-Geräte gemäß RFC6177 bereits erfüllt.
>
Danke, sehe ich als Bestätigung des Konzepts.


>  Hinsichtlich der Transition-Netzwerke besteht daher kein Bedarf an
> Verteilung weiterer Hostnetze (network-specific prefix).
>
OK, bestätigt das vorliegende Konzept.


>  Die Nutzung des "well-known prefix" /96 erscheint für die in unserem Netz
> vorherrschende Problemstellung aus Erwägungsgründen eher zweckmäßig:
>
/96 verhindert die künftige Nutzung der 8 Bits, die im vorigen Mail "u"
genannt wurden.

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.


>  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.
>
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.

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.
>
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.

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.
>
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.

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.
>
Bestätigt das Konzept der Gruppe.

Darüber hinaus steht es jedem Nodebetreiber frei, ein abweichendes
> 4-to-6-Mapping innerhalb seiner eigenen Hostnetz selbst umzusetzen, wenn
> daran Bedarf besteht.
>
Das ist in jeder Variante so.


> Ich stelle weiterhin den Antrag, den das Mapping betreffenden Teil des
> Konzepts vorerst einmal zu streichen und ans Reißbrett zurück zu verweisen.
>
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.
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.

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.

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.

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!

 LG
> Erich
>
LgS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.funkfeuer.at/pipermail/ipv6-wien/attachments/20130325/21ce817f/attachment.html>