Re: Buch "IPv6 Essentials"
Ralph Angenendt
> Das Buch "IPv6 Essentials"
> http://www.amazon.com/dp/0596100582/
> kann von
amazon geliefert werden. Ansonsten verpiss dich.
Ralph
--
If the future isn't bright, at least it's colourful.
Nicht schreiben können: http://lestighaniker.de/
Armin Wolf
> Das Buch "IPv6 Essentials"
> [...]
> kann von
> [...]
> als EPUB-Buch runtergeladen werden.
>
> Kann man größtenteils querlesen da man für die Praxis
> die genauen Details zu nem guten Teil nicht wissen muss.
Weshalb muß ich erst nach einem Reader googeln?
<http://www.adobe.com/products/digitaleditions/#fp>
Was soll ein englischsprachiges Werk in .de- Gruppen,
wo es doch unter <http://de.wikipedia.org/wiki/IPv6>
genügend Infos und Quellen gibt?
Wie hoch ist Deine Provision?
Dietz Proepper
> "eBooks" <ebo...@Use-Author-Supplied-Address.invalid> schrieb
>
>> Das Buch "IPv6 Essentials"
>> [...]
>> kann von
>> [...]
>> als EPUB-Buch runtergeladen werden.
>>
>> Kann man größtenteils querlesen da man für die Praxis
>> die genauen Details zu nem guten Teil nicht wissen muss.
>
> Weshalb muß ich erst nach einem Reader googeln?
> <http://www.adobe.com/products/digitaleditions/#fp>
Deine Softwarekomposition ist kaputt :-).
--
CASE NIGHTMARE BLUE
Florian Weimer
> http://www.amazon.com/dp/0596100582/
Das Buch ist überholt oder schlicht falsch, je nach Sichtweise. Es
nennt folgende Vorzüge für IPv6:
| Extended address space
Dafür ist die Verwendung von IPv6-Adressen u.U. beschränkt. Es ist in
vielen Fällen derzeit noch einfacher, IPv4-Adressen für Anwendungen
Webhosting zu bekommen.
Urteil: langfristig sicherlich korrekt, im Moment noch etwas holprig
| Autoconfiguration
Insbesondere "Stateless autoconfiguration" kann aus prinzipiellen
Gründen nicht funktionieren, weil das Netz zur Quelladreßvalidierung
Zustand halten muß (genauso wie bei IPv4).
Urteil: widerlegt
| Simplification of header format
Es wird eine feste Länge von "40 bytes" für den IPv6-Header behauptet.
Das stimmt aber nur durch Neusprech. Ein Paketfilter, der z.B. die
UDP-Portnummern prüfen will, muß immer noch einen Header variabler
Länge überspringen. Das ist sogar wesentlich schwieriger als bei IPv6,
weil der erste Header nicht mehr die Gesamtlänge aller Header enthält.
Urteil: widerlegt
| Improved support for options and extensions
Die beschriebenen Erweiterungen sind größtenteils inzwischen als
unsicher bekannt und müssen gefiltert oder ignoriert werden. Wegen der
verketteten Liste von Headern ist die Verarbeitung in Paketfiltern
wesentlich ineffizienter als bei IPv4. Da selbst Fragmentierung über
eine Erweiterung signalisiert wird und für DNSSEC über IPv6 in der
Praxis zwingend erforderlich ist, können nicht mal alle Erweiterungen
ohne weiteres ignoriert werden (im Gegensatz zu IP-Optionen bei IPv4).
Urteil: widerlegt
Wer so etwas raubkopiert, hat es nicht besser verdient.
Das traurige ist, daß die Schwierigkeiten schon ziemlich früh bekannt
waren (wenn auch vielleicht nicht die zwingende Notwendigkeit, so
ziemlich überall im Netz UDP- und TCP-Portinformation zu extrahieren),
aber die IETF strukturell nicht in der Lage war, einfach die
Adreßlänge auf 64 oder 128 Bit aufzubohren, ohne sonst etwas zu
ändern.
Helmut Springer
> Das traurige ist, daß die Schwierigkeiten schon ziemlich früh
> bekannt waren (wenn auch vielleicht nicht die zwingende
> Notwendigkeit, so ziemlich überall im Netz UDP- und
> TCP-Portinformation zu extrahieren), aber die IETF strukturell
> nicht in der Lage war, einfach die Adreßlänge auf 64 oder 128 Bit
> aufzubohren, ohne sonst etwas zu ändern.
Second-System Effect.
--
MfG/Best regards
helmut springer panta rhei
Simon Krahnke
>> Das Buch "IPv6 Essentials"
>| Extended address space
>
> Dafür ist die Verwendung von IPv6-Adressen u.U. beschränkt. Es ist in
> vielen Fällen derzeit noch einfacher, IPv4-Adressen für Anwendungen
> Webhosting zu bekommen.
>
> Urteil: langfristig sicherlich korrekt, im Moment noch etwas holprig
Ah ja.
>| Autoconfiguration
>
> Insbesondere "Stateless autoconfiguration" kann aus prinzipiellen
> Gründen nicht funktionieren, weil das Netz zur Quelladreßvalidierung
> Zustand halten muß (genauso wie bei IPv4).
3 Parseversuche bis ich meinte, was abstrakt gemeint sein könnte. Was
das konkret heißen soll, ist mir weiter unklar.
MAC-Validierung ist jedenfalls out-of-scope.
> Urteil: widerlegt
>| Simplification of header format
>
> Es wird eine feste Länge von "40 bytes" für den IPv6-Header behauptet.
> Das stimmt aber nur durch Neusprech. Ein Paketfilter, der z.B. die
> UDP-Portnummern prüfen will, muß immer noch einen Header variabler
> Länge überspringen. Das ist sogar wesentlich schwieriger als bei IPv6,
> weil der erste Header nicht mehr die Gesamtlänge aller Header enthält.
"header format" != "header usability for packet filters"
> Urteil: widerlegt
>| Improved support for options and extensions
> Die beschriebenen Erweiterungen sind größtenteils inzwischen als
> unsicher bekannt und müssen gefiltert oder ignoriert werden. Wegen der
> verketteten Liste von Headern ist die Verarbeitung in Paketfiltern
> wesentlich ineffizienter als bei IPv4. Da selbst Fragmentierung über
> eine Erweiterung signalisiert wird und für DNSSEC über IPv6 in der
> Praxis zwingend erforderlich ist, können nicht mal alle Erweiterungen
> ohne weiteres ignoriert werden (im Gegensatz zu IP-Optionen bei IPv4).
Dein einziges Argument scheint Verarbeitung in Paketfiltern zu sein.
Wer nach Portnummern filtert, hat Schwierigkeiten verdient.
> Urteil: widerlegt
mfg, simon .... l
Juergen P. Meier
Simon Krahnke <over...@gmx.li>:
> * Florian Weimer <f...@deneb.enyo.de> (22:53) schrieb:
>
>>> Das Buch "IPv6 Essentials"
>
>>| Extended address space
>>
>> Dafür ist die Verwendung von IPv6-Adressen u.U. beschränkt. Es ist in
>> vielen Fällen derzeit noch einfacher, IPv4-Adressen für Anwendungen
>> Webhosting zu bekommen.
>>
>> Urteil: langfristig sicherlich korrekt, im Moment noch etwas holprig
>
> Ah ja.
Immerhin etwas, dass sich bereits deutlich bessert und bald als Kritik
nicht mehr existiert.
>>| Autoconfiguration
>>
>> Insbesondere "Stateless autoconfiguration" kann aus prinzipiellen
>> Gründen nicht funktionieren, weil das Netz zur Quelladreßvalidierung
>> Zustand halten muß (genauso wie bei IPv4).
>
> 3 Parseversuche bis ich meinte, was abstrakt gemeint sein könnte. Was
> das konkret heißen soll, ist mir weiter unklar.
RFC 2462, §5.4, Punkt 2.
Wo das z.B. regelmaessig knallt sind Virtuelle Hostingumgebungen:
Es ist einfach nicht lustig, wenn man zwei Hosts mit der selben IPv6
link-local sowie Unicast IP hat, die beide meinen eine Duplicate-Address-
Detection sei ueberfluessig.
Insbesondere wenn clevere Admins VMs einfach klonen.
> MAC-Validierung ist jedenfalls out-of-scope.
Leider. Weil man sich hier nicht an der Praxis orientiert hat, sondern
eine bereits praktisch zur Irrelevanz verkommene Annahme eines fremden
Standards blind uebernommen hat.
>> Urteil: widerlegt
ACK.
>>| Simplification of header format
>>
>> Es wird eine feste Länge von "40 bytes" für den IPv6-Header behauptet.
>> Das stimmt aber nur durch Neusprech. Ein Paketfilter, der z.B. die
>> UDP-Portnummern prüfen will, muß immer noch einen Header variabler
>> Länge überspringen. Das ist sogar wesentlich schwieriger als bei IPv6,
>> weil der erste Header nicht mehr die Gesamtlänge aller Header enthält.
>
> "header format" != "header usability for packet filters"
Bei "simplification" geht es um die maschinenlesbarkeit aller Header.
Und die ist bei IPv6 oberhalb der IP-Schicht teilweise schlechter as
bei IPv4. Insbesondere wenn Optionen und Extensions verwendet werden.
>> Urteil: widerlegt
Von daher: ACK.
>>| Improved support for options and extensions
>
>> Die beschriebenen Erweiterungen sind größtenteils inzwischen als
>> unsicher bekannt und müssen gefiltert oder ignoriert werden. Wegen der
>> verketteten Liste von Headern ist die Verarbeitung in Paketfiltern
>> wesentlich ineffizienter als bei IPv4. Da selbst Fragmentierung über
>> eine Erweiterung signalisiert wird und für DNSSEC über IPv6 in der
>> Praxis zwingend erforderlich ist, können nicht mal alle Erweiterungen
>> ohne weiteres ignoriert werden (im Gegensatz zu IP-Optionen bei IPv4).
>
> Dein einziges Argument scheint Verarbeitung in Paketfiltern zu sein.
> Wer nach Portnummern filtert, hat Schwierigkeiten verdient.
Wer noch nach Portnummern filtert, hat mindestens ein Jahrzehnt
verpennt.
Moderne SEGs filtern vorwiegend nach Inhalten und Anwendungen. Und
bei IPv6 ist das deutlich aufwaendiger (in schnelle, effiziente
technik zu giessen) als bei IPv4. Und damit werden Systeme, die
derzeit IPv4-Basierte Anwendungen mit linespeed filtern koennen,
zukuenftig zum Flaschenhals. Und man muss viel Geld verschwenden sie
aufzuruesten.
>> Urteil: widerlegt
>
> mfg, simon .... l
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Ignatios Souvatzis
>> Das Buch "IPv6 Essentials"
>> http://www.amazon.com/dp/0596100582/
>
> Das Buch ist überholt oder schlicht falsch, je nach Sichtweise. Es
> nennt folgende Vorzüge für IPv6:
>
>| Extended address space
>
> Dafür ist die Verwendung von IPv6-Adressen u.U. beschränkt. Es ist in
> vielen Fällen derzeit noch einfacher, IPv4-Adressen für Anwendungen
> Webhosting zu bekommen.
>
> Urteil: langfristig sicherlich korrekt, im Moment noch etwas holprig
Die Länge ist nicht all zu lang...
<http://www.zdnet.com/blog/networking/it-8217s-official-asia-8217s-just-run-out-of-ipv4-addresses/948>
-is