Hallo,
irgendwie stehe ich auf der Leitung. Ich habe hier einen DHCP Server (ISC DHCP 4.2.3), der ist auch für IPv6 verantwortlich. Zusätzlich zu den Adressen, die die Clients sich selbst konfigurieren (nachdem sie vom Router den Präfix haben), möchte ich noch Adressen aus einem Pool vergeben. Das funktioniert soweit.
Nun wollte ich gerne die vergebenen Adressen mit dem zugehörigen Hostnamen (der Client schickt seinen Hostnamen mit) im DNS eintragen. So, wie ich das früher mit IPv4 gemacht habe. (ddns-update-style interim).
Geht nur leider nicht. Aber ich finde auch keinen passenden Logeintrag. Geht das wirklich nicht, oder bin ich zu blöd?
Danke,
Hallo Heiko,
DDNS mit bind? und dhcpd sowie IPv6
Hörensagen : "es geht nicht".
Vielleicht bringt das hier Licht ins Dunkel : http://www.pro-linux.de/artikel/2/1563/dynamisches-dns-update-im-lokalen-ipv...
Halte uns auf dem Stand ob und ggf. wie Du es löst.
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Vielleicht ist die Lösung, dass man das nicht will. Aber glauben kann ich das noch nicht. Auch ist mir nicht klar, warum der DHCP Server das nicht einfach eintragen können sollte. Ich werde mal in die Sourcen gucken müssen.
Heiko Schlittermann hs@schlittermann.de (Di 12 Jun 2012 19:13:06 CEST):
Vielleicht ist die Lösung, dass man das nicht will. Aber glauben kann ich das noch nicht. Auch ist mir nicht klar, warum der DHCP Server das nicht einfach eintragen können sollte. Ich werde mal in die Sourcen gucken müssen.
Vielleicht ist die Idee, daß ich die Adressen, die ich wirklich brauche, erst im DNS eintrage, und ggf. diese dann per DHCP an die berechtigten Clients verteile?
Und bei allen anderen ist mir der Name, der zur Adresse gehört, egal. Weil es ja eigentlich auch ziemlich unsicher ist, denn der Name, den der DHCP-Server im DNS einträgt, ja auch nur auf einer Selbstauskunft des Clients beruht.
Die Client-Identifikation, auf deren Basis per DHCP Adressen fest zugeordnet werden, natürlich auch nur…
Confused.
Ronny Seffner ronny@seffner.de (Di 12 Jun 2012 18:13:29 CEST):
Hallo Heiko,
DDNS mit bind? und dhcpd sowie IPv6
Vielleicht bringt das hier Licht ins Dunkel : http://www.pro-linux.de/artikel/2/1563/dynamisches-dns-update-im-lokalen-ipv...
Den hatte ich auch schon, er bestätigt, daß das offenbar aktuell nicht wirklich gelöst ist, außer vielleicht von den dort vorgestellten Diensten.
Ich hoffe eigentlich, daß das alles etwas einfacher ist.
Heiko Schlittermann hs@schlittermann.de (Di 12 Jun 2012 17:31:41 CEST):
Hallo,
irgendwie stehe ich auf der Leitung. Ich habe hier einen DHCP Server (ISC DHCP 4.2.3), der ist auch für IPv6 verantwortlich. Zusätzlich zu den Adressen, die die Clients sich selbst konfigurieren (nachdem sie vom Router den Präfix haben), möchte ich noch Adressen aus einem Pool vergeben. Das funktioniert soweit.
Nun wollte ich gerne die vergebenen Adressen mit dem zugehörigen Hostnamen (der Client schickt seinen Hostnamen mit) im DNS eintragen. So, wie ich das früher mit IPv4 gemacht habe. (ddns-update-style interim).
Geht nur leider nicht. Aber ich finde auch keinen passenden Logeintrag. Geht das wirklich nicht, oder bin ich zu blöd?
In den Release-Notes des mit aktuellem Debian installieren dhcp3-servers 4.1.5:
... changed since 4.1.0
- DDNS support. We now update AAAA records in the same place we would update A records, if we have an IPv6 address. We also generate IP6.ARPA style names for PTR records if we're dealing with an IPv6 address. Both A and AAAA updates are done using the same 'fqdn.' virtual option space (although the DHCPv4 FQDN and DHCPv6 FQDN options are formatted differently, they both use the same code here).
Müsste also gehen.
Heiko Schlittermann hs@schlittermann.de (Di 12 Jun 2012 21:34:07 CEST):
In den Release-Notes des mit aktuellem Debian installieren dhcp3-servers 4.1.5:
... changed since 4.1.0
- DDNS support. We now update AAAA records in the same place we would update A records, if we have an IPv6 address. We also generate IP6.ARPA style names for PTR records if we're dealing with an IPv6 address. Both A and AAAA updates are done using the same 'fqdn.' virtual option space (although the DHCPv4 FQDN and DHCPv6 FQDN options are formatted differently, they both use the same code here).
Müsste also gehen.
Wenn der Client den Namen mitschickt… geht das. Nur „send host-name“ wird nicht vom „dhclient -6“ ausgewertet, der nutzt „send fqdn.fqdn“.
Ok, steht alles in den Manuals. Der Server aktualisiert nicht immer den A/AAAA und den PTR-Record. Es hängt auch vom Client ab. Der Client teilt dem Server mit, ob er seinen A/AAAA-Record selbst aktualisieren möchte. („send fqdn.server-update …“), der Server kann den Wunsch des Clients, sich selbst im DNS zu aktualisieren, aber auch auch ignorieren („ignore client-updates„).
Allerdings kann der ISC-DHCP-Server den Namen, den er selbst eingetragen hatte (und den zughörigen TXT-Record) dann nicht mehr selber finden, Beim Versuch, ein Update des Namens einzutragen, gibt es „FAILED: Has an address record but no DHCID, not mine„ als Ausrede.
Das erforsche ich jetzt nicht mehr, zumal der 4.1.1 ja auch schon älter ist.
Ein neuerer (4.2.2) kann aber gleich gar nicht den Namen im DNS eintragen: die Ausrede ist vielsagend: „not found“… what ever er da nicht finden konnte.
Ich denke, es gibt inzwischen noch neuere, vielleicht können die das.
Schade eigentlich, IPv6 ist wohl nur etwas für die Großen… :-/
Noch mal ich…
jetzt ist mir klar, warum man eigentlich nicht (mehr?) will, daß der Server den AAAA-Record einträgt, wohl aber den PTR. Und daß evtl. der Client selbst den AAAA-Record aktualisiert.
Wir haben mit IPv6 ja eigentlich wieder globale Erreichbarkeit. Mein Laptop ist dann immer jumper.schlittermann.de. Egal in welchem Netz ich bin, ich bekomme hoffentlich eine global gültige IP, die ich vielleicht als AAAA im DNS *meiner* Zone eintragen möchte. Und wenn jemand in meiner Zone etwas eintragen darf, dann eher ich und nicht der Admin des DHCP-Servers, in dessen Reichweite ich zufällig gerade bin.
Der Admin des Netzes, in dem der DHCP-Server steht und von dem ich eine Adresse bekommen habe, der möchte sich vielleicht den PTR eintragen, damit er mich beim Fehlersuchen besser identifizieren kann. Bei dem kann dann ruhig stehen „….ip6.arpa PTR jumper.schlittermann.de“, das geht dann hoffentlich sogar auf. Und die DNS-Namen können ja wie die IPv6-Adressen global eindeutig sein.
Da ist also ein Plan dabei ☺
Danke für's Zuhören.
----- Ursprüngliche Message -----
Von: Heiko Schlittermann hs@schlittermann.de An: lug-dd@mailman.schlittermann.de CC: Gesendet: 0:08 Mittwoch, 13.Juni 2012 Betreff: Re: [Solved] Re: IPv6 und DNS Updates durch den DHCP Server
Noch mal ich…
jetzt ist mir klar, warum man eigentlich nicht (mehr?) will, daß der Server den AAAA-Record einträgt, wohl aber den PTR. Und daß evtl. der Client selbst den AAAA-Record aktualisiert.
Wir haben mit IPv6 ja eigentlich wieder globale Erreichbarkeit. Mein Laptop ist dann immer jumper.schlittermann.de. Egal in welchem Netz ich bin, ich bekomme hoffentlich eine global gültige IP, die ich vielleicht als AAAA im DNS *meiner* Zone eintragen möchte. Und wenn jemand in meiner Zone etwas eintragen darf, dann eher ich und nicht der Admin des DHCP-Servers, in dessen Reichweite ich zufällig gerade bin.
Der Admin des Netzes, in dem der DHCP-Server steht und von dem ich eine Adresse bekommen habe, der möchte sich vielleicht den PTR eintragen, damit er mich beim Fehlersuchen besser identifizieren kann. Bei dem kann dann ruhig stehen „….ip6.arpa PTR jumper.schlittermann.de“, das geht dann hoffentlich sogar auf. Und die DNS-Namen können ja wie die IPv6-Adressen global eindeutig sein.
Da ist also ein Plan dabei ☺
wie soll dann der Plan für standortlokale Adressen (site local addresses) sein (ipv6 ist doch angetretten Netze automatisch zu konfigurieren also muss doch der Fall vorgesehen sein)
fridy
Grimnin Fridyson fridy_lugdd@yahoo.de (Mi 13 Jun 2012 05:52:14 CEST):
wie soll dann der Plan für standortlokale Adressen (site local addresses) sein (ipv6 ist doch angetretten Netze automatisch zu konfigurieren also muss doch der Fall vorgesehen sein)
Du meinst diese ULA (Unique Local Address) aus dem Block fc00::/7, der in fc00::/8 (zentral gemanaged, irgendwann) und fd00::/8 (random /48-Prefixe) zerfällt?
Soweit ich das sehe, solltest Du im Idealfall solche Adressen ja nicht wirklich brauchen, außer zu Test- oder Spielzwecken, weil Du ja eigentlich genügend öffentliche Adressen bekommst (irgendwann) von Deinem freundlichen ISP.
Und ich kann mir gut vorstellen, daß es im Ermessen des Clients liegt, die Adresse als AAAA-Record dann in „seiner“ Domain einzutragen, wenn er erkennt, daß sie aus dem ULA-Bereich ist und daß damit voraussichtlich keine globale Erreichbarkeit gegeben ist.
Und zusätzlich kann ja auch dem DHCP-Server niemand verbieten, die Adresse zusätzlich auch als AAAA in der Domain der aktuellen Site einzutragen. Für den PTR-Records ist der DHCP-Betreiber aber sehr wahrscheinlich in jedem Falle zuständig.
On Wednesday 13 June 2012 10:10:27 Heiko Schlittermann wrote:
Grimnin Fridyson fridy_lugdd@yahoo.de (Mi 13 Jun 2012 05:52:14 CEST):
wie soll dann der Plan für standortlokale Adressen (site local addresses) sein (ipv6 ist doch angetretten Netze automatisch zu konfigurieren also muss doch der Fall vorgesehen sein)
Der Begriff "site local" wird nur im Zusammenhang mit Multicast benutzt. Die sind üblicherweise nicht per DHCP vergeben... ;-)
Du meinst diese ULA (Unique Local Address) aus dem Block fc00::/7, der in fc00::/8 (zentral gemanaged, irgendwann) und fd00::/8 (random /48-Prefixe) zerfällt?
Soweit ich das sehe, solltest Du im Idealfall solche Adressen ja nicht wirklich brauchen, außer zu Test- oder Spielzwecken, weil Du ja eigentlich genügend öffentliche Adressen bekommst (irgendwann) von Deinem freundlichen ISP.
Kommt darauf wie man sein lokales Netz betreibt. ULA's sind eine prima Möglichkeit lokale Services auf festen Adressen zu bieten ohne Probleme zu bekommen, nur weil nach ein paar Monaten ein Manager der Meinung ist dass ein anderer Provider günstiger ist.
Beispiel: die Firma hat eine Fertigung, einen Serverraum mit der Produktionssteuerung und ein Büro.
Der Fertigung würde ich feste Adressen aus dem ULA-Bereich geben - die Schleifmaschine braucht nicht auf Ammasohn einzukaufen, andererseits dürfen laufende Verbindungen nicht unterbrochen werden.
Das Büro bekommt nur Adressen aus dem öffentlichen Bereich (ISP supplied global scope), damit die Chefsekretärin neuen Kaffee bestellen kann, aber das Büro braucht keine festen Adressen.
Der Serverraum bekommt beides, damit die Server immer auf der selben Adresse erreichbar sind und die Verbindungen zur Produktion nicht abbrechen nur weil man den ISP wechselt.
Und ich kann mir gut vorstellen, daß es im Ermessen des Clients liegt, die Adresse als AAAA-Record dann in „seiner“ Domain einzutragen, wenn er erkennt, daß sie aus dem ULA-Bereich ist und daß damit voraussichtlich keine globale Erreichbarkeit gegeben ist.
Korrekt. Nur dass ich als Admin in einer Firma mit 24x7 Produktion keine Updates der zur ULA korrespondierenden DNS-Zone zulassen würde. Solche Probleme will man nicht diagnostizieren müssen.
ULA ist übrigens nicht nur "vorraussichtlich" nicht global erreichbar. Wenn ein ISP das durchläßt dann hat er einen fatalen Fehler gemacht.
Und zusätzlich kann ja auch dem DHCP-Server niemand verbieten, die Adresse zusätzlich auch als AAAA in der Domain der aktuellen Site einzutragen. Für den PTR-Records ist der DHCP-Betreiber aber sehr wahrscheinlich in jedem Falle zuständig.
Und woher soll der DHCPv6-Server wissen wo der PTR hinzeigen soll? Angenommen ich bin in einem Fremdnetz und bekomme per DHCP eine Adresse zugewiesen, dann schicke ich meinem DNS-Server zu Hause einen AAAA mit Adresse und meinem normalen Heim-FQDN. Der DHCPv6-Server kennt aber nur meine Adresse, meine MAC und meine DUID - er hat keine Chance einen sinnvollen PTR zu konstruieren. Wahrscheinlicher ist sogar dass ich im Fremdnetz nur SLAAC und kein DHCP mache - wenn der Router also nicht aktiv alle ICMP-Nachrichten mitsnifft, dann hat er keine Ahnung wer ich bin (RS/RA tauscht nur die Net-ID aus, die Host-ID ist erst in der DAD zu sehen - man weiß ja nicht ob ich die EUI-64 oder Privacy Extension benutze).
Konrad
Glossar für alle, die wir bis jetzt abgehängt haben:
Host - Laptop, PC, Handy, Tablet
Server - teurer PC
Router - PC mit mehreren Netzwerkanschlüssen oder kleine graue Box mit DSL
IPv4 - kurze IP-Adressen, die eigentlich schon alle sind. Es ist ein Wunder dass das Internet noch geht.
IPv6 - TCP/IP mit langen Adressen (128 bit) von denen es deutlich mehr gibt; damit es nicht so lang wird schreibt man die hexadezimal; deutsche ISPs können bisher nicht hexadezimal zählen, deswegen gibt es kein IPv6 von der Telebum
Host-ID - die letzten 64 bit einer IPv6-Adresse
Net-ID - die ersten 64 bit einer IPv6-Adresse
Prefix - die ersten Bits einer IPv6-Adresse, die ein Netzwerk gemeinsam hat; ein /64-Prefix ist meistens auch die Net-ID des LANs dem es zugewiesen ist; als Kunde eines ISP sollte man ein /56 (256 Subnetze) oder ein /48 (65536 Subnetze) bekommen
ICMP - Internet Control Message Protocol, der Teil von IP wo Ping und andere Low-Level-Nachrichten ausgetauscht werden
ULA - Unique Local Address, das IPv6-Äquivalent von 192.168.x.y
ISP - Internet Service Provider (T-Offline, 1&1, in begrenztem Maße AOL)
DHCP(v4) - dynamische Adressvergabe bei IPv4; machen kleine graue Boxen von alleine (falsch) und macht Admins graue Haare, ist aber immernoch besser als manuell ein paar tausend Rechner zu konfigurieren; manchmal ist Wäscheklammern mit aufgeklebten Nummern verwenden einfacher
DHCPv6 - was ganz anderes als DHCPv4: dynamische automatische Neu-Nummerierung von ganzen IPv6-Netzwerken über mehrere Hierarchie-Ebenen hinweg (große Firmen). Kann auch IPv6-Adressen an einzelne Hosts vergeben (eher die Ausnahme). Kleine graue Boxen mit IPv6 werden das benutzen, um für das lokale Netzwerk ein Prefix zu bekommen (wenn die Telebum es in ein paar Jahren dann schafft IPv6 einzuführen). In IPv6-LANs mit normalen Hosts wird man es nur sehen wenn der Admin einen Chef hat der darauf besteht, weil man es ja schon immer mit Däh-Hah-See-Bäh gemacht hat... ;-)
SLAAC - StateLess Address AutoConfiguration, machen kleine graue Boxen und große Router mit IPv6 von alleine; sagt dem Host wo der Router ist und in welchem Netzwerk (Net-ID) er sich befindet - die Host-ID würfelt er sich dann selbst
RS/RA - Router Solicitation/Router Advertisement - die beiden ICMP- Nachrichten, die für SLAAC benutzt werden; RS: wo ist hier ein Router?, RA: ich bin der Router für Net-ID xxx/64
DAD - Duplicate Address Detection - wenn ein Host sich eine Adresse gewürfelt hat fragt er als erstes ob die schon jemand benutzt, wenn keiner antwortet, dann kann er sie benutzen
MAC - a) die eindeutige 48-bit Adresse einer Ethernet-Karte, man kann daraus eine EUI-64 errechnen; b) weißer Host mit Apfellogo und Besitzer, der nicht weiß was IP ist
EUI-64 - eine Host-ID, die aus der MAC der angeschlossenen Netzwerkkarte errechnet wird indem man in der Mitte fffe einschiebt und Bit 7 umdreht (xor 0x02); pro Host eindeutige Host-ID
Privacy Extension - Beruhigungspille für Datenschutzbeauftragte - statt eine EUI-64 als Host-ID zu benutzen wird diese jeden Tag neu gewürfelt, damit ich auch ja nicht unter der selben Telefonnummer erreichbar bin
Konrad Rosenbaum konrad@silmor.de (Mi 13 Jun 2012 14:51:34 CEST):
Und ich kann mir gut vorstellen, daß es im Ermessen des Clients liegt, die Adresse als AAAA-Record dann in „seiner“ Domain einzutragen, wenn er erkennt, daß sie aus dem ULA-Bereich ist und daß damit voraussichtlich keine globale Erreichbarkeit gegeben ist.
Korrekt. Nur dass ich als Admin in einer Firma mit 24x7 Produktion keine Updates der zur ULA korrespondierenden DNS-Zone zulassen würde. Solche Probleme will man nicht diagnostizieren müssen.
ULA ist übrigens nicht nur "vorraussichtlich" nicht global erreichbar. Wenn ein ISP das durchläßt dann hat er einen fatalen Fehler gemacht.
Ich meine es derart, daß es kein verläßliches Ding ist, sich auf die ULA zu verlassen und dann zu meinen, man ist nicht erreichbar. Ähnlich, wie auf NAT sich keine Sicherheit aufbauen läßt.
Und zusätzlich kann ja auch dem DHCP-Server niemand verbieten, die Adresse zusätzlich auch als AAAA in der Domain der aktuellen Site einzutragen. Für den PTR-Records ist der DHCP-Betreiber aber sehr wahrscheinlich in jedem Falle zuständig.
Und woher soll der DHCPv6-Server wissen wo der PTR hinzeigen soll? Angenommen ich bin in einem Fremdnetz und bekomme per DHCP eine Adresse zugewiesen, dann schicke ich meinem DNS-Server zu Hause einen AAAA mit Adresse und meinem normalen Heim-FQDN. Der DHCPv6-Server kennt aber nur meine Adresse, meine MAC und meine DUID - er hat keine Chance einen sinnvollen PTR zu konstruieren.
Dein DHCPv6-Client kann(!) dem DHCPv6-Server seinen fqdn mitteilen. (Option fqdn.fqdn in der Konfiguration des ISC DHCP-Clients.)
Wahrscheinlicher ist sogar dass ich im Fremdnetz nur SLAAC und kein DHCP mache
- wenn der Router also nicht aktiv alle ICMP-Nachrichten mitsnifft, dann hat
er keine Ahnung wer ich bin (RS/RA tauscht nur die Net-ID aus, die Host-ID ist erst in der DAD zu sehen - man weiß ja nicht ob ich die EUI-64 oder Privacy Extension benutze).
Wenn Du nur SLAAC machst, dann steht es Dir frei, Dir einen AAAA-Record irgendwo einzutragen, und der Admin des Netzes, wo Du bist, hat eben Pech.
Das Sniffen wird ihm nichts nutzen, da Du in den ICMPv6-Messages Deinen Hostnamen/FQDN nicht verraten wirst. ICMPv6-Node-Info wird von Linuxen nicht nativ unterstützt, es gibt wohl einen Daemon, aber ob der installiert ist?
On Wednesday 13 June 2012 15:52:07 Heiko Schlittermann wrote:
Konrad Rosenbaum konrad@silmor.de (Mi 13 Jun 2012 14:51:34 CEST):
ULA ist übrigens nicht nur "vorraussichtlich" nicht global erreichbar. Wenn ein ISP das durchläßt dann hat er einen fatalen Fehler gemacht.
Ich meine es derart, daß es kein verläßliches Ding ist, sich auf die ULA zu verlassen und dann zu meinen, man ist nicht erreichbar. Ähnlich, wie auf NAT sich keine Sicherheit aufbauen läßt.
Stimmt auffallend. Als Client kannst Du nie wissen bis wo hin eine Nachricht mit ULA-Absender/-Empfänger gehen kann. Die Reichweite definiert der Netzwerk- Admin. ULA ist ja explizit so gebaut dass es (mit hoher Wahrscheinlichkeit) problemlos möglich ist zwei ULA-Netze zusammenzuschalten ohne neu nummerieren zu müssen (z.B. nachdem zwei Firmen fusioniert sind).
Und zusätzlich kann ja auch dem DHCP-Server niemand verbieten, die Adresse zusätzlich auch als AAAA in der Domain der aktuellen Site einzutragen. Für den PTR-Records ist der DHCP-Betreiber aber sehr wahrscheinlich in jedem Falle zuständig.
Und woher soll der DHCPv6-Server wissen wo der PTR hinzeigen soll? Angenommen ich bin in einem Fremdnetz und bekomme per DHCP eine Adresse zugewiesen, dann schicke ich meinem DNS-Server zu Hause einen AAAA mit Adresse und meinem normalen Heim-FQDN. Der DHCPv6-Server kennt aber nur meine Adresse, meine MAC und meine DUID - er hat keine Chance einen sinnvollen PTR zu konstruieren.
Dein DHCPv6-Client kann(!) dem DHCPv6-Server seinen fqdn mitteilen. (Option fqdn.fqdn in der Konfiguration des ISC DHCP-Clients.)
Hmm. Stimmt auch. Hatte ich nicht beachtet, weil meine eigene DHCPv6- Implementation das nicht kann (die kann eigentlich nur PD und minimales IA).
Wahrscheinlicher ist sogar dass ich im Fremdnetz nur SLAAC und kein DHCP mache - wenn der Router also nicht aktiv alle ICMP-Nachrichten mitsnifft, dann hat er keine Ahnung wer ich bin (RS/RA tauscht nur die Net-ID aus, die Host-ID ist erst in der DAD zu sehen - man weiß ja nicht ob ich die EUI-64 oder Privacy Extension benutze).
Wenn Du nur SLAAC machst, dann steht es Dir frei, Dir einen AAAA-Record irgendwo einzutragen, und der Admin des Netzes, wo Du bist, hat eben Pech.
Bei DHCP genauso. Die FQDN-Option würde ich nur setzen, wenn ich mir etwas davon verspreche - falls sich das in 10 Jahren als Mechanismus für PTR-Records durchsetzen sollte, dann vielleicht...
Im Augenblick sehe ich sowieso nur zwei vollkommen legitime Anwendungsfälle für DHCPv6: Prefix Delegation vom ISP zum Kunden und PD innerhalb eines großen Firmennetzes. Alles andere ist "Spielerei", da Net-ID (und damit dynamische Adressierung) und DNS-Server bereits per SLAAC kommen - die Arbeit mit DHCP im LAN kann ich mir also sparen.
Das Sniffen wird ihm nichts nutzen, da Du in den ICMPv6-Messages Deinen Hostnamen/FQDN nicht verraten wirst.
Stimmt.
ICMPv6-Node-Info wird von Linuxen nicht nativ unterstützt, es gibt wohl einen Daemon, aber ob der installiert ist?
Bei mir bestimmt nicht. So aus Neugier: fällt Dir irgendwas ein wo man NI tatsächlich einsetzen will? Mir nicht.
Konrad
lug-dd@mailman.schlittermann.de
-
Grimnin Fridyson -
Heiko Schlittermann -
Konrad Rosenbaum -
Ronny Seffner