On Wed, 9 Jul 2003 17:31:13 +0200
Patrick Koppen <[EMAIL PROTECTED]> wrote:
> Hallo,
>
> ich bin neu auf dieser Liste und habe gleich mal ein paar Fragen:)
>
> Zur Zeit wollen wir das Netz der Uni-Kaiserslautern um IPv6 erweitern
> und diskutieren gerade ueber das grundlegende Adresskonzept. Ich habe
> schon im Archiv dieser Liste nachgeschaut, aber nichts passendes gefunden.
>
> Hier mal die ersten Diskussionsergebnisse, leider ist da noch nichts
> wirklich brauchbares bei. Auf diesem Wegen will ich auch gleich
> mal fragen, wie das andere Unis machen.
>
> Randbedingungen Uni-KL
> - Class-B Netz
> - (so gut wie) keine privaten Subnetze
> - offenes Netz, d.h. auf ein notwendiges Mass beschraenkte Accesslisten.
> Jeder Rechner (ausser Verwaltung) hat freien Zugang zum Netz.
> Lediglich kritische Protokolle wie snmp usw. sind gesperrt.
> - 1300 angeschlossene Wohnungen in Wohnheimen
> - Adressbasiertes Accounting, deswegen feste Bindung von
> Adresse zu DNS-Name
Hm, wie genau macht ihr das? Bzw. wie verhindert ihr, dass sich jemand eine
beliebige IP sucht? Genau das ist naemlich bei IPv6 deutlich leichter
(zb trivialst mit rfc3041).
> - Jeder Raum (auch Seminarraeume und Hoersaele) hat eine Ethernetdose.
> - nur /24-Bit IPv4 Netze
> - so gut wie kein DHCP und wenn dann nur mit statischem Mapping
> MAC<->IP<->DNS (siehe Accounting)
> - kein Adressmangel
> - es wird keine Adresse ohne DNS-Eintrag im Netz geduldet
s.o., filtert ihr das? "Klappert" ihr alle DNS-Eintraege ab und lasst nur die
zu?
> Moeglichkeiten zur IPv6 Adressvergabe
>
> KL=131.246 (/16)
> KL6=2001:638:208 (/48)
>
> 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.
Das kann man beides so machen ja. Ich sehe bisher nicht unbedingt die
Notwendigkeit die alte IPv4 in der IPv6-Adresse zu integrieren, aber machbar
ist es schon. Bei diesem Verfahren wuerdet ihr nur ein /54 eures Adressraumes
verwenden und haettet genug Platz fuer anderes oder spaetere
Umstrukturierungen. Man sollte halt im Kopf behalten, dass man irgendwann auch
mal ohne IPv4 arbeiten wird.
> Das Hauptproblem bei Autokonfiguration ist fuer uns jedoch der
> zur Zeit implementierte Algorithmus zur Berechnung des Hostanteils,
> der aus Datenschutzgruenden vollkommen indiskutabel ist. Jeder
> Webseitenbetreiber der Welt, auf dessen Seiten man regelmaessig
> zugreift (z.B. Betriebssystemhersteller), kann wunderbar Notebooks
> auf ihrem Weg trotz verschiedener Prefixe verfolgen. Hier
> muesste man sich noch mal das Draft fuer Randomadressen anschauen.
Ist das wirklich indiskutabel? Ich bin da vielleicht nicht paranoid genug,
aber das einzige was mich daran stoeren wuerde ist, dass man sieht, was fuer
eine Netzwerkarte(Hersteller) benutzt wird. Im Grunde genommen ist es voellig
egal, ob eine bla::1, bla::2, oder bla:EUI-64 Adresse verwendet wird. Der
Einwand, dass man nomadisierende Systeme nachverfolgen kann ist, ist
allerdings richtig, aber die kann man ja ggf. anders konfigurieren oder werden
u.U. sowieso bei der Wanderung anders addressiert. Zur Not gibts noch
erzwungenes 3Wege-Mobile-IP.
Euer Problem hier duerfte ansonsten sein, dass sich Privacy Adressen und
IP-based Accounting gegenseitig ausschliessen. Privacy Adressen haben ein
Problem mit dem Nameservice, man braucht DDNS, und das will man noch viel
weniger haben, als sichtbare MAC-Adressen. DDNS duerfte auch voll mit eurem
Accounting kollidieren bzw. macht es hoechst unsicher.
>
> 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.
Oh, wieso, man kann sich durchaus Adressstrukturen ueberlegen, bei denen
bestimmte Teile gar nicht nach draussen oder sogar intern nur eingeschraenkt
geroutet werden. Wir denken bei uns gerade ueber sowas nach.
> ISATAP (vielen Dank fuer die HOWTO!!!)
> KL.89.19/24 -> KL6:59::5EFE:131.246.89.19/64
>
> Vorteil: Unterstuetzung durch Router, einfaches Mapping (IP und DNS),
> Migrationshilfe
>
> Nachteil: Manuelle Konfiguration, DHCPv6 oder Tunnel notwendig???,
> Ausgabe bei den meisten Geraeten nur im Hexformat, Eingabe
> bei vielen Geraeten nur im Hexformat.
Ich denke ISATAP hilft euch bei der Adressierung nicht viel weiter. Warum sich
wieder Tunnel einfangen, wenn man doch eigentlich Dualstack machen will.
ISATAP ist ein wundervoller Mechanismus, wenn man es mal nicht schafft, IPv6
in ein 'veraltetes' Subnetz zu bringen, aber als Mittel der Adressierung
denkbar ungeeignet.
> Eigener, fester Hostanteil /64
>
> KL.89.19/24 -> KL6:89::19/64 (dezimal..dezimal)
> KL.89.19/24 -> KL6:59::19/64 (hex ..dezimal)
> KL.89.19/24 -> KL6:59::13/64 (hex ..hex)
>
> Vorteil: 64 Bit Hostanteil ist kompatibel zu anderen IPv6 Adressierungs-
> konzepten, einfaches Mapping fuer Mensch und Maschine.
>
> Nachteil: Verschnitt, manuelle Konfiguration oder DHCPv6,
> werden Kaffemaschinen und Toaster mehr als IPv6 Autoaddressing
> koennen???
Auch das kann man so machen. IPv4 Adressen in die Interface-ID zu kodieren ist
durchaus diskutabel. Ist aber nur eine Erweiterung zu obigem ersten Ansatz.
Ich glaube ihr braucht fuer sauberes Accounting und die gewuenschte Privacy
dann sowieso DHCPv6.
> Vollkommen freie Prefixlaenge
>
> KL.89.19/24 -> KL6::89:19/112
>
> Vorteil: Nur SLA=0000 benutzt, dadurch wenig Verschnitt, einfach
> zu Lesen und zu Konfigurieren, mapping IPv4<->IPv6
>
> Nachteil: Macht das irgendjemand in der Welt so? Manuelle
> Konfiguration oder DHCPv6 notwendig. Was ist, wenn
> wir doch mal automatische Konfiguration brauchen?
Diese Loesung ist boese und verboten. Die /64 ist die einzige harte Grenze
die in RFC3513 geblieben ist, und die darf man nicht verletzen. Routing in
den ersten 64 Bit, Addressierung in den zweiten /64 Bit.
Natuerlich darf man die IPv4 Adresse so einkodieren, Routen darf man aber nur
bis 64, also zB KL6:xxxx::89:19/64.
> Ich persoenlich tendiere momentan zur Loesung mit 112 Bit Prefixlaenge.
> Hier kann man ein fuer den Menschen einfach lesbare Adressen verwenden.
> Da die '89' im oben genannten Beispiel einmal dezimal und einmal
> hexadezimal benutzt wird, faellt wohl einfach keinem auf.
> Wenn man doch mal das /64 Konzept braucht, hat man dann zur Migration
> noch alle SLA-Adressen ausser der 0000 uebrig. Man verbaut sich
> so zumindestens nicht sofort was. Zudem wuerde unser DNS und Accounting-
> konzept noch funktionieren. Man muesste sich das Routing natuerlich
> noch mal anschauen, aber das ist bei uns gluecklicher Weise sehr einfach.
Generell tendiere ich dazu, die SLA eher dazu zu benutzen, echte
Netzwerkstrukturen abzubilden, also zB falls vorhanden Hierarchien (wobei ich
hier vorsichtig waere, da diese sich durchaus alle paar Jahre mal aendern),
oder um Sicherheitsstufen einzubauen. Man kann zB durch kuenstliche
Hierarchiestufen bestimmtes Routing und damit bestimmte Filterung erzwingen.
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
