[wlanfhain] Re: IPv4-Infrastruktur / Adressallokation

[Bruno Randolf]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hallo andreas!

vielen dank fuer deine erklaerungen!

On Tuesday 06 July 2004 17:17, Andreas Kotes wrote:

> - z.B. 104.x.x.x/8 als basisnetz

ok. oder gleich IPv6

>   warum eine adresse mitten aus dem space? weil man, wenn der space zu
>   eng wird, einfach weiter aufmacht. 

ahhh! :)

> - routing erfolgt immer mit moeglichst grossen netzmasken
>   sprich: man macht eine grosszuegige aufteilung nach
>   logischen/geographischen gesichtspunkten, z.B. ost-berlin 104.x.x.0/9
>   und west-berlin 104.x.x.128/9, je naeher man dem entsprechenden
>   corepoint kommt, desto konkreter wird man. 

mesh routing protokolle wie OLSR machen in jedem fall eine host route, dh man 
kann diese einteilung erstmal nicht zu machen. dadurch werden natuerlich die 
routing tabellen ziemlich gross - aber ich konnte mit 1000 eintraegen im 
meshcube noch keine vergroesserung der latenz feststellen (sollte vielleicht 
mal wer anderer ev auch mit anderer hardware verifizieren).

wie gut das ganze mit extrem vielen routen (sagen wir mal 100.000) 
funktionieren wuerde ist natuerlich fraglich, dh eventuell sollten wir zur 
sicherheit trotzdem diese grobe geographische einteilung machen, damit wir 
bei bedarf das netz halbwegs sinnvoll fragmentieren koennen.

> fuer die routen nach draussen wuerde ich uebrigends empfehlen das man auf
> jeden fall metriken auf diesen setzt, d.h. man kann in der routingtabelle
> mit eintragen wie hoch die 'kosten' fuer die nutzung einer strecke sind,
> damit immer die 'billigste' genommen wird. da bei flatrates, dsl, etc keine
> kosten entstehen, sollte man die bandbreite darueber nach draussen
> announcen, z.B:
>
> - metric 32 - analog-modem
> - metric 30 - isdn-anschluss
> - metric 25 - adsl 768/128
> - metric 24 - adsl 768/256
> - metric 20 - adsl 1024/256
> - metric 19 - adsl 1024/512
> - metric 16 - adsl 1500/384
> - metric 15 - adsl 1500/768
> - metric 12 - sdsl 1024/1024
> - metric 10 - adsl 2048/1024
> - metric  8 - sdsl 2048/2048
> - metric  7 - sdsl 4096/4096
> - metric  6 - 10 mbit ethernet
> - metric  5 - 22mbit wlan
> - metric  4 - 54mbit wlan
> - metric  3 - 100 mbit ethernet
> - metric  2 - 1 gbit ethernet
> - metric  1 - noch fetter
> - metric  0 - so fett, dasses egal ist

sehr guter vorchlag!

> ... wollt ihr uebrigends NICHT von der MAC-adresse ableiten, sondern
> dynamisch/zufaellig generieren, wie von RFC 3041 vorgeschlagen.
> 
> In Absatz 2.3 dieses RFC wirds auch nochmal erklaert warum:
> 
> die MAC-adresse der karte ist unique, d.h. die privatsphaere des
> benutzers geht sofort phloeten, da er immer mit der selben (teil)adresse
> kommt, und somit spitzenmaessig zugeordnet werden kann, selbst wenn sich
> der (netz)prefix aendert.

ich kann diese privacy-bedenken grundsaetzlich schon verstehen, aber 
andererseits wuerde uns es das auch sehr schwierig machen, das netz zu 
debuggen oder mapping zu machen, denn im RFC 3041 steht auch:

   "Use of the extension causes
   nodes to generate global-scope addresses from interface identifiers
   that change over time" 

und bei meinem node am dach ist mir zb echt egal, ob der getracked werden kann 
oder nicht, denn er leitet im prinzip nur mehr pakete fuer andere (und mich) 
weiter v.a. bei IPv6, da gibt es ja keinen grund mehr NAT zu machen (ist echt 
schwierig sich wieder an den gendanken zu gewoehen, dass ganz normal geroutet 
wird, oder ;)). 

fuer individuelle notebooks/rechner/PDAs kann man ja adressen nach RFC 3041 
generieren, fuer infrastruktur-nodes halte ich das fuer kontraproduktiv, da 
wollen wir ja wahrscheinlich selbst mapping machen und v.a. in der 
anfangsphase brauchen wir statische adressen zum debuggen.

lg,
bruno
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA67Yffg2jtUL97G4RArJEAJ0XO7B1zmxkU0oMVfho2+ZLUc0DVQCfbcxd
18j3x1OiEgRD7I/MTDciz9o=
=YngX
-----END PGP SIGNATURE-----