Hi,
On Wed, Sep 01, 2004 at 02:04:59PM +0200, Benedikt Stockebrand wrote:
> [Weil ich's gestern in einem seltenen Anfall geistiger Umnachtung nur
> an Gert geschickt habe mit einiger Versp�tung:]
>
> Moltijd,
> > Middach :)
Wie auch immer :-)
[..]
> > 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.
Stimmt schon. Aber eben weil das schon muehsam genug ist, sehe ich
zusaetzliche Latenzen mit Sorge. "Mit IPv6 ist alles ja viel langsamer
als bisher".
[..]
> > 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:-)
Genau das ist das Problem. *Welcher* Provider? Der, wo Dein Home-Agent
steht? Der, der das Auto mit IPv6 versorgt? Derjenige, der den IPv6-Stack
fuer Dein Notebook gebaut hat?
Im Zweifel gibt es ein Problem zwischen dem Auto-ISP und dem Home-Agent-
Provider der Gegenstelle, was sich aber nur manifestiert, wenn eine
HomeAddress-Option im Paket gesetzt ist (also mit normalem Traceroute
nicht feststellbar), weil irgendeine Firewall etwas uebereifrig die Pakete
anguckt.
> > Speziell vor letzterem graust mir.
... wie schon gesagt - ich sitze dann naemlich auf der Provider-Seite,
der Kunde jammert "es geht nicht", und habe im Zweifel weder die
Moeglichkeit, *irgendwas* zu tun (weil die Datenpakete gar nicht ueber
uns laufen), noch es zu diagnostizieren...
[..9
> 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.
Und wie genau loest der Wechsel des Link-Layers das Ende-Ende-Connectivity-
Problem zu genau *der* Gegenstelle, mit der Du gerade VoIP-Telefonieren
moechtest?
Was, wenn der Home-Agent einfach nur gerade wegen Leitungsausfall "zu Hause"
nicht erreichbar ist?
usw...
> 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). [..]
Hier rennst Du bei mir offene Tueren ein :-)
(Mein naechstes Experiment ist IPv6-IPSEC mit NetBSD-2.0, was lt. Doku
eigentlich problemlos funktionieren muesste...)
[..]
> >> 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.
Ja, der Zug ist vermutlich auch schon abgefahren.
> 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.
Baaaaaeeeehhh... :-(
[..]
> >> 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
Polling? Das kann nicht Dein Ernst sein :-)
(Ausserdem ist das zu langsam, denn damit kriegst Du die neue Adresse
ja erst, wenn zufaellig mal ein RA vom neuen Router vorbeikommt. Eigentlich
willst Du in dem Moment, wo sich auf dem Link-Layer was tut, sofort nach
Routern suchen, und dann "wenn neues Prefix" gleich entsprechende
Aktionen triggern)
> 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.
Das waere sein Untergang. Die Konfiguration muss vollkommen automatisch
ablaufen, bzw. mit genau zwei Optionen:
Mobile IPv6-Support [ ] an [x] aus
Heimataddresse [ ]
[..]
> > 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.
IPSEC geht nicht (MN kenns den CN nicht, es gibt keine PKI), aber dafuer
gibt es entsprechende Vorschlaege in der MIP6-RFC, die durchaus
funktionieren (return routability test).
Muss man nur halt auch erst implementieren.
> > 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).
Natuerlich ist das alles nicht "unloesbar" - aber es erhoeht die Code-
Komplexitaet erheblich, und damit schleichen sich auch wieder haesslich
zu findende Bugs ein...
Wenn man das dann auch noch Handy-Hersteller implementieren laesst, die
nicht mal "Voice ueber GSM" richtig koennen, dann muesste es Dich eigentlich
auch gruseln.
Gert Doering
-- NetMaster
--
Total number of prefixes smaller than registry allocations: 65398 (60210)
SpaceNet AG Mail: [EMAIL PROTECTED]
Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0
80807 Muenchen Fax : +49-89-32356-299
_______________________________________________
ipv6 mailing list
[EMAIL PROTECTED]
http://listserv.uni-muenster.de/mailman/listinfo/ipv6
