Kommentare siehe Inline.
Rechnet Ihr kein Volumen ab? (Ist nat�rlich kein Problem, ist nur eine generelle Frage.)Adressverwaltung bedeutet: - Festlegen eines neuen Adressbereichs fuer ein Geraet/Netz/Kunden - Festlegen des Default Gateways in diesem Adressbereich - Eintrag im Routing - Zuordnen des Adressbereichs zu einem Kunden - Eintrag Forward/Reverse Mapping im DNS - Loeschen einer Adresse eines Geraets - Loeschen des Routings - Loeschen der Zuordnung zum Kunden
[Cryptografisch sichere Adressen]
Aus Deinen Schilderungen kann ich im Moment nicht ganz ersehen, was das exakte Problem ist, das Du umschiffen willst. Wenn Du nicht m�chtest, dass der EUI-64-Teil die konvertierte MAC enth�lt, musst Du halt die Privacy-Extension verwenden (etwas ung�nstig f�r Reverse DNS) oder direkt DHCPv6.Sind CGA (crypto-generated adresses) sicher ? http://www.ietf.org/internet-drafts/draft-ietf-send-cga-01.txt A: Nur die naechsten 20 Jahre, weil nur 64bit zur Verfuegung stehen. Hmm.
Halte ich f�r problematisch, weil Du einen hohen Arbeitsaufwand erzeugst. Dann kannst du Renumbering eigentlich sofort vergessen. In meinen Augen gibt es eigentlich nur drei sinnvolle M�glichkeiten, wie Adressen verteilt werden:Daher: Vorschlag zur Policy: Also werden auch unter v6 Adressen im Normalfall statisch vergeben.
(1) RA <- ist sicher a priori die einfachste M�glichkeit, weil sie ein Minimum an Konfigurationsarbeiten erfordert. Dann ist allerdings zu bedenken, dass die RAs vom Router des Kunden gemacht werden. In wieweit Ihr da Einfluss drauf habt, wei� ich nicht, aber das sollte man auf jeden Fall bedenken. Hier hast Du auch nur mit der Privacy Extension die M�glichkeit, die EUI-64-Adresse aus der IP zu nehmen. �ber den Sinn, das zu tun, kann man sich streiten.
(2) Stateful DHCPv6 <- Krankt an dem Problem, dass es nicht so viele Implementierungen gibt, aber einige sind schon greifbar (sogar freie Implementierungen). Ist im Grunde aber eine sehr charmante L�sung, um Adressen zu verteilen, insbes., wenn Du ein m�glichst zentral verwaltetes Mapping IPv6-Adresse<->zugeh. Host haben willst und gleichzeitig R�ckschl�sse auf den Host per konvertierter MAC verhindern willst.
(3) Stateless DHCPv6 mit Pr�fix-Delegierung <- Ein nette M�glichkeit besonders f�r Einwahlkunden: der Einwahlrouter ist DHCPv6-Client und fragt den ISP-DHCPv6-Server nach einem Pr�fix, den er im Kundennetz per RA announcen soll.
Statische IP-Vergabe w�rde ich schnell vergessen.
Die Begr�ndung ist fadenscheinig. "Security through obscurity" ist in meinen Augen ein absolut naiver Ansatz. Ich glaube, dass Angreifer in der IPv6-Welt sich sehr bald schon vom simplen Scannen von Subnetzen verabschieden werden. Es wird sicher bald andere Tricks geben, und dann wird es v�llig egal sein, wie die IPs vergeben sind. Entweder, man sch�tzt die Rechner aktiv, oder man l�sst es. Aber die Hosts zu "verschleiern" ist eine tr�gerische Sicherheit, wo der Schuss 100%ig r�ckw�rts los gehen wird. F�r kurze Zeit mag es Angriffe mit vorhergehenden Scans ein wenig erschweren, aber schon bald spielt das sicher keine Rolle mehr.Naechste Frage: Wenn statisch vergeben, wie wird bei einer Vergabe der naechste Adressbereich ausgewaehlt ? Zwei Alternativen stehen zur Wahl:
1) Linear, d.h. aus dem jeweiligen Adressblock wird der naechste freie gewaehlt.
2) Zufaellig, d.h. aus dem jeweiligen Adressblock wird zufaellig ein freier ausgewaehlt.
Vorteil von 1) Einfach nachzuvollziehen.
Nachteil von 1) Das macht es Angreifern leicht, nach aktiven Geraeten zu scannen.
Nachteil von 2) Schwierig in der Handhabung.Deswegen w�rde ich statisch keine IPs vergeben.
Das ist dann f�r gr��ere Kunden, die quasi eigene Sites haben, richtig? Das w�rde hinkommen.- Vorschlag zur Adressverteilung: o Ethernetze bekommen zufaellig ausgewaehlte /48 aus dem /32-Fenster
o Kunden hinter Leitungen/Dialups bekommen ein zufaellig
ausgewaehltes /48
Hui! Das ist aber gro�z�gig. Was spricht gegen einen l�ngeren Pr�fix
wie /64? Bei Dial-up denken ich an DSL-/Modem-/ISDN-Kunden. Oder
verstehst Du da etwas anderes drunter?o phys-server bekommen ein zufaellig ausgewaehltes /128 im entsprechendenGut, das Problem hast Du dann aber z.B. mit DHCPv6 nicht. Abgesehen davon hindert Dich niemand daran, die Privacy-Extension zu verwenden. Das ist nat�rlich f�r Reverse DNS komplizierter, aber Du musst abw�gen: einfacheres Management oder Verschleierung der MAC.
ethernet und wenn weitere Adressen notwendig werden, ein zufaellig
ausgewaehltes /64 aus einem dafuer reservierten und zufaellig
ausgesuchten /48.
Warum nicht die letzten /64 aus der ethernet-Adresse ? A:
Security, keine Infos ueber den Adaptertyp/Geraete verteilen.
o Point-to-point Links ? siehe rfc3627
* /128, sehr sparsam, aber vermutlich schwieriger aufzusetzen
* /126, sparsam, tut technisch (analog einem /30)
* /112, das ist eine 16-bit boundary, daher einfacher zu merken
Meine Praeferenz: /126
Wir benutzen hier f�r P-t-P-Links grunds�tzlich /112, was sich sehr gut
bew�hrt hat. Kann ich nur weiter empfehlen. /128 bringt absolut gar
nix, denn bei /128 bekommst Du keine implizite Route, mit der Du z.B.
den P-t-P-Link per ping auf die Gegenseite testen kannst, ohne am
Routing (z.B. auf ISP- und Kunden-Router) fummeln zu m�ssen. o Default-Gateway ist jeweils eine zufaellig ausgewaehlte IPs im
entsprechend zugeteilten Netz.
bei einem /48: 2001:14b0:xxxx:YYYY:ZZZZ:ZZZZ:ZZZZ:ZZZZ/32
bei einem /64: 2001:14b0:XXXX:xxxx:YYYY:YYYY:YYYY:YYYY/32
Problem: wer einen valid host findet, findet sofort alle
Hosts als zwischenstation (d.h. vermutl. auch den default gw?)
Waere zu testen.
Jetzt hast Du mich abgeh�ngt. Was soll eine zuf�llige GW-IP f�r
Vorteile haben? Und was ist ein "valid host" und wo ist das Problem,
dass jemand Gateways findet? traceroute kannst Du doch auch �ber IPv4
machen. Wenn Du den Gateway sch�tzen/verstecken willst, musst Du halt
eine Firewall verwenden (anders geht das unter IPv4 auch nicht). Oder
habe ich diesen Absatz missverstanden?Gru�, Christian
--
JOIN - IP Version 6 in the WiN Christian Strauf
A DFN project Westf�lische Wilhelms-Universit�t M�nster
http://www.join.uni-muenster.de Zentrum f�r Informationsverarbeitung
Team: [EMAIL PROTECTED] R�ntgenstrasse 9-13
Priv: [EMAIL PROTECTED] D-48149 M�nster / Germany
GPG-/PGP-Key-ID: 1DFAAA9A Fon: +49 251 83 31639, Fax: +49 251 83 31653
_______________________________________________ ipv6 mailing list [EMAIL PROTECTED] http://listserv.uni-muenster.de/mailman/listinfo/ipv6
