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

[Jens Nachtigall]

Hallo,

> 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).

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 
Admins -- entweder sie natten fürs BerlinNetz (wie im Internet) oder 
wenn sie keinen NAT sondern im Berliner Netz echte IPs wollen, dann 
stellen sie auf 96.x.x.x/3 um. Einfache Regelung, kein Ausversehen das 
gleiche private Netz ins BerlinerNetz announcen etc. Da diese Policy 
vom Internet bekannt ist

> 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 
in deiner Routing-Tabelle bzw. will das ein WRT54G (von der Berechnung 
dieser Routingtabelle zu schweigen)? Und dann alles umstellen?

> und außerdem stellt sich dann in der regel raus, daß man dann 
> doch irgendwo zuviel oder zu wenig hat.

Auch dazu möchte ich auf counts Vorschlag zurückgreifen:
im zitat einfach cp1 durch so36, cp2 durch Mitte etc. ersetzen:
<zitat count>
corepoints [Anm.: oder kieze] kriegen jeder ein 104.x.x.x/22, mit 
abstand dazwischen

  beispiel:
[Anm.: 104.x.x.x liegt in 96.x.x.x/3]
  cp1: 104.0. 0.x/22 - 104.0. 0.x  - 1024 adressen
  cp2: 104.0.32.x/22 - 104.0.34.x  - 1024 adressen
  cp3: 104.0.64.x/22 - 104.0.67.x  - 1024 adressen
  cpM: 104.0.96.x/22 - 104.0.99.x  - 1024 adressen

  ... wenn jetzt der adressraum von z.B. cp2 und cp3 nicht mehr
  ausreicht, macht man weiter auf:

  cp1: 104.0. 0.x/22 - 104.0. 0.x  - 1024 adressen
  cp2: 104.0.32.x/21 - 104.0.39.x  - 2048 adressen
  cp3: 104.0.64.x/21 - 104.0.71.x  - 2048 adressen
  cpM: 104.0.96.x/22 - 104.0.99.x  - 1024 adressen

  ... reicht immernochnicht? ok, noch weiter aufmachen:

  cp1: 104.0. 0.x/22 - 104.0. 0.x  - 1024 adressen
  cp2: 104.0.32.x/20 - 104.0.47.x  - 4096 adressen
  cp3: 104.0.64.x/20 - 104.0.79.x  - 4096 adressen
  cpM: 104.0.96.x/22 - 104.0.99.x  - 1024 adressen

  ... cp2 braucht noch mehr?? ok:

  cp1: 104.0. 0.x/22 - 104.0. 0.x  - 1024 adressen
  cp2: 104.0.32.x/19 - 104.0.63.x  - 8192 adressen
  cp3: 104.0.64.x/20 - 104.0.79.x  - 4096 adressen
  cpM: 104.0.96.x/22 - 104.0.99.x  - 1024 adressen

  .. fuer cp2 ist jetzt das ende der fahnenstange erreicht, allerdings
  konnte es dreimal problemlos verdoppelt werden! soweit, so gut. nehmen
  wir mal an, es kommt noch ein cpN dazu, und wir sind uns sicher das
  cp3 und cpM in absehbarer zeit nicht wachen werden:

  cp1: 104.0. 0.x/22 - 104.0. 0.x  - 1024 adressen
  cp2: 104.0.32.x/19 - 104.0.63.x  - 8192 adressen
  cp3: 104.0.64.x/20 - 104.0.79.x  - 4096 adressen
  cpN: 104.0.80.x/22 - 104.0.83.x  - 1024 adressen oder
  cpN: 104.0.84.x/22 - 104.0.87.x  - 1024 adressen oder
  cpN: 104.0.88.x/22 - 104.0.91.x  - 1024 adressen oder
  cpN: 104.0.92.x/22 - 104.0.95.x  - 1024 adressen oder
  cpN: 104.0.80.x/22 - 104.0.87.x  - 2048 adressen oder
  cpN: 104.0.88.x/22 - 104.0.95.x  - 2048 adressen oder
  cpN: 104.0.80.x/22 - 104.0.95.x  - 4096 adressen
  cpM: 104.0.96.x/22 - 104.0.99.x  - 1024 adressen
</zitat> 


> Davon stationären knoten hinter olsr Knoten IPs aus dem 172.16.0.0/12
> weil wir dieses netz in der jezigen config komplett für olsr
> vorgesehen haben - außerdem wäre es schön an der IP zu sehen ob sich
> der knoten bewegen kann oder nicht.

Aber die meisten olsr-Stationen stehen doch auf dem Dach und sind nicht 
stationär.


>
> Mein Technischer anspruch an die IP vergabe war, das ich einfach nur
> in der Datenbank nachsehe welche olsr ip noch frei ist, und wo ich
> noch ein freies subnet habe und beides dann rausschicke, ohne daß ich
> nachdenken muß wo dieser Knoten sich befindet.

Die geographische Vergabe schließt Einfachheit nicht aus. Die IANA macht 
es nicht anders, da hast du auch nicht 80.185.221.249 in Europa und 
80.185.221.250 ist dann in Afrika. Die Datenbank finde ich eine gute 
Idee, dennoch wird sie es nicht ersetzen können, dass wir uns 
absprechen. Erst alle Kieze zusammen, wer welchen Adressraum kriegt. 
Und dann die Kieze selbst wie ihr Adressraum weiterverteilt wird. Da 
kann die Datenbank dann später hilfreich sein -- einfach ein 
zusätzliches Feld im Webinterface: »In welchem Kiez wohnst du« und 
dazugehöriges Optionen (so36, fhain etc.) 

>
> Das muß kein 192.168.x.x netz sein, das kann auch ein 10.er Netz sein
> - oder sonst etwas privates, von mir aus auch ein 42.er wie in der
> c-base.
>
> Und eben weil es - egal wie wir es machen - wenn das netz wächst
> einen Ziemlichen aufwand bedeuten wird es zu organisieren - würde ich
> das gerne so einfach wie möglich halten.

Genau deshalb würde ich es wollen, dass wir es die IPs geographisch 
vergeben, sobalb wir 1000 Einträge in der Routingtabelle haben (falls 
das bei einem WRT54G überhaupt geht), müssen wir soweiso damit anfangen 
und dann wird es so meine Prognose nicht mehr gehen (überzeuge mal 1000 
Leute)


Na das wird ja ein spannender 27.10. ;-)

Viele Grüße,
Jens