[Weil ich's gestern in einem seltenen Anfall geistiger Umnachtung nur an Gert geschickt habe mit einiger Versp�tung:]
Moltijd, > Middach :) ...wenn ein Nordafrikaner versucht, Deutsch zu sprechen... Wenn �berhaupt hei�t das dann "Moin Dag". Oder "Moltijd". Und Jeroen hat vermutlich noch drei bis zwanzig andere Varianten auf Lager. (Wer's genau wissen will: http://www.plattmaster.de/moinmoin.htm) > [Mobility-Aware Apps vs. Mobile IPv6] > > Ja und nein. Fuer die Anwendung ist es komplett transparent - aber sie > muss mit den Nachteilen leben, die da m.E. "deutlich hoehere Latenz beim > Verbindungsaufbau" und (wenn der CN kein MIP6 kann) "hoehere Latenz der > eigentlichen Datenpakete". Das hast Du auch schon, wenn Du das gleiche Protokoll wahlweise �ber Gigabit Ethernet im lokalen Netz und �ber eine analoge Einwahlleitung (von GPRS will ich gar nicht reden) benutzt. Bei echtzeitnahen Applikationen wird das unter Umst�nden unsch�n, aber f�r POP3/IMAP/SMTP zum Beispiel spielt es keine wirkliche Rolle. In dem Fall sind schon eher die Kosten interessant---was nicht hei�t, da� sich da jemand bisher gen�tigt sieht, eine Kostensperre zu konzipieren. Woran das jetzt schon wieder liegt? > Dazu kommt die totale Unmoeglichkeit, sowas zu debuggen, wenn es mal > nicht funktioniert (der Notebook haengt mit seiner HomeA in einem > Auto-WLAN, was sich mit NEMO in der Gegend rumbewegt, und kann eine > Gegenstelle nicht erreichen, die mit GPRS und MIP6 in einem anderen > Handy-Netz rumroamt...). Da trete ich meinem Provider in den Ar... und der hat sich dann gef�lligst darum zu k�mmern:-) > Speziell vor letzterem graust mir. Dabei habe ich seit mindestens f�nfzehn Jahren keine Stahlkappen mehr in den Schuhen... Aber ernsthaft: Mit dem Debugging das wird sicherlich nicht einfach, ist aber eine Frage der Tools, der Erfahrung, und letztlich auch der Hardware dahinter. Wenn ich Mobile IPv6 in Verbindung mit Multiprotokoll-Devices einsetze, die zum Beispiel wahlweise LAN, WLAN, UMTS und GPRS unterst�tzen, dann sollte es m�glich sein, damit etwas zu stemmen: Wenn der Mobile Node den Home Agent nicht erreicht, wechselt er den Link Layer. Da� da in vielen Punkten schon die Basis bisher noch auf reichlich wackligen Beinen steht, ist eine andere Sache. Aber deswegen k�mmere ich mich ja auch lieber um Grundlagen als um all die tollen Sachen, die darauf aufbauen (sollen). Bevor eine Reihe Unixe beim Booten keine saubere DAD macht, sich mindestens ein Router Advertisement Daemon beim Runterfahren nicht mehr die M�he macht, die Valid und Preferred Lifetime sauber runterzusetzen und sich die Situation bei den Paketfiltern im besten Fall mit "solange kein Schwein IPv6 benutzt, k�nnte es damit gutgehen" beschreiben l��t, sind meine pers�nlichen Priorit�ten klar. Aber wer heute nicht wenigstens die Themen andenkt, mu� sie morgen in einer deutlich gr��eren Landschaft nachflicken. >> SCTP habe ich mir noch nicht genauer angesehen. Wie weit mu� ich da >> noch in der jeweiligen Anwendung eingreifen? > > Weit. SCTP ist ein Protokoll "neben" TCP und UDP, was mit einem Buendel > von Source- und Destination-Adressen arbeitet, also auch jederzeit waehrend > der Session spontan auf andere Adresspaare ausweichen kann, wenn irgendwas > wegfliegt. > > Eine Anwendung muss also zumindest andere Socket-Funktionen zum Session- > Aufbau verwenden. Damit ist SCTP auf die F�lle beschr�nkt, wo sich der Aufwand rechtfertigt. F�r VoIP und Konsorten ist das wohl uneingeschr�nkt sinnvoll, bei neuen Protokollen mu� man es abw�gen, aber f�r die Masse der existierenden Protokolle ist das ein Schlag nach hinten. Das f�hrt dann fr�her oder sp�ter dazu, da� PPP in einer propriet�ren Variante so aufgebohrt wird, da� es SCTP benutzen kann, um dann dar�ber zu tunneln, so da� mit H�ngen und W�rgen f�r einen bestimmten Zweck ansatzweise das dabei herauskommt, was mit Mobile IP allgemein zur Verf�gung gestellt werden soll. Die Suche nach noch krankeren "L�sungen" �berlasse ich den bekannten Spezialisten f�r diese Aufgabe... >> Was ist an dem Protokollaufwand so immens? Es werden eine Reihe >> Sachen wiederbenutzt, von der Encapsulation �ber IPsec (hatten wir ja >> schon) bis zur API. Und vom grunds�tzlichen Aufbau ist es nicht so >> unendlich komplex. > > "Rausfinden, ob man gerade in einem anderen Netz ist" ifconfig -a Wobei an dem Punkt schon deutlich wird, da� Mobile IP ein inh�rentes Problem mitbringen k�nnte: Es kann sein, da� die Konfiguration von Mobile Nodes vergleichsweise aufwendig wird. > IPSEC zum HA (schwierig genug) Das ist ein Problem von IPsec, nicht von Mobile IPv6. Das meinte ich mit dem Protokoll-Recycling. Da� IPsec an genug stellen auch noch problematisch ist, ist eine andere Baustelle. Man k�nnte an der Stelle argumentieren, da� es sich nicht lohnt, �ber Mobile IP zu diskutieren, solange IPsec nicht etabliert ist. Aber wenn nicht einmal ein Versuch einer Spezifikation existiert, bekommen einige Vertreter der R�stungsindustrie vielleicht doch mal rote Ohren, wenn sie wieder behaupten, da� das alles schon l�ngst funktioniert. Und dann kann die das Geld kosten, deshalb schicken sie Leute in die IETF. (F�r alle, die nicht dabei waren: Ich meine damit einige Vortr�ge beim "European IPv6 Summit" in Bad Godesberg im letzten Juni.) > Absichern des Binding-Update zum CN Im Zweifelsfall geht auch das per IPsec und redundante Link-Layer-Protokolle (s.o.). Nicht da� das trivial w�re, aber die M�glichkeiten sind da. > HMIP6 (Flags im RA) Ja schon, aber auch das scheint kein unl�sbares Problem zu sein. Der rtadvd aus der KAME-Implementierung scheint alles dazu an Bord zu haben, soweit ich das den Man Pages gerade entnehmen konnte (was nicht hei�t, da� ich das getestet h�tte). Ich sage nicht, da� das ganze trivial ist, aber es scheint machbar zu sein und stellt eine Basis zur Verf�gung, auf der andere aufsetzen k�nnen, ohne gleich wieder zu irgendwelchen gebastelten Notl�sungen zu greifen: >> Aber auch da k�nnte man so argumentieren: Es gibt einen NAT-Router, >> der das alles auf eine einzelne Adresse umbiegt und dann tut's auch >> normales Mobile IP---sogar ohne v6. > > Baeh... Genau. Aber das hei�t nicht, da� sowas nicht von irgendeiner Software-Klitsche kommt und sich auch noch durchsetzt. Ich denke wir kennen alle genug kaputte Protokolle, wo genau sowas passiert ist. NAT ist da noch nicht das Schlimmste, was einem unterkommen kann---DirectX �ber HTTP finde ich da noch deutlich perverser, und auch das ist eine "etablierte Basistechnologie". Dann lieber eine halbwegs brauchbare Spezifikation, an die sich auch eine gr��ere Software-Klitsche am Ende h�lt, weil sie sonst mit ihrer n�chsten Betriebssystem-Version (ich wei�, da� ich hier den Begriff "Betriebssystem" sehr weit auslege) noch l�nger brauchen. Viele Gr��e, Benedikt -- Benedikt Stockebrand, Dipl.-Inform. Freelance IT System Architect http://www.benedikt-stockebrand.de/ always looking for a contract Unix (all flavours), TCP/IP, IPv6, IT Security, Unix Operations Training Performance and High Availability Tuning, Large Scale Systems Design _______________________________________________ ipv6 mailing list [EMAIL PROTECTED] http://listserv.uni-muenster.de/mailman/listinfo/ipv6
