- Details
-
Erstellt: Donnerstag, 06. Dezember 2018 10:42
Inzwischen ist es kaum noch etwas Besonders von seinem ISP mit einem echten globalen IPv6 /64 beworfen zu werden. Dualstack bietet fast jeder an. Die meisten Dienste im Internet sind ebenfalls so erreichbar und fast jeder in der IT hat zumindest schon mal von IPv6 gehört.
Nicht ganz so bekannt sind anscheinend bei IPv6 die ULAs die Unique Local Addresses RFC 4193. Es ist der Bereich fc00::/7 und im speziellen der Bereich fd00::/8 ist bei IPv6 vergleichbar mit den alten bekannten 10.0.0.0/8, 172.16.0.0/12 und natürlich 192.168.0.0/16. Wenn mal also sein internes Netzwerk für IPv6 Aufbaut benutzt man diese Adressen.
Auf der Arbeit beschäftigen wir uns auch mit diesem Thema. Wir haben uns ein /48 gewürfelt, geplant wie wir verschiedene /56 daraus auf die verschiedenen Standorte verteilen bis am Ende in den verschiedenen Netzten ein /64 per RA herauskommt. Stück für Stück verteilen wir im Moment die einzelnen Netze und so bekommen immer wieder neue Systeme zu ihrer IPv4 Adresse auch eine IPv6 Adresse. Immer mal wieder stößt man selbst 2018 dabei noch auf Überraschungen. Die eine oder andere werde ich in der nächsten Zeit mit euch teilen.
Starten möchte ich heute mit unserer Samsung Printstation X4300LX. Diesem Drucker wollten wir die im zugedachte IPv6 ULA fest einstellen. Leider beantwortete der Drucker diesen Versuch immer nur mit: Make sure your input is correct. This field only allows IPv6 address
Simple Image Gallery Extended
Gehen wir erst einmal auf das Thema fest einstellen ein, bevor dazu die ersten Mails kommen :-D
Bei IPv6 sollte der Client selbst sich darum kümmern eine Adresse zu haben. Selbst im kleinsten "sinnvollen" IPv6 Netz (/64) gibt es so viele Adressen, dass bekannte zentrale Möglichkeiten schnell gestresst sein könnten. Daher bekommt der Client per RA Router Advertisement einige der nötigen Informationen um sich selbst eine Adresse zu basteln. Im Zusammenspiel mit der eigenen MAC Adresse kommt dann eine IPv6 Adresse zustande. Sofern diese Adresse nicht schon einmal im Netzwerk vertreten ist (dieses prüft der Client selbst per NDP Neighbor Discovery Protocol) hat der Drucker damit immer die selbe Adresse. Warum also selbst eine feste IPv6 Adresse am Drucker vergeben? Nun ja, für die Zeit der Umstellung ist es etwas einfacher wenn die IPv6 Adressen für uns Menschen etwas übersichtlicher sind. Die eigentlichen Benutzer kommen an keiner Stelle mit den Adressen in Berührung, sie nutzen ausschließlich den DNS Namen. Für uns Admins ist es dennoch etwas einfacher wenn gewisse zentale Systeme schon für uns an der IPv6 Adresse erkennbar sind. Zumindest solange wir noch im Aufbau des gesamten ULA Netzwerkes bei uns sind. Später wird dieses natürlich anders sein.
Zurück zum Drucker! Die eingegebene IPv6 Adresse ist natürlich gültig und absolut korrekt. Also haben wir uns an unseren Servicepartner für den Drucker gewendet. Hier ist IPv6 noch nicht so "weit". Aussage war das wir die Ersten sind welche sich zu diesem Thema jemals gemeldet haben. Unser Servicepartner hat sich selbst noch etwas schlau gemacht und ist dann direkt in Kontakt mit Samsung / HP getreten. Die erste Rückmeldung die wir bekommen haben ist: Wenn wir das fd00 zum Beginn weglassen, dann könnten wir eine Adresse eintragen. Sie könnten dieses an verschiedenen Drucker so nachstellen. Zusammen sind wir dann zum Schluss gekommen, dass einfach die Adressüberprüfung vom Samsung SyncThru Web Service einen Bug hat. Unser Servicepartner ist also wieder in Kontakt mit seinem Ansprechparnter bei Samsung / HP getreten. Von diesem kam einige Zeit später eine E-Mail welche uns weitergeleitet wurde. In dieser E-Mail wird uns erklärt das IPv6 Adressen eindeutig sein sollten und wie sich aus der MAC Adresse eine IPv6 Adresse berechnet. Was natürlich absolut korrekt ist, unser eigentliches Problem nur leider nicht betrifft oder löst. Wir haben also wieder mit unserem Servicepartner gesprochen welcher uns wenig Hoffnung machte. Wenn Samsung / HP meint keinen Fehler gemacht zu haben wird es schwer ihnen das Gegenteil zu beweisen. Wir könnten dem Drucker ja einfach per DHCPv6 eine Adresse reservieren....
Joar könnten wir.... Wir haben einen zentralen DHCPv4 und auch einen zentralen DHCPv6 Server. Verschiedene DHCP-Relay Server leiten die Anfragen aus verschiedenen Netzten an diesen weiter. Dieses funktioniert für IPv4 und IPv6 problemlos. Für IPv4 kümmert er sich zusätzlich um gewisse Reservierungen und die Adressvergabe. Bei IPv6 (hierzu ist im RA das Flag "other config" gesetzt) holt er sich Dinge wie DNS, Timeserver, Searchdomains usw... Wir wollen aus beschriebenen Gründen keine Adressreservierungen per DHCPv6. Ausgewählte Systeme bekommen hier eine eindeutige und vorher definierte IPv6 Adresse und der Rest darf alleine rechnen. DHCPv6 fällt also raus. Für diese Druckstation werden wir also ersteinmal die selbstgerechnete Adresse benutzen bis wir es zusammen mit unserem Servicepartner geschafft haben Samsung / HP davon zu überzeugen das es einen Bug in ihrem SyncThru Web Service gibt.
Wenn also jemand einen guten Kontakt hat..... Wir können ja nicht die Einzigen sein welche versuchen ein ULA Netz aufzubauen, oder?
Samsung / HP sind nicht die Einzigen welche hier noch Probleme haben. Wir sind noch auf viele andere spannende Dinge gestoßen und wir werden sich noch auf einige kommen. Ausgewählte wird es hier wie angekündigt geben!
- Details
-
Erstellt: Montag, 21. Januar 2019 12:57
Ihr erinnert euch sicher noch an das IPv6 Druckerproblem zwischen uns und HP/Samsung, oder? Es gibt ein kleines Updates zu dem Thema!
Betreff: RE: X4300 und IPv6
was ist aus der IPv6 Anfrage des Kunden geworden? Hat der Admin einen anderen Weg gefunden?
Wir hatten den Fall eskaliert und folgende Antwort bekommen:
JSP will successfully validate only following IPv6 address types in manual address box:
1. Site local IPv6 addresses (With prefix fec0)
2. Link local addresses with prefix fe80
3. Global unicast addresses with prefix
Das heißt zusammengefasst, dass der Kopierer nicht mit einer Unique Local Address (fd00 Präfix) arbeiten kann.
Ich würde mich freuen, wenn sie sich diesbezüglich nochmal bei uns melden, damit wir wissen, ob wir den Fall schließen können.
Danke und beste Grüße
fec0?!?!? Das war eine Idee aus 1995 welche 2004 aus guten Gründen mit RFC 3879 gekippt wurde. Der Drucker frisst also fe80 sauber per EUI-64 (oh was ein wunder), globale Adressen (ok, kann jemand sinnvolle und brauche Ansätze nennen warum man das tun sollte?!?) und Adressen die man seit knapp 15 Jahren nicht mehr benutzen sollte O_o
Mal sehen wie Samsung / HP nun darauf reagiert. Ich kann doch nicht der einzige auf diesem Planeten mit dem Problem sein. dieses JSP-Ding wird doch auf allen erdenklichen Netzwerkdruckern eingesetzt. Das muss doch noch jemandem auffallen, oder? Dieser Bug muss doch nur von einem Entwickler dort gelesen werden, der versteht was ich sage, dann macht er es schnell schön und gelöst ist das Problem. Ist da denn keiner?!?
