Global Unicast (RFC3587)
=========================

entspricht den public-IPs

die meisten dieser Adressen sind noch reserviert, aber
vereinzelt beginnt man schon 'global unicast adressen' zu vergeben.
Die allozierten Bloecke werden nachstehend aufgelistet:

prefix beabsichtigte Verwendung RFC
----------------------------------------------------------------
2001::/16 production via RFC 2450
Regional Internet Registries
2002::/16 6to4 transition mechanism RFC 3056
3ffe::/16 6bonetest network RFC2471,3701

Einige Adressbereiche des "production address space" sind in grossen Teilstuecken den sog. RIR's (Regional Internet Registries) zugewiesen. Diese wiederum vergeben kleinere Adressbereiche (aus deren Bereich) an die LIR (local internet registries) - z.B. ISP's - und so kommt dann die eine oder andere IPv6-Adresse zum Endkunden

Link-local-Addressing
=====================

diese Adressen machen nur Sinn an einem einzelnem link - der wird an jedem link eingesetzt, an dem IPV6 konfiguriert wurde

ein "link" ist eine Gruppe von Maschinen die direkt miteinander reden koennen

ein buero kann so diese Adressen fuer interne communication einsetzen

eine point-to-point-Verbindung zwischen zwei routern kann mit link-local-Adressen versehen werden - ist aber 1. nicht notwendig, weil es Adressen wie Sand am Meer gibt und 2. koennte es sein, dass router icmp-error-messages senden sollen, und dafuer wieder eine global-unicast-Adresse brauchen

multicast:
=========

mit mehreren Rechnern gleichzeitig reden (begrenzte Anzahl von Rechnern) unicast in diesem Fall inefficzient, weil jedes Paket fuer jeden Rechner einzeln extra zu versenden ist - broadcasting ist noch ineffizienter, weil jedes Paket an alle Rechner geht, und das koennen sehr vielen sein

Ein host kann sich zu einer bestimmten multicast-Adresse hinzugesellen!!

multicast-groups werden ueber die multicast-adressen definiert

in ipv6 ist multicast obligatorisch! ein Herzstueck (zentrales Element)

multicast wird auch eingesetzt, um das Equivalent zu ARP zu implementieren (ICMPv6)

multicast braucht keine Konfiguration, wenn es auf ein Netzwerk begrenzt ist

fuer multicast ueber die eigene Netzwerk-grenze hinaus braucht es eigene multicast-daemons

link-local-multicast:
--------------------

die multicast-Adressen sind aufgeteilt in einzelne kleinere Bereiche (chunks) die die unicast-adressen wiederspiegeln sollen

multicast-Adressen haben die Form:

ffXY::...

X ist eine Folge von 4bits von flags
Y gibt die Gueltigkeitsbereich (scope) des multicast an

das top-bit der flags ist reserviert und sollte 0 sein.

das letzte bit sollte auf 1 gesetzt sein, wenn es sich um eine transiente Adresse (von kurzer Dauer) handelt (im Gegensatz zu einer wohlbekannten (well-known) multicast adresse) well-known ==> ist eine Adresse fuer ein well-known service (z.B. dhcpv6) eine transiente ist eine dynamisch kreierte, die z.B. eingesetzt wird, um ueber diese eine Anzhal Rechner fuer einen Radio-stream zu erreichen, den ich aussenden will

bei well-known adressen muessen die anderen flags auf null gesetzt sein

bei transienten Adressen sind die beiden mittleren flags interessant

00 ==> weist auf eine beliebige vergebene Adresse hin (Adresse wurden festgesetzt vom verantwortlichen fuer link/site/network - scope von Adresse muss auch passen

01 ==> weist auf eine Festlegung hin, die auf einen unicst-prefix basiert, was den Vorteil hat, dass ein block (prefix) von ipv6-adressen verwendet wird, dass autom atisch ein Block von multicast-Adressen zur Verfuegung steht.

11==> weist auch auf eine Festlegung hin, die auf einen unicst-prefix bas
iert - aber dieses Mal ist es eine Adresse eines sogenannten
rendezvous-points, der auch in der multicast-Adresse encoded sein kann.

Ein rendezvous-point ist einPlatz im multicast-netzwerk der als Verteilerpunkt fuer bestimmte multicast-Stroeme dient.

Diesen punkt zu finden ist tricky und problematisch in manchen typen von multicast-routing -- deshalb macht es das Leben einfacher, wenn dieser in der multicast-Adresse bereits inkludiert wird

scope-values:
============

das sind prefixe fuer well-known und simple transiente Adressen fuer diesen Ausschnitt

da gibt es auch aehnliche bloecke auch fuer Adressen mit anderen flags

scope value well-known transient
-------------------------------------------------------------
reserved 0 ff00::/16 ff10::/16
node-local 1 ff01::/16 ff11::/16
dieses Paktet verlaesst das Interface nie! (vergleichbar mit loopback)
link-local 2 ff02::/16 ff12::/16
koennen das Teilnetz nicht verlassen (weil nicht geroutet)
reserviert 3 ff03::/16 ff13::/16
admin-local 4 ff04::/16 ff14::/16
der kleinste Bereich, dessen Abgrenzung in den Routern speziell administriert werden muss
site-local 5 ff05::/16 ff15::/16
duerfen zwar geroutet werden, jedoch nicht von Border-Routern
organization-local 8 ff08::/16 ff18::/16
global E ff0e::/16 ff1e::/16
reserved F ff0f::/16 ff1f::/16

es gibt well-known-Adressen, die eine variable scope haben -- z.B.

ff0X::101 ist bestimmt fuer NTP-servers mit Reichweite X.

andere wiederum sind nur in einem bestimmten Bereich gueltig!!!
z.B. DHCPv6-server bekommen eine site-local- scope address von
ff05::1:3

In manchen Faellen sind IP-Address-ranges festgelegt
z.B
ff02::1:ff00:0/104

fuer eine
solicited node multicast
(vom node angeforderte multicast-adresse)

wenn ein node eine unicast-Adresse hat, die mit
ab:cdef, dann muss der Teil der multicast-gruppe

ff02::1:ffab:cdef

sein.

Da ein interface mehrere adressen haben kann, so kann ein interface mehrere solcher Adressen bergen. ABER wenn die interface-ID dieselbe ist fuer alle unicast-adressen, dann braucht das interface nur eine haben, die den soliceted-multicast-group folgt.

www.iana.org => da gibt es liste von vergebenen multicast-Adressen

ff02::1 und ff02::2 sollte jeder kennen

ff02::1
ist die link-local all nodes Adresse (entspricht der non-routed broadcast-adresse)

ff02::2
ist die link-local all routers adresse, die im ipv6-autoconfiguration-prozess eine Rolle spielt.