[wlanfhain] Re: IP-Vergabe (war Re: Re: OpenWRT, OLSR und NAT
Juergen Neumann
j.neumann
Mi Okt 6 12:39:13 CEST 2004
-----BEGIN PGP SIGNED MESSAGE-----
Ahoi!
Mein Kommentar am Ende der Mail:
> > 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)
Drei Punke finde ich hier entscheidend:
1. Lieber keine privaten Adressen im Netz verwenden - das hilft uns
ungemein Adress-Konfliktez vermeiden! (also das 96.x.x.x/3 Netz)
2. Ein Routing nach Regionen, um die Routingtabellen nicht überlaufen zu
lasse, erscheint mir sinnvoll.
3. Wenn wir das 104er Netz dafür verwenden wollen, dann ließe sich evtl.
gleich eine Analogie zur PLZ in Berlin herstellen.
LG
JuergeN
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8
iQEVAwUBQWO9Qt3z6c5eZCFlAQHS8wf+NjLRlT9npxn+UB04wrHYIuxKUpMyluH2
+M7d8uAiIJ0SfBFT/piasOZKgUN2SIYH7h3zJ0uZX3EkRfALHvDK2Aw5gA4Gvx6V
ZtFvu78ygy9bj32Q9wJhQzLel76gK4uRj3NZdvspjSWzwfwQYEnPvIRDzfztTeRx
c0fHKJAxzvrtTUIzcv6eZjspPIkKywdMInQxlcOQXnVVcJtM50mFP+ttryaRoBAG
gSvc/mzEcWJS7lTwt71VAIN0S0nseWdd5h/VOKEbvG4uZZVU2AHD6unIUPr1UZEC
2YRfAJxy1/JqQ30txlhE+PACdbnopi1P4N0aNlLjDeygoSF5jIfEzg==
=m8Lj
-----END PGP SIGNATURE-----
---
[scanned]
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.772 / Virus Database: 519 - Release Date: 01.10.2004
Mehr Informationen über die Mailingliste Berlin