🚀 go-pugleaf

>                              - OSITEL/400 message -
>
> Verursacher:                      C=DE;A=DBP;P=FGAN;O=FFM;OU=RUFVAX;S=bel
> Erstempfaenger:                   C=de;A=dbp;P=dfn;OU=zpl;S=win-ip/c
> Betreff:                          hinweise

Schoene Header.

> liebe kollegen,
> einige anmerkungen zu herrn kaehler's hinweisen:
> 1.) die hinweise in der vorliegenden form sind wohl mehr fuer die
> betreiber eines routers an einem LAN ins WIN/IP gedacht, als fuer
> die einzelnen tcp/ip benutzer, fuer die man lokal benutzungshinweise
> erstellen sollte, bis auf eine formulierung des "acceptable use"
> des DE-Internets.

Stimmt, er ging ja nie dadrum, wie jemand in seinem lokalen Netz
etwas betreiben soll, sicherlich waere es aber sinnvoll, Erfahrungen in diesem
bereich auch zu sammeln, und schriftlich zur Verfuegung zu stellen.
(Haetten Sie nicht auch Lust dazu ?).

> 2.) nutzung von ip ueber win kann mit zwwei zielsetzungen geschehen:
>   a) erreichen von tcp/ip partnern ausserhalb deutschlands (nicht nur
>     usa - denn ripe sollte man nicht ganz aus der sicht verlieren)
>   b) erreichen von tcp/ip partnern in deutschland ueber das win
>      (nicht win partner muessen in gegenseitiger absprache direkt
>       angesprochen werden. z.B. wenn wir mit uni erlangen ip'en
>       wollen, muessten wir win benutzen, fuer sel dagegen uns direkt
>       mit denen zusammensetzen)

Eine IP-Verbindung in die Staaten zu ereichen ist technich ziemlich einfach,
dazu muss man nur zu seinem Forwarder (im Moment Dortmund oder Karsruhe,
spaeter DFN Gatewaybetreiber auch noch), eine IP/X.25 Verbindung aufbauen,
und eine default route eintragen. Viel mehr Arbeit macht es allerdings,
dafuer zu sorgen, dass man alle Netze in der Bundesrepublik IP-maessig
erreichen kann, weil man dazu zu jeder Institution solch eine IP/X25
Verbindung konfigurieren muss, deshalb auch die Bemuehungen in diese
Konfigurationsaufgaben eine Struktur hineinzubringen.

> 3.) erhaelt ein teilnehmer nach vertragsabschluss mit dem dfn von
>     diesem eine ip-nummer (bereich) zugeteilt ? dfn verteilt doch
>     wohl nur ip-addresse fuer router. das lan kann doch schon eine
>     eigene ip-adresse haben (evtl schon mit connect status z.b. wir
>     haben 128.7. beim sri-nic eingetragen !). als lan betreiber
>     wuerde ich nicht die adressen nur deshalb aendern muessen, weil
>     wir auch ueber win ip machen wollen.

Gut, das sollte in dem entgueltigen Paper besser beschrieben werden.
Die Adresse fuer den Router auf dem 188.1 Netz wird im Moment
durch herrn Volk (rv@unido.uucp) vergeben, zukuenftig wird dies
der DFN-Gateway Betreiber machen. Zusaetzlich hat/wird sich das DFN bemuehen,
eine Reihe von Class-B und Class-C netzen zu bekommen, fuer die
pauschal in den Staaten Internet-Connected Status eingetragen wird,
und die schon auf den IP-Gateway des DFN geroutet werden.
Wenn dann jemand, der _NOCH_NICHT_ im Besitz gueltiger Netzwerkadressen
ist, zum DFN geht, dann bekommt er dort (und eben hoffentlich schneller
als beim NIC) ein Netzwerk, das dann gleich schon ueber das Internet
zu erreichen ist (schlechtes Beispiel: zwischen dem "Ja, ihr netzwerk
hat Internet connected Status" vom NIC, und dem technischen funktionieren
vergigngen bei uns 2 Monate, das sollte durch oben beschriebene Organisation
verbessert werden). Natuerlich hilft das denjenigen, die jetzt schon Netz-
werknummern verwenden, und diese behalten wollen, nix mehr. Da heisst
aber bloss, dass dann der Internet-Connected Status auf dem ueblichen
Weg erreicht werden muss, aber das uebernimmt dann ja sowieso der
DFN-Gatewaybetreiber (den Papierkram dafuer, meine ich).

> 4.) wenn dfn ip adresse vergibt muss er auch fuer connect-status sorgen.
S.o.

> 5.) vollfunktionale router:
>    bezueglich gateway protokolle sollte man nicht unbedingt egp anfuehren,
>    (vgl. ietf nachricht von mir)

Jein, der Artikel war recht nett, beschreibt aber die Zukunftsabsichten
fuer ein IGP, was man als Routingprotokoll zwischen den Routern auf
dem WiN braucht ist ein protokoll, was es im Moment nicht gibt, weil
die Amerikaner so etwas nie brauchten (dort gibt es solch ein Netz
als backbone Netz nicht), und was wohl auch nicht kommt (weil sich in
Deutschland schwerlich jemand hinsetzen wird um es zu entwickeln).
EGP ist ein EGP (ja, hoert sich dumm an), und damit schon mal besser
geeignet fue diese Aufgabe, als ein IGP. Mithin ist EGP im Moment
das einzige Protokoll, das man dafuer nehmen _koennte_. Man wird
es austesten muessen. RIP, OSPF und IS-IS sind ungeeignet (das kann ich
auch erklaeren, aber nur wenn die Einzelheiten interessieren).

>    router sollte unbedingt trace funktion haben, um evtl. fehler
>    besser suchen zu koennen
Ja, ich kann mir auch eine Menge von Dingen vorstellen, die ein
Router haben sollte. Ihr beispiel beleuchtet natuerlich ein generelles
problem: bei IP gibt es sehr viele Protokolle und Applikationen,
und einige davon koennen gerne mal viel_zu_viel Traffic erzeugen,
mir ist das mit dem nameserver aehnlich gegangen.
So etwas herauszufinden ist aber nicht notwendigerweise eine Aufgabe
des X.25/IP routers, sondern kann auch von anderen Monitorstationen
uebernommen werden (die z.B. nur am Ethernet haengen).

> 6.) fuer jeden router muss ein zustaendiger da sein, an den man
>     evtl. fehlverhalten eines teilnehmers an dessen lokalen netz
>     melden kann, damit er dies abstellt z.B. wenn wieder einmal
>     entdeckt, dass man mit icmp-echo herrlich die konnektivitaet
>     von netzen feststellen kann und nun dauernd verbindungen nach
>     australien, hawaii korea etc herstellt und laufzeiten "misst".

Stimmt, haben sie schon die 188.1 Liste erhalten ?

> 7.) nicht vollfunktionale router sollten nur fuer eine begrenzte
>     zeit zugelassen werden bis ein cisco box o.ae. bestellt und
>     geliefert ist.

Tja, das ist meiner meinung nach ein wenig von oben herab, nicht
jeder hat schliesslich das Geld fuer so etwas. Das Konzept sieht ja
auch vor, solche nicht voll-funktionsfaehigen Router hinter
voll-funktionsfaehigen Routern zu "verstecken", womit sich die
probleme wieder loesen.

> 8.) auch im sttischen routing sollten default eintrage verboten sein.
Tatsaechlich ? - Wie wollen Sie die Netze in den USA erreichen, wollen
sie die alle eintragen, ich halte das fuer ueberfluessig ?

> 9.) bei der paketgroesse 1024 byte habe ich bauchschmerzen:
>    die cisco koennen das aber nicht alle unix systeme (4.2 bsd)
>    ausserdem vergroessern sich round trip zeiten gewaltig.
>    (Zahlen liefere ich noch wenn wir wieder mit uk testen koennen)
>    segmentieren sollte man moeglichst vermeiden.
>    kann sein, dass hier die empfehlung fuer usa und innerdeutschen
>    verkehr getrennt werden sollte.
>    auf jeden fall sollte man die beliebten telnet mini pakete
>    mit einem datenbyte verbieten (kein remote echo beim telnet!)

1. Die Paketgroesse von 1024 war fuer die Datex-P Pakete gemeint.
Die empfohlene MTU fuer die IP-Pakete ist 576, und damit ergibt sich,
dass eine X.25 paketgroesse von 1024 notwendig ist, um 576 grosse
IP-Pakete als ein X.25 Paket verschicken zu koennen, und es nicht
als X.25 paketsequenz zu verschicken. Wenn man naemlich IP-Pakete als
X.25 Paketsequenzen verschickt, hat das auch sehr negative Auswirkungen,
insbesondere bei TCP Verbindungen. Durch die Sequenzierung der X.25
Pakete geraten naemlich oft Pakete aus anderen virtuellen Kanaelen
zwischen einzelne Folgepakete einer X.25 paketsequenz, was dann dazu
fuehrt, dass sich die Laufzeit des IP Paketes merklich erhoeht. ausserdem
wird dadurch die Varianz der Laufzeit richtungsabhaengig erhoeht, etwas,
was das TCP seeehr ungern hat (der Durchsatz sinkt).

Die Trennung zwischen innerdeutschen Verkehr und internationalen ist natuerlich
nicht einfach moeglich, weil es ja auf die MTU eines Interfaces ankommt,
und ueber das Interface kann ja sowohl amerikanischer als auch innerdeutscher
Verkehr fliessen, ausserdem geht ihre Argumentation davon aus, dass
der Verkehrstyp in die Staaten anders ist als der innerdeutsche, warum
glauben Sie dies ? Das mit dem Telnet ist eine unschoene Sache. Verbieten
hoert sich typisch deutsch an, das halte ich fuer ziemlich unsinnig.
Unsere Erfahrungen im BHN (seit 1 1/2 jahren machen wir IP ueber X.25
an den bayerischen Universitaeten, vor dem WiN ueber 64kbit Standleitungen)
sind die, dass auch interaktiver telnet mit einzelzeichenecho wunderbar
klappt, und die Leitungen keineswegs dicht macht, ein ftp stoert wesentlich
mehr, ausserdem muss man einmal sehen, dass es ohne Einzelzeichenecho
bei vielen Dingen garnicht geht, wie sollte man z.B.: vi auf einer remote
Maschine machen ??


Toerless Eckert