IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Kategorie: Netzwerke & Protokolle (Seite 4 von 5)

IPv4, IPv6, DNS, DNSSEC, SSH und Netzwerk-Grundlagen — Praxiswissen für Admins und Netzwerker.

Alternative SPF-RECORDS im DNS

Veraltet: Der dedizierte SPF-DNS-Record-Typ (Typ 99) wurde mit RFC 7208 als deprecated eingestuft. SPF wird ausschließlich über TXT-Records veröffentlicht. Siehe den aktuellen SPF-Beitrag.

Da ich es gerade mal wieder auf dem Tisch habe…. Ja, „früher“ konnte man verschiedene RECORDS im DNS setzten um SPF-RECORDS zu veröffentlichen. So auch einen Record Type mit dem direkten Namen SPF. Seit 2014 ist dem aber nicht mehr so! Denn ab jetzt soll man seine SPF-Records nur noch als TXT-Record (RFC1035 Typ 16) veröffentlichen. Dieses steht im fertigen RFC7208 Abschnitt 3.1.

Damit also bitte die ganzen anderen RECORDS zu SPF aus dem DNS entfernen und nur noch TXT-RECORDS einsetzten. Ich freue mich darüber, denn bisher musste man sonst eine Vielzahl verschiedener Records pflegen, da man sich nicht sicher sein konnte, welchen jetzt bitte die Implementierung des Empfängers nutzt. Zugegeben, die Basis TXT war die am meisten verbreitete Version. Denn noch gab es da hin und wieder ein Problem. Nun steht das RFC bereits einige Zeit fest, und ich habe alle anderen „SPF-RECORDS“ aus dem DNS entfernt. Nun also nur noch TXT bei mir.

So long

SSLv3 ist tot…

Veraltet: Dieser Beitrag ist eine Momentaufnahme von 2014. SSLv3 ist seit dem POODLE-Angriff in allen Browsern und Servern deaktiviert. TLS 1.0 und 1.1 wurden ebenfalls inzwischen aus allen Browsern entfernt.

Nein, ich habe es nicht überlesen. SSLv3 ist damit wohl hoffentlich tot!

Es ist ja nicht so als wenn man nicht schon davor gewarnt hätte. Oh was hat diese Meldung bei mir für gute Laune geführt! Wieder mal ein richtiger „Told you so“ Moment für mich.

Oh ja, was zum Lesen gefällig?

http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html

Bäääähhhhmmmm! Das schreit nach einem GIF!

Told you so reaction GIF about SSLv3 deprecation

Auf die schnell böse Dinge deaktivieren…

Postfix:

smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_ciphers=high
tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA

Dovecot:

ssl_cipher_list = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4
ssl_protocols = !SSLv2 !SSLv3

Apache2:

SSLEngine on
SSLProtocol +ALL -SSLv3 -SSLv2
SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4
SSLCompression off
Header always set Strict-Transport-Security "max-age=15552000"

IPv6 und Carrier Grade NAT: Warum nicht der ISP schuld ist

Nach dem IPv6-Kongress 2014 war die Verbreitung mal wieder kurz im Rampenlicht. Nach über 15 Jahren IPv6 war die Umstellung noch immer nicht weit genug. Alle Empfehlungen von Experten wurden ignoriert. Es gab ja keine Nachfrage. Bis den ISPs die IPv4-Adressen ausgingen.

Carrier Grade NAT

Wer in Deutschland einen neuen Internetanschluss bei einem Kabelnetzbetreiber bekommt, bekommt oft einen Carrier Grade NAT (CGN) Anschluss. Das bedeutet: Keine eigene öffentliche IPv4-Adresse mehr. Stattdessen eine private Adresse hinter einem zentralen NAT-Router des ISPs. Versteckt wird das hinter Bezeichnungen wie DS-Lite oder DS64-Lite.

Das Port-Problem

Jede TCP-Verbindung verbraucht auf der abgehenden IP-Adresse einen Port. Ports sind 16-Bit-Zahlen, maximal 65.535. Abzüglich der reservierten Ports bleiben rund 64.500 gleichzeitige Verbindungen pro IP. Ein einzelner Benutzer baut schnell 50 und mehr Verbindungen gleichzeitig auf: E-Mail, Messenger, Browser mit parallelen Requests. Dazu kommen Verbindungen die nicht sauber geschlossen werden und bis zum Timeout offen bleiben.

Offene Verbindungen anzeigen:

netstat -tapen

Wenn sich hunderte Kunden eine öffentliche IP teilen, sind die Ports schnell aufgebraucht. Der ISP könnte bestehende Verbindungen nach einer Zeit hart zurücksetzen. Oder die maximale Anzahl gleichzeitiger Verbindungen pro Kunde begrenzen. Beides führt zu Problemen.

Dazu kommt: Viele Webserver und Mailserver begrenzen die Anzahl gleichzeitiger Verbindungen pro IP-Adresse, als Schutz gegen DDoS. Wenn hundert Kunden hinter einer IP sitzen, trifft dieses Limit schnell.

Wer ist schuld?

Ein gutes Beispiel war Sipgate. Der VoIP-Anbieter beschwerte sich öffentlich darüber, dass seine Kunden hinter CGN-Anschlüssen Probleme mit ihren Sipgate-Leitungen hatten. Sipgate schob den schwarzen Peter an Unitymedia und hoffte, dass sich jemand meldet um das Problem gemeinsam zu lösen.

Was dabei unterging: Unitymedia hatte auf eigene Kosten einen Workaround eingerichtet, damit Dienste die es nach Jahren noch nicht geschafft hatten IPv6 zu unterstützen überhaupt noch erreichbar waren. Und dann kommt ein Diensteanbieter und sagt: Dein Workaround funktioniert nicht perfekt mit unserem System, bitte nachbessern.

Facepalm reaction GIF about IPv6 adoption delays

Der Schuldige ist nicht der ISP. Der Schuldige ist der Diensteanbieter, der es nach über 15 Jahren Vorlaufzeit nicht geschafft hat seinen Dienst IPv6-fähig zu machen. Wer Probleme mit seinem Internetanschluss hat die auf CGN zurückzuführen sind: Nicht den ISP anrufen, sondern den Diensteanbieter fragen wann IPv6 kommt.

Fragen? Einfach melden.

Exchange Online und Office 365: DNS-Einträge für eine BIND-Zone

Bei mir ist die Frage aufgeschlagen, was man in seine BIND-Zone schreiben muss, wenn man Exchange Online, Lync/Skype for Business oder Office 365 nutzen will. Microsoft zeigt einem während der Einrichtung eine Tabelle mit DNS-Einträgen an. Für Webinterface-Hoster kein Problem, für BIND-Admins aber erstmal Übersetzungsarbeit.

Ich liebe es, wenn Microsoft solche Dinge ins Deutsche übersetzt. „Verweist auf die Adresse“ statt „Points to“. „Gültigkeitsdauer“ statt „TTL“. Aber gut.

Hinweis: Lync heißt inzwischen Teams, die SRV-Records für Lync Federation sind aber weiterhin nötig, solange Skype for Business im Tenant aktiv ist.

Was Microsoft verlangt

Für eine Domain (hier kernel-error.com als Beispiel) werden folgende Records benötigt:

# Exchange Online
MX    0  kernel-error-com0i.mail.protection.outlook.com
TXT      "v=spf1 include:spf.protection.outlook.com -all"
CNAME    autodiscover → autodiscover.outlook.com

# Lync / Skype for Business / Teams
SRV      _sip._tls           443  1 100  sipdir.online.lync.com
SRV      _sipfederationtls._tcp 5061 1 100  sipfed.online.lync.com
CNAME    sip → sipdir.online.lync.com
CNAME    lyncdiscover → webdir.online.lync.com

# Office 365 allgemein
TXT      "MS=ms12345678"   (Domain-Verifikation)
CNAME    msoid → clientconfig.microsoftonline-p.net

Das BIND-Zonefile

Und so sieht das dann als BIND-Zone aus:

$ORIGIN .
$TTL 86400
kernel-error.com  IN SOA ns1.kernel-error.de. root.kernel-error.de. (
                      2014010101 ; serial
                      15000      ; refresh
                      1800       ; retry
                      604800     ; expire
                      86400      ; minimum
                  )
                  NS  ns1.kernel-error.de.
                  NS  ns2.kernel-error.org.

$TTL 1H
                  IN TXT "MS=ms12345678"
                  IN TXT "v=spf1 include:spf.protection.outlook.com -all"
                  IN MX  0 kernel-error-com0i.mail.protection.outlook.com.

_sip._tls.kernel-error.com.              IN SRV 1 100 443  sipdir.online.lync.com.
_sipfederationtls._tcp.kernel-error.com. IN SRV 1 100 5061 sipfed.online.lync.com.

$ORIGIN kernel-error.com.
$TTL 1H
autodiscover  IN CNAME autodiscover.outlook.com.
sip           IN CNAME sipdir.online.lync.com.
lyncdiscover  IN CNAME webdir.online.lync.com.
msoid         IN CNAME clientconfig.microsoftonline-p.net.

Prüfen

Die gesetzten Records lassen sich mit dig prüfen:

dig +nocmd +noall +answer kernel-error.com IN MX @ns1.kernel-error.de
dig +nocmd +noall +answer kernel-error.com IN TXT @ns1.kernel-error.de
dig +nocmd +noall +answer _sip._tls.kernel-error.com IN SRV @ns1.kernel-error.de
dig +nocmd +noall +answer autodiscover.kernel-error.com IN CNAME @ns1.kernel-error.de

Viel Spaß mit den Microsoft-Online-Produkten. Fragen? Einfach melden.

Ping6 funktioniert nicht auf fe80-Adresse: Fehlerbehebung

Ja, die liebe fe80 Adressen! Wer schon mal ganz unbedarft folgendes in seine Konsole hämmert:

$ ping6 fe80::20c:42ff:fe72:2ba6
connect: Invalid argument

Wundert sich sicher im ersten Moment über die freche Antwort: „connect: Invalid argument“. ABER das ist absolut richtig. Denn wenn man mehrere Netzwerkkarten in seinem Rechner verbastelt hat, dann hat man ebenfalls mehrere fe80 link local Adressen. Nämlich mindestens eine pro Netzwerkkarte. Damit sollte es jetzt schon klingeln, hm? Noch nicht? Na woher soll das Paket den bitte wissen über welche der Netzwerkkarten es denn den Weg zur angepingten Adresse nehmen soll?!?!? Genau überhaupt nicht! Daher muss das Interface welches als „Ausgang“ genutzt werden soll immer mit angegeben werden.

$ ping6 fe80::20c:42ff:fe72:2ba6%eth0
PING fe80::20c:42ff:fe72:2ba6%eth0(fe80::20c:42ff:fe72:2ba6) 56 data bytes
64 bytes from fe80::20c:42ff:fe72:2ba6: icmp_seq=1 ttl=64 time=0.323 ms
--- fe80::20c:42ff:fe72:2ba6%eth0 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.323/0.323/0.323/0.000 ms

Unter Linux gibt man einfach %NIC-Name an und unter Windows einfach %NIC-ID:

C:\>ping -6 fe80::20c:42ff:fe72:2ba6%3

Ping wird ausgeführt für fe80::20c:42ff:fe72:2ba6%3 mit 32 Bytes Daten:
Antwort von fe80::20c:42ff:fe72:2ba6%3: Zeit<1ms
Antwort von fe80::20c:42ff:fe72:2ba6%3: Zeit<1ms

Ping-Statistik für fe80::20c:42ff:fe72:2ba6%3:
Pakete: Gesendet = 2, Empfangen = 2, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

C:\>

Wobei ich die Meldung eines Microsoft Windows doch schnell etwas verwirrend finde. Denn hier gibt es nur die Rückmeldung dass das Zielnetz nicht erreichbar ist. Was ja im Grunde korrekt ist, nur grenzt es leider den Fehler nicht so schön ein!

C:\>ping -6 fe80::20c:42ff:fe72:2ba6

Ping wird ausgeführt für fe80::20c:42ff:fe72:2ba6 mit 32 Bytes Daten:

Zielnetz nicht erreichbar.
Zielnetz nicht erreichbar.
Zielnetz nicht erreichbar.
Zielnetz nicht erreichbar.

Ping-Statistik für fe80::20c:42ff:fe72:2ba6:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4 (100% Verlust),

C:\>

Japp, so einfach kann es sein.

Siehe auch: IPv6 Grundlagen

Fragen? Einfach melden.

IPv6 ICMP Redirect erklärt: „rt6_redirect: source isn’t a valid nexthop“

Man stolpert irgendwann über diese Meldung im Kernel-Log:

rt6_redirect: source isn't a valid nexthop for redirect target
Illustration eines IPv6-Netzwerks mit Kernel-Logmeldung „rt6_redirect: source isn't a valid nexthop for redirect target“. Ein ICMPv6-Redirect verweist fälschlich von einer Link-Local-Adresse auf eine globale IPv6-Adresse als Next Hop, was vom System abgelehnt wird.

Gerne im Zusammenhang mit IPv6, gerne dann, wenn man glaubt, eigentlich alles richtig gemacht zu haben. Routing stimmt. Neighbors sehen gut aus. Und trotzdem meckert der Kernel.

Die Kurzfassung: Der Linux-Kernel hat ein ICMPv6 Redirect bekommen und lehnt es ab, weil der vorgeschlagene Next Hop aus seiner Sicht kein gültiger First Hop ist.

Worum geht es überhaupt?

ICMPv6 Redirects (Typ 137) sind Teil von Neighbor Discovery. Ein Router sagt damit zu einem Host sinngemäß:

„Für dieses Ziel gibt es einen besseren ersten Hop als mich.“

Wichtig: erster Hop. Nicht irgendein Router irgendwo, sondern ein direkt erreichbarer Nachbar auf dem Link.

Ein Redirect enthält deshalb zwei zentrale Informationen:

  • das Target (Zieladresse, für die das Redirect gilt)
  • den Better Next Hop

Und jetzt kommt der Teil, den viele Implementierungen (und Admins) gerne unterschätzen:
Der Host muss diesem Vorschlag nicht glauben.

Was Linux hier tatsächlich prüft

Linux ist bei Redirects ziemlich streng. Zu Recht. Redirects sind ein beliebtes Einfallstor für Unsinn und Angriffe.

Bevor der Kernel ein Redirect akzeptiert, prüft er u. a.:

  • stammt das Redirect von einem Router, den ich bereits als Router kenne?
  • liegt der vorgeschlagene Next Hop auf demselben Link?
  • ist dieser Next Hop als Neighbor bekannt bzw. grundsätzlich auflösbar?
  • passt das Ganze zur bestehenden Routing-Entscheidung?

Und genau hier schlägt diese Logmeldung zu.

Der Kernel schaut auf den Better Next Hop im Redirect und stellt fest:

„Diese Adresse kann für dieses Ziel kein gültiger Next Hop sein.“

Dann wird das Redirect verworfen. Keine neue Route. Kein Update. Nur diese Meldung.

Der Klassiker: Global statt Link-Local

In der Praxis sieht man das oft in Setups, in denen Router ihre Default-Route oder interne Routen nicht sauber über Link-Local-Adressen aufbauen.

Beispiel (vereinfacht):

default via 2001:db8:1::1 dev eth0

Sieht harmlos aus. Funktioniert auch meistens. Aber:
IPv6 erwartet, dass Router auf einem Link über ihre Link-Local-Adresse angesprochen werden.

Korrekt wäre also eher:

default via fe80::1 dev eth0

Was passiert nun?

Der Router verschickt ein Redirect und trägt als „Better Next Hop“ seine globale Adresse ein (z. B. 2001:db8:1::1).
Der Host bekommt das Redirect, prüft es – und sagt:

„Moment. Dieser Next Hop ist kein gültiger direkt erreichbarer Neighbor für dieses Ziel.“

Und genau dann landet diese Meldung im Log.

Wichtig:
Das Problem ist nicht primär, dass die Adresse global ist.
Das Problem ist, dass der Kernel den vorgeschlagenen Next Hop nicht als legitimen First Hop auf diesem Link akzeptiert.

Link-Local ist der Normalfall. Alles andere muss extrem gut begründet sein – und ist es fast nie.

Ein Blick auf die Nachbartabelle hilft

Wenn man wissen will, warum der Kernel das Redirect ablehnt, lohnt sich ein Blick in die Neighbor-Daten:

ip -6 neigh show

Oder gezielter:

ip -6 route get 2001:db8:dead:beef::1

Wenn der vorgeschlagene Next Hop dort nicht als sinnvoller Neighbor auftaucht, ist die Sache im Prinzip entschieden.
Kein Neighbor → kein gültiger Next Hop → Redirect wird verworfen.

Warum das kein Bug ist

Die Meldung klingt erstmal nach kaputtem Routing. Ist es aber meistens nicht.

Im Gegenteil:
Der Kernel verhält sich exakt so, wie es das Protokoll vorsieht. Redirects sind Hinweise, keine Befehle. Und Linux nimmt diese Hinweise nur an, wenn sie sauber in das bestehende Neighbor- und Routing-Modell passen.

Das schützt unter anderem vor:

  • falschen Router-Konfigurationen
  • kaputten RA-Setups
  • Bridge-/VM-Konstrukten mit „kreativem“ IPv6
  • trivialen Redirect-Spoofing-Angriffen

Fazit

Die Meldung

rt6_redirect: source isn't a valid nexthop for redirect target

bedeutet nicht „IPv6 kaputt“.
Sie bedeutet: Ein Router hat ein Redirect geschickt, das aus Sicht des Hosts keinen gültigen Next Hop beschreibt.

In der Praxis ist das fast immer ein Hinweis auf:

  • Default- oder interne Routen ohne Link-Local-Next-Hop (siehe auch IPv6 ULA und Adresspriorisierung)
  • Router, die globale Adressen in Redirects verwenden
  • Setups, in denen Neighbor Discovery und Routing nicht sauber zusammenpassen

Oder anders gesagt:
Der Kernel ist hier nicht pingelig. Er ist vorsichtig. Und das ist gut so.

Siehe auch: IPv6 Grundlagen

Fragen? Einfach melden.

IPv6 Prefix Delegation: FritzBox und MikroTik

Prefix Delegation per DHCPv6 ist nichts Neues. Dass eine FritzBox das bietet, war mir aber neu. Vielleicht unterschätze ich das Teil?

Ich bekomme ein /48 zugeteilt, die FritzBox bietet die — nicht weiter konfigurierbare — Möglichkeit, ein /62 per Prefix Delegation an einen weiteren Router im Netzwerk weiterzugeben.

Ich habe also meinen MikroTik über den DHCPv6-Client mit einem Prefix füttern lassen. Der MikroTik arbeitet als Hotspot und Trenner fürs WLAN. Nun schiebt dieser das per Prefix Delegation zugewiesene /64 auch ins WLAN durch.

Damit ist im WLAN über die FritzBox und den MikroTik auch IPv6 angekommen. An der FritzBox lässt sich kaum etwas hinsichtlich Netzwerk konfigurieren — ist halt alles zielgruppengerecht. Aber hier hat mich die Kiste von AVM überrascht.

Fragen? Einfach melden.

IPv6 / Default Route / DNS /DHCP

Nun arbeite ich schon seit einigen Jahren, privat wie im Berufsleben, mit IPv6. Was mir bei vielen Schulungen, Einführungen, Netzumstellungen usw… auffällt ist dass es vielen Admins schwer fällt zu verstehen wie der Client nun an seine Netzwerkkonfiguration kommt. Da in der letzten Zeit immer mehr Fragen zu dem Thema bei mir landen (scheinbar müssen viele jetzt noch „auf den letzten Drücker“ IPv6 lernen), versuche ich es hier mal grob aufzuschlüsseln. Im Grunde ist es ganz einfach: –    Bei IPv6 verteilt der DHCPv6 Server keine Default Route, das macht der Router! –    Der DHCPv6 kann DNS Server, NTP-Server usw. verteilen und für eine automatische Eintragung des Clients am DNS Server sorgen. Er kann natürlich auch zusätzliche IPv6 Adressen verteilen. –    Der Router verteilt sein Präfix per RA (Router Advertisment).       o    Der Client kümmert sich um die Generierung einer IP-Adresse.       o    Im RA kann der Client aufgefordert werden einen DHCPv6 Server nach weiteren Informationen zu fragen.       o    Im RA kann ein DNS Server an den Client übergeben werden (RDNSS) Erst einmal ist also für eine vollständige Autokonfiguration des Clients kein DHCPv6 Server mehr nötig. Denn der Client hat immer und direkt eine IPv6 Adresse vom scope link (fe80:….). Diese Adresse hat der Client sobald er einen Netzwerklink hat und wird aus der eigenen MAC-Adresse per EUI (Extended Unique Identifier) erstellt. Nun sendet der Client im einfachsten Fall ein RS (Router Solicitation) an die Multicast Adresse, auf welche ALLE Router hören, ins Netzwerk (ff02::2). Der Router antwortet dann mit einem RA und übermittelt dem Client das IPv6-Präfix. Der Client baut dann aus diesem Präfix und EUI wieder eine Adresse vom scope global. Sowie bei aktivierten Privacy Extensions eine gewürfelte Adresse. Der Client hat nun mindestens zwei IPv6 Adressen bei aktivierten Privacy Extensions sogar bereits drei IPv6 Adressen, sowie eine Default Route über den Router welcher uns den RA verpasst hat. Ist am Router die Option RDNSS gesetzt wird dem Client zum Präfix auch noch ein DNS Server übergeben. Dieses ~verstehen~ leider noch nicht alle Clients. Damit wäre der Client schon in der Lage vollständig am „Internetleben“ teil zu nehmen. Ist am Router das Other Config Flag gesetzt, wird der Client angewiesen einen DHCPv6 Server nach weiteren Einstellungen/Informationen zu fragen. Nun kommt der DHCPv6 Server ins Spiel. Wird dieser vom Client nach weiteren Einstellungen/Informationen gefragt wird er die gewünschten Informationen an den Client übermitteln. Was nicht bedeutet dass der Client damit eine weitere IPv6 Adresse bekommen muss. Es ist auch möglich nur wins, ntp, dns usw.. an die Client zu übermitteln. Der Client muss dazu über einen DHCPv6-Client verfügen. Dieser ist bisher noch nicht bei allen Clientsystemen per Default vorhanden bzw. aktiviert! Natürlich kann man seinen DHCPv6 Server auch so konfigurieren dass er zusätzlich noch eine dritte bzw. vierte (oder mehr) IPv6 Adresse an den Client übermittelt. Damit wäre der DHCPv6-Server zusätzlich in der Lage diese IPv6 Adressen einem DNS Server bekannt zu machen. Wie auch beim Thema NAT bei IPv6 gibt es Vorschläge dem DHCPv6 Server wieder die Option Route zu spendieren, ich denke es ist nicht nötig / sinnvoll… Hier kann man sich streiten! Die Idee bei IPv6 möglichst viel Arbeit auf den Client zu verlagern ergibt meist erst auf den zweiten Blick Sinn. Bei IPv4 war es bisher so dass der Client als erstes ins Netzwerk herumbrüllt ob den ein DHCP Server da ist, dann gab es einen regen Austausch zwischen diesen Systemen und am Ende hatte der Client alle seine Informationen. Denkt man aber nun daran dass im größten IPv4 Netzausbei maximal (24^2)-2 Hostadressen herausspringen und beim IPv6 im kleinsten Netzausbau minimal (64^2)-2 Hostadressen herausspringen… Ja dann ahnt man schon, wenn sich hier ein Router noch ums Popo abwischen kümmern muss, dann ist nicht mehr viel mit Netzwerk. Noch Fragen? Dann fragen….

Siehe auch: IPv6 Grundlagen

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑