Hi Kurt!

Kommentare siehe Inline.

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
Rechnet Ihr kein Volumen ab? (Ist nat�rlich kein Problem, ist nur eine generelle Frage.)

[Cryptografisch sichere Adressen]
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.
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.

Daher: Vorschlag zur Policy: Also werden auch unter v6 Adressen
im Normalfall statisch vergeben.
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:

(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.

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.
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.

Nachteil von 2) Schwierig in der Handhabung.
Deswegen w�rde ich statisch keine IPs vergeben.

- Vorschlag zur Adressverteilung:
  o Ethernetze bekommen zufaellig ausgewaehlte /48 aus dem /32-Fenster
Das ist dann f�r gr��ere Kunden, die quasi eigene Sites haben, richtig? Das w�rde hinkommen.

  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 entsprechenden
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.
Gut, 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.

  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

Antwort per Email an