On Wed, 9 Jul 2003 17:58:08 +0200
Andre Grueneberg <[EMAIL PROTECTED]> wrote:
> Hi Patrick,
>
> Patrick Koppen wrote:
> > Autoconfiguration:
> > Jedem IPv4 Netz wird ein IPv6 Prefix zugwiesen:
> > KL.89.0/24 -> KL6:59::/64
> > Die 89 wurde einfach als Hexdezimalzahl im SLA Teil geschrieben.
> >
> > Alternativ:
> > KL.89.0/24 -> KL6:89::/64
> > KL.137.0/24 -> KL6:137::/64
> > Bei der ersten Loesung ist nicht so viel Verschnitt, aber die
> > zweite ist fuer den Menschen wesendlich einfacher zu lesen.
>
> Da Menschen sowieso nicht gerne mit numerischen IPv6-Adressen in Kontakt
> kommen m�chten, ist das v�llig egal. Ich wei� ja nicht, wie stark euer
> Netz so strukturiert ist, aber die Regel ist doch eher, dass man
> Hierarchien oder Standorte hat, die man gerne auch in der Adressierung
> umsetzen wollen w�rde.
> Ich w�rde nicht so flach arbeiten.
Hmjaa, Hierarchiesierung macht aber nur wirklich Sinn, wenn man ein
Backbone hat, das auch entsprechend aussieht. Also zum Beispiel ein MAN.
Aber welche Uni hat das schon. Selbst wir, die Uni-Muenster, die sich ueber
das ganze Stadtgebiet verteilt, braucht keine Hierarchien.
Hinzu kommt, das sich Backbonestrukturen alle paar Jahre grundlegend aendert
(FDDI -> ATM -> GE), und wenn man da einmal eine Addressierungshierarchie
draufgepropft hat, die man uU nicht so schnell loswird, dann kann man in der
naechsten Ausbaustufe durchaus unangenehm gebunden sein.
Natuerlich spricht nichts dagegen, Subnetze syntaktisch zusammenzufassen und
zu verteilen (Gebauede A-Z, Stadtteil 1-9, Institut Bla-Blubb), aber das
bedeutet ja nicht, das man dass auch aggregieren muss. Flaches Routing ist
meiner Ansicht nach durch aus erlaubt und ich glaube nicht, das man da in
Skalierungsprobleme laufen kann (wer hat schon soviele Subnetze...).
[..]
>
> > Weiterer Nachteil ist, dass jeder Benutzer direkt eine weltweit
> > routebare Adresse bekommt, die Konzeptbedingt bei uns im Netz
> > sofort funktioniert. So kann dann jeder halt sagen: 'aber es
> > ging doch, und wieso soll ich mich erst beim Rechenzentrum
> > registrieren'. Die koennte auch beim Accounting Probleme machen.
>
> Warum? Vorher muss er sich doch auch registrieren, damit der Traffic
> durch durfte?! Oder hat man sich da nur f�r den Bezug der Adresse
> registriert und konnte auch vorher schon einfach mal ne beliebige
> (freie) Adresse benutzen und "es ging"? Dann ist euer Accounting sowieso
> kaputt und ihr wollt es fixen. :)
>
> Ich w�rde einfach empfehlen MAC-Adressen als Accounting-Grundlage zu
> benutzen. Dann muss sich $BENUTZER eben registrieren und erst dann wird
> auf Switch/Router f�r $MACADRESSE aufgemacht.
Was ich dann auch unbedingt empfehlen wuerde. MAC-Adressen sind zwar auch
faelschbar, aber dann doch nicht ganz so trivial, wie IPv6-Adressen.
> Ja, das ist mehr Filtering, aber sowieso sinnvoll. Damit ist euer
> Accounting (dank �nderbarer MAC-Adressen) zwar auch nicht sicher, aber
> zumindest sinnf�lliger und problemfreier.
>
> [Alle anderen L�sungen]
> Kr�cken. Tunnel will man nicht, wenn man's nativ haben kann und DHCPv6
> ist eigentlich auch nicht darauf ausgelegt Adressen zu verteilen --
> daf�r hat man ja schon stateless auto configuration.
Hm, was genau meinst du? DHCPv6 soll eigentlich genau das tun, Adressen an
Clients zu verteilen (state_ful_ address configuration).
Gruss,
Christian
--
JOIN - IP Version 6 in the WiN Christian Schild
A DFN project Westfaelische Wilhelms-Universitaet Muenster
http://www.join.uni-muenster.de Zentrum fuer Informationsverarbeitung
Team: [EMAIL PROTECTED] Roentgenstrasse 9-13
Priv: [EMAIL PROTECTED] D-48149 Muenster / Germany
GPG-/PGP-Key-ID: 6EBFA081 Fon: +49 251 83 31638, fax: +49 251 83 31653
_______________________________________________
ipv6 mailing list
[EMAIL PROTECTED]
http://listserv.uni-muenster.de/mailman/listinfo/ipv6
