Disclaimer:
Ok, Vorsicht, ich gebe hier zum Teil Ansichten der IETFler wieder :-)
Am Mon, 2003-08-11 um 11.24 schrieb Peter Bieringer:
> --On Monday, August 11, 2003 11:11:49 AM +0200 Gert Doering
> <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > On Mon, Aug 11, 2003 at 11:08:27AM +0200, Ignatios Souvatzis wrote:
> >> Es werden zur Zeit Modelle entwickelt, ungeroutete eindeutige Adressen zu
> >> billig/kostenlos zu vergeben, die anstelle der site-locals treten sollen.
>
> Mu� mir wohl mal den Thread zu gem�te f�hren...das einzige, was ich
Tus nicht :)
Der ging ueber Monate und drehte sich etliche Male im Kreis.
Grundsaetzlich ging es wohl darum, das Site-Local-Adressen nicht
eindeutig sind. In den frueheren RFCs waren _alle_ site-locals
fec0::/48, und selbst mit fec0::/10 _koennten_ Probleme auftauchen.
ZB. wenn man zwei Sites zusammenfuehren will, oder wenn man sich zB mit
seinem Heim-SL-Netz ueber VPN in das Firmen-SL-Netz einwaehlt. Es gab da
diverse kaputte Szenarien.
Zusaetzliches Problem war wohl, das heutige Stacks sich keinen Deut um
den Scope einer Adresse scheren. Man kann halt mir einer
SL-Source-Adresse nicht global reden und es gab keine definierten
Regeln, was wann als Source-Adresse benutzt werden soll/darf.
Ich will das echt nicht alles aufrollen, IPng hat mir gereicht :)
> irgendwie mitbekommen habe, da� site-local halt kein organizational-local
> ist (obwohl ein Netzplaner das ja locker durchorganisieren k�nnte). Bei
> sp�terer einsetzender Fusionitis (hilft eh nur autorenumbering) oder das
> gleiche Chaos wie bei IPv4 tritt ein...und IPv6-NAT wird von der
> "Industrie" gefordert...
Genau dieses Autorenumbering soll ja verhindert werden. Warum soll man
die Kruecken der uneindeutigen Addressierung aus IPv4 mitschleppen. Fuer
eine Site moechte man halt zumindest eine stabile interne Addressierung.
IPv6 ist ja schliesslich so schoen mehrfach addressierbar, warum also
nicht eine interne Addressierung, die sich nicht aendert, wenn man den
Provider wechselt. Waer ja doof, wenn das Intranet mitgestoert werden
wuerde nur weil man gerade fuer eine gewisse Uebergangszeit keinen
Provider hat.
>
> > Bin ja gespannt, wie lange sich das mit dem "ungeroutet" durchalten
> > laesst.
> >
> > PI-Netze vergeben und dann erwarten, dass sie nicht geroutet werden - argl
> > (aber die IETF ist bei den Adressierungsfragen eh' "etwas" weltfremd).
>
> Danke f�r die Info...und gegen das Routing helfen ja einfache Filter auf
> dem IPv6-Backbone...sowie IPv4 RFC1918 Source-Adress-Filter ja auch
> eigentlich �berall an den Edges �berall sein sollten (jaja, ich wei�, ich
> tr�ume, denn wenn ich mir so meine FW-Logs anschaue, scheint es das nicht
> �berall zu geben...).
Filter sind hier nicht das Problem.
Wenn erst mal abgesegnete, eindeutige und Provider-unabhaengige Adressen
offiziell an Kunden von den RIRs verteilt werden, wer sollte die
Provider daran hindern, diese auch zu routen? Ist doch viel einfacher
und praktischer als all die komplexen Renumbering-Notwendigkeiten, die
ihnen von den design-fanatischen Theoretikern vorgesetzt wurden.
"Keep it simple" wird sich da durchsetzen, und genau dieses sollte man
im Keim ersticken. Oder kommt dein kleiner 26xx mit ein paar Millionen
BGP-Routen (und vor allem -Updates!) zurecht? :-)
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
