[wlanfhain] Re: IPv4-Infrastruktur / Adressallokation - terminkonflikt

[Andreas Kotes]

Heya,

* Bruno Randolf <br1 at subnet.at> [20040707 10:43]:
> hallo andreas!

count, bitte :)

sowohl im c-base als auch im (ccc-)clubumfeld ist mit 'andreas' in quasi
allen faellen eine andere person gemeint ...

> vielen dank fuer deine erklaerungen!

gern :)

> On Tuesday 06 July 2004 17:17, Andreas Kotes wrote:
> > - z.B. 104.x.x.x/8 als basisnetz
> ok. oder gleich IPv6

fuer intern - klar. fuer extern (oder veraltete clients) wird das leider
nicht reichen.

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

... meine rede. klingt ansonsten danach als wuerde man fuers
infrastruktur-netz dann definitiv OSPF (oder IS-IS) nehmen wollen.

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

der _interface identifier_ aendert sich, man kann allerdings dem
interface auch (absichtlich) eine 'richtige' IPv6-adresse geben, welche
nicht aus der MAC-adresse generiert wurde - sollte man sowieso machen!

auch und gerade im infrastruktur-bereich, was wuerdet ihr denn z.B.
machen wenn eine netzwerkkarte abraucht und ausgetauscht werden muss? ..
schwupps, schon hat man ne neue MAC, und guckt auf einmal sehr komisch
..

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

diese statischen adressen solltet ihr selbst festlegen, und euch nicht
von den MACs ableiten :)

Viele Gruesse,

   Count

P.S: ich werds heute vermutlich (doch) nicht schaffen, sorry :( zum
treffen am letzten mittwoch des monats werd ich allerdings sicherstellen
das ich da bin - ich hoffe, das hilft euch.

-- 
Andreas Kotes - ICQ: 3741366 - The views expressed herein are (only) mine!
Follow the path of the unsafe, independent thinker. Expose your ideas to the
danger of controversy. Speak your mind and fear less the label of "crackpot"
than the stigma of conformity. (Thomas J. Watson) ### OpenPGP key 0x8F94C228