[wlanfhain] Re: IP-Vergabe (war Re: Re: OpenWRT, OLSR und NAT

[Jens Nachtigall]

Hallo,

weiter unten ein paar Kommentare, wenn ich dazu komme, schreibe ich mal 
heute oder morgen eine Art BRFC (Berliner RFC;-) wie ich denke, dass 
die IP-Vergabe organisiert werden könnte. 

> Jens Nachtigall wrote:
> >>Ich verstehe die ganze aufregung nicht.
> >>egal welchen privaten adressraum wir nehemen, die ein oder anderen
> >>kollisionen wird es immer geben.
> >
> >Auch dafür gäbe es eine einfache Lösung. Wir nehmen im Berliner Netz
> > den Adressbereich: 96.x.x.x/3 (wie count das schonmal vorgeschlagen
> > hat), das ist ein von der IANA reserviertes, aber nicht genutzes
> > IP-Bereich (siehe auch
> > http://www.iana.org/assignments/ipv4-address-space).
>
> Welchen Adressbereich man nimmt, denke ich,  ist relativ egal, denn:
> >Private Addressräume (192.168.x.x usw.) haben dann im Berliner Netz
> >genauso wie im Internet nichts zu suchen. Das meist es einfach für
>
> das Konzept des privaten Adressraumes gilt erstmal nur für das
> Internet. Das Internet ist nicht mehr als ein IP Namensraum mit
> Routing. Bestimmte Teile des Namensraums sind da als "privat"
> vereinbart.
>
> Da wohl niemand für "unser" Netz IP Adressen reservieren wird, wird
> es auch nie Teil des Internets sein. Deshalb könnten wir verwenden
> was wir wollen. Wenn wir uns ins Internet NATen wollen, dann sollte
> es schon eines der nicht im Internet genutzen Netze sein, sonst hast
> du ein Problem, wenn du zufällig die IP von google.com hast.

Wenn du einen Uplink ins www hast, kriegst du vom ISP eine öffentl. IP., 
über die man dann natten kann. Das von dir skizzierte Problem existiert 
also nicht (wenn ich dich richtig verstehe).

> Der 
> Konventionen wegen bietet sich natürlich an, eines der 172, 192, 10,
> ... zu nehmen. Und wenn jemand sein Heimnetz nicht umkonfigurieren
> will, muß er halt NATen.

96.x.x.x ist zwar ein offiziell öffentliches Netz, aber diese 
IP-Adressen werden nicht verwendet (sind von der IANA noch nicht 
vergeben).




>
> >>Von einer  geografischen verteilung halte ich deshalb nichts weil
> >> da jemand drüber nachdenken muß, wie man das jezt am
> >> geschicktesten macht,
> >
> >Besser jetzt als wenn du in 2 Jahren eine Routing-Tabelle auf
> > Host-Basis hast. Sagen wir mal es wären 5000 Teilnehmer -- willst
> > du 5000 Einträge
>
> Eine Routingtabelle von 5000 Einträgen dürfte kaum als groß zu
> bezeichnen sein (5000 * ein paar Bytes). Was außerdem wichtiger ist,
> ist der routing cache, der
> Cache der tatsächlich benutzten Routen.
>
> Sagen wir mal es wären wirklich 5000 Teilnehmer. Es gibt da zwei
> interessante Szenarien:
>
> 1. Jeder geht über den nächsten gateway ins Internet
> Der routing cache wäre ziemlich klein, er enthielte nur die Einträge
> für nodes, die der gateway versorgt.

Ich mach mir eher Gedanke über die Berechnung dieser 5000 Einträge.


>
> 2. Jeder kommuniziert mit jedem (wäre schön, aber unwahrscheinlich,
> weil doch alle hauptsächlich "ins Internet" wollen)

Das mag für Otto Normal-DSL stimmen, die meisten der Berliner 
Wavelan-Begeisternten wollen aber ein eigenes Netz mit eigenen Inhalten 
aufbauen.

> In diesem Fall hättest du dann wirklich einen routing cache mit
> vielen Einträgen. Gefühlsmäßig hat da ein 100MHz RISC kein Problem
> mit, aber ich lasse mich da auch gerne eines besseren belehren. Bei
> 5000 Teilnehmern habe ich da aber eher Bedenken ob OLSR soweit
> skaliert, und ob wg. der vielen Hops zwischen den Nodes die Latenz
> und packet loss nicht zu groß wird. Für OLSR habe ich ein Paper
> gefunden, in dem ein statisches Szenario mit 100 Nodes noch relativ
> wenig control traffic hat [1]. Kennt jemand ein Paper in dem größere
> Netze mit simuliert wurden?
>
> Ein hierarchischer Aufbau des Netzes (IP Verteilung nach
> Netzwerktopologie, nicht geographisch) würde den routing table lookup
> schon beschleunigen. Die Frage ist nur, ob OLSR diese Hierarchie
> entdecken würde und entsprechende network routes anlegt...

Das kann OLSR nicht von selbst, deshalb gab es ja die Überlegung BGP zu 
nehmen, und OLSR nur in Autonomen Systemen (= die Kieze) zu verwenden. 
Die Brücke zw. diesen OLSR-Kiezen würde BGP schlagen.


Jens

-- Attached file included as plaintext by Ecartis --

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBBZQuyAzJOgw63+4oRAmhyAJ9bulI/CXbDhCH4MvXiOD8vFkwIBACcDl4h
bKOJ4D68hnmevFUpwiDwJL4=
=gCUB
-----END PGP SIGNATURE-----