[sage] IPv6 (war: IE und Self-Signed Certificates?)

[Benedikt Stockebrand]

Moin Andreas und Liste,

Andreas Jellinghaus <aj at dungeon.inka.de> writes:

>> Das war mein Punkt: Wenn man von heute verfügbarer Hardware zu den
>> heutigen Preisen ausgeht, dann stimmt das.  Aber das ist genau die
>> Form von Kurzsichtigkeit, mit der Bill Gates (und einige andere) sich
>> an verschiedenen Stellen ziemlich blamiert haben.
>
>  * die sache mit 640k ist eine urban legend, oder?

ob er den allgemein zitierten Spruch damals gebracht hat oder nicht,
will ich nicht beurteilen.  Aber dass diese Beschränkung von den
damaligen Intel/IBM/Microsoft-Produkten (der erste PC hatte laut
Wikipedia 16 kB RAM) kurzsichtig war, kann man wohl an der damaligen
Hardware, und insbesondere an den folgenden Krücken (A20 Gate,
expanded memory, extended memory, real vs. protected mode, ...)
deutlich sehen.

>  * soll das wieder eine nebelkerze sein?

Bitte lass die Polemik; wenn Du meinst, dass man heute grundsätzliche
Denkfehler nicht mehr macht, und deshalb nicht aus den Beispielen der
Vergangenheit lernen muss, dann ist das selbstverständlich Dir
überlassen.  Ich persönlich halte diesen Ansatz aber für
unrealistisch.

> stadt bei ipv6 zu bleiben kommst
>    du schon wieder mit 640k an (ich denke darauf wolltest du anspielen).

Nicht als solches, sondern als gängiges Beispiel für ein
zugrundeliegendes, viel grundsätzlicheres Problem.

> harte fakten wären hier viel interessanter.

"Harte Fakten" werden wir erst haben, wenn sie sich nicht mehr
nachträglich berücksichtigen lassen.  Aber nachdem Gert ja in einem
anderen Posting selbst nochmal auf die Nutzung des Adressraums
eingeht, schiebe ich lieber gleich in dem Kontext nochmal eine
Rechnung nach.

> die sache mit maximal 5 computern weltweit wäre ein beispiel für 
> kurzsichtigkeit. gibts sehr viele davon, in dieser welt. die kann man
> aber alle sehr gut belegen. wenn du eine kurzsichtigkeit im ipv6 design
> kennst, dann erklär sie bitte.

Ich habe nie von *Kurzsichtigkeit* geredet.  In meiner ursprünglichen
Mail, als Antwort auf Pi's Frage, habe ich nur gesagt, dass bei einem
wie auch immer endlichen Adressraum Gefahr laufen, dass es durchaus zu
einer künstlichen, wirtschaftlich motivierten Verknappung kommen kann.

> man kann zum beispiel mit recht sagen, das beim design von bgp keiner daran
> gedacht hat, das vielleicht man jedes schiff und jedes flugzeug einen festen
> ipv4 bereich haben will, und dynamisch routen will, und es dann mit 16bit AS
> nummern eng wird. 

Die AS-Nummern sind das kleinere Problem, die werden ja auch gerade
aufgebohrt.  Das Problem ist, dass dann in der Default Free Zone
ständig entsprechende Updates folgen.

> zudem wäre das boing beispiel doch mal ein guter aufhänger um zu zeigen,
> wie es besser geht. du kennst dich da viel besser aus, aber wenn ich um die
> 50 flugzeuge mit festen IP versorgen müsste, egal wo sie sind, da fände ich
> die 50 AS nummern und bgp gar nicht soo doof.

Erstens reden wir potentiell von deutlich mehr als 50 Flugzeugen und
zweitens wüsste ich nicht, warum es bei Flugzeugen bleiben sollte.  Es
gibt auch noch ICEs, ICs, Regionalzüge, S-Bahnen, Autos, Schiffe,
Netbooks, Handies, RFID-Chips und was weiss ich noch alles, was
prinzipiell mobil ist und mehr oder weniger dringend Netzanbindung
haben will.

Nach Aussagen einiger Leute, die in dem Bereich arbeiten, ist das
Thema "Mobilität" bisher nicht einmal in den dafür ja mehr oder
weniger konzipierten Mobilfunknetzen einschließlich UMTS wirklich
schlüssig und vor allem skalierbar gelöst.  Mobile IPv6, bei dem ich
andererseits aus Sicherheitsüberlegungen heraus erhebliche
Bauchschmerzen (siehe auch RFC 4487) habe, ist da einen Schritt
weiter, aber immer noch keine wirklich schlüssige Lösung; nach meiner
Auffassung stellt die Forderung nach Mobilität auch den gesamten
TCP/IP-Stack in Frage, nicht nur das Network Layer.

> laut cidr report sind aktuell
> 30000 AS in nutzung, da sollten 50 noch frei sein (und auch weitere hundert,
> falls 1 oder 2 konkurrenten das kopieren). die alternativen sind ja entweder
> routing nicht auf routing ebene zu machen, mobile ipv6 / handy welt nachbauen,
> oder vpn mit entsprechener latenz einmal um die erde im extremfall.

Bei der Latenz machst Du einen Denkfehler; die kommt bei
satellitengestützen Verbindungen im wesentlichen durch die
Funkstrecke.  Damit ist ein VPN-Ansatz durchaus eine Möglichkeit.

> welchen vorschlag hast du, wie boing das besser gemacht hätte?

Jede Maschine unterstützt einen Tunnel zu jeder Bodenstation und
verteilt per DHCP bzw. SAC immer bevorzugt Adressen aus dem Prefix der
Bodenstation, zu der sie gerade Verbindung hat.

Das ist zwar auch nicht wirklich schön, aber warum habe ich ja schon
oben versucht zu erklären.

>> Und wie gesagt, ich habe mindestens in einem Fall erlebt, dass noch
>> während einer Schulung Diskussionen losgingen, ob man nicht ein /32
>> bekommen könnte, um dann in einem Teil der Subnet ID bitweise zu
>> codieren, welche Ports von/zu einem Subnet auf den vorgeschalteten
>> Paketfiltern geöffnet sein müssten.
>
> dumme ideen gibts immer, manche organisationen bilden ein komitee um diese
> einzusammeln und möglichst viele in einen standard zu giesen. aber das ipv6
> von der sorte sein soll, müsste man mir schon belegen.

Nochmal: Ich halte IPv6 nicht für eine "dumme Idee", mit der ich
zufällig meinen Lebensunterhalt verdiene.  Aber auch IPv6 hat Grenzen,
von den Altlasten im übrigen TCP/IP-Stack bis zu nicht-technischen
Aspekten, die aber auch als solche nicht einfach zu ignorieren sind.

> was dein schüler
> in der schulung auf anhieb für ideen hat, macht nicht den standard schlecht.
> und ob so eine idee durch ripe vergabe verfahren geht - ich denke mal nicht.
> was ich von gert so gelesen habe.

Dann macht man eben einen auf ISP und bekommt sein /32.  Oder man ist
ein ausreichend großes amerikanisches Unternehmen und geht den Weg
über die US-Regierung und IANA direkt.

>> Ich würde vermuten, da hast Du etwas in den völlig falschen Hals
>> bekommen.
>
> ich habe eine allergie gegen "beweis durch anekdote".

Es geht hier nicht um "Anekdoten", sondern darum, aus den Fehlern der
Vergangenheit zu lernen.

Sicher, man kann diese "Anekdoten" als "Einzelfälle" abtun.  Das
passiert vor allem im Nachhinein, weil es vielen Leuten am Ego kratzt,
wenn man sagt, dass sie einen Fehler hätten vermeiden können, wenn sie
sich etwas mehr Gedanken um grundsätzliche Zusammenhänge gemacht
hätten.

> und substanz war in deinen mails wirklich nicht.

Was meinst Du mit "Substanz"?  Dass ich nicht hellsehen kann, sollte
niemand überraschen.  Und selbst wenn ich sagen würde, dass ich es
kann und wir am 17. Januar 2023 mit einem RFC "IPv6 Network Address
Translation" konfrontiert werden, würdest Du es erst in fünfzehn
Jahren glauben.

> wobei das thema, wenn man denn fakten auftischen kann, ja durchaus
> spannend ist.

Bitte erklär mir, was Du mit "Fakten" meinst bzw. akzeptierst.

>> Das war kein Rant, sondern der Versuch, an alten Beispielen ein
>> grundsätzliches Phänomen zu demonstrieren, das allzu viele Leute immer
>> wieder völlig überrascht: Man geht (meist unbewußt) von aktuellen
>> Gegebenheiten aus und extrapoliert dann weiter, ohne zu
>> berücksichtigen, dass sich diese Gegebenheiten ändern.  Im Fall der
>> 640 kB war das unter anderem deshalb so peinlich, weil das Moore'sche
>> Gesetz zu der Zeit schon lange bekannt war.
>
> nenn mal eine pre-pc plattform, die mehrere cpu zyklen inclusive erweiterung
> des speicherraums durchgemacht hat, ohne das programme neu geschrieben wurde.

Ich verstehe zwar nicht, was das mit meiner Aussage zu tun hat, aber
so aus dem Stand fallen mir (in alphabetischer Reihenfolge) ALGOL,
AS/400, dBase, Cobol, Fortran, Pascal, PL/1 und S/360 ein.

> das war eine zeit, in der neuer rechner hies software neu schreiben, mehr oder
> minder.

Nein, das hieß höchstens, *Assembler*- und CPU-spezifische Programme
neu zu schreiben.

> da neue cpu mit anderem befehlssatz gabs ja auch wenig alternative.
> damals waren viele crude hacks noch tolieriert - wir denken an die tolle idee
> "hmm, wo haben wir noch einen freien pin?" mit dem das a20 gate am tastatur
> kontroller zum schalten des addressüberlaufs verbunden wurde. 

"Crude Hacks" hat es auch danach noch mehr als genug gegeben; ob nun
die regelmäßig alle paar Jahre "überraschend auftretenden"
BIOS-Beschränkungen bei IDE-Festplatten in PCs oder das in Entwicklung
befindliche USB 3.0.

> all die geschichten sind aber kein grund zu behaupten, die ipv6 designer 
> hätten nicht weit genug gedacht. 

Habe ich irgendwo gesagt, dass sie "nicht weit genug gedacht" haben?
Wüsste ich ehrlich gesagt nicht.  Was ich sage ist dass IPv6
irgendwann an Grenzen stoßen wird und vor allem, dass der TCP/IP-Stack
von seinem grundsätzlichen Aufbau her Beschränkungen mit sich bringt,
an denen IPv6 auch nichts ändern kann.  Insbesondere der zweite Punkt
hat zu einer ganzen Reihe von ziemlich problematischen Entwicklungen
geführt, um Probleme in IPv6 zu lösen, die an einer anderen Stelle
liegen.  Dazu gehören für mich insbesondere die Sachen, die IPv6
stateful machen: Mobile IPv6, IPsec und vor allem IntServ.

> 2^128 addressen, wenn es nur 2^90 atome im universum gibt (falls
> endlich),

Diese Zahlen sagen genau gar nichts aus, weil Du nicht
berücksichtigst, wie viele der 2^128 Adressen tatsächlich praktisch
nutzbar sind.  Die Rechnung dazu kommt aber noch separat, weil Gert da
noch was nachgeschoben hat, worauf man recht gut aufbauen kann.

> kurz: zumindest bgp mit aktueller hardware/software ist nicht auf das routing
> von schiffen und flugzeugen ausgelegt? wundert mich nicht, daran hat auch
> keiner gedacht damals, denke ich (zumindest wären mir keine entsprechenden
> paper bekannt).

Und wenn jemand das damals schon gesagt hätte, hätten Leute mit Deiner
Argumentationsweise damals gesagt, dass das unrealistisch ist, weil
man wohl kaum in jedes Flugzeug eine VAX einbauen würde.

>> Für mein Verständnis ist IPv6 ein ziemlicher Schritt nach vorne, aber
>> ein Allheilmittel ist es nun wirklich nicht.
>
> na dann lass uns doch daran teil haben. bill gates, deine schüler und boings
> umsetzung von routing für flugzeuge sind für mich anekdoten, aber keine
> probleme von ipv6. du könntest genau so gut damit sonstwas begründen wollen.

Bitte lies nochmal Pi's ursprüngliche Fragestellung.  Die hatte nichts
mit IPv6 zu tun, außer dass sich für einige Überlegungen dabei IPv6
als Beispiel anbietet.

Was die "Probleme von IPv6" angeht: Das Haupt-"problem" ist, dass man
vor zehn Jahren versucht hat, ein einzelnes Problem zu lösen und dazu
nur eine begrenzte Baustelle aufgemacht hat, nämlich das Network
Layer.  Der TCP/IP-Stack stößt aber auch an anderen Stellen an
Grenzen, unter anderem durch sein grundsätzliches Design.  Das soll
aber nicht heißen, dass es damals ein Fehler war, nicht gleich den
gesamten TCP/IP-Stack durch etwas neues zu ersetzen -- dann wären wir
heute vermutlich noch lange nicht an dem Punkt, eine einsetzbare
Lösung zu haben.


Viele Grüße,

    Benedikt

-- 
Benedikt Stockebrand, Dipl.-Inform.   http://www.benedikt-stockebrand.de/