Christian Schild wrote: > > 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.
Na gut. Ich ging von unserer Situation aus: * 5 Standorte * auch IPv4-Bereiche sind i.d.R. aggregiert -- nur weil nicht genug Platz zwischendrin war, haben wir das etwas aufgel�st. Da bietet sich das einfach an, erstmal so Sachen wie 2001:638:801:100::/56 pro Standort vorzusehen. > 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. Was hat denn das Backbone mit den Adressen der angeschlossenen Netze zu tun? Im Backbone wird eh mit Transfer-Netzen aus einem unabh�ngigen Bereich bearbeitet. > 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...). Nat�rlich ist es erlaubt. Nur die Adressverteilung ist mit IPv6 wesentlich leichter an die vorhandenen physischen/logischen Strukturen m�glich. Und zumindest ich find's angenehm, die vorhandenen M�glichkeiten zu nutzen. > > 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. Letztlich ist beides trivial. Man m�chte eigentlich Absicherung der ND etc. -- nur das ist ja ein bekanntes ungel�stes Problem. > > [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). Ja, es ist daf�r vorgesehen. Aber erinnere ich mich falsch oder waren bisherige DHCPv6-Implementation insbesondere dazu da, um weitere Parameter (�ber die Adresse hinausgehend) zu setzen? Andre -- In the long run, we are all dead.
pgp00000.pgp
Description: PGP signature
