Zeroconf-issues: Unterschied zwischen den Versionen
Pk (Diskussion | Beiträge) K + kat. |
MiKa (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
Zeile 1: | Zeile 1: | ||
== 1st Contact == | |||
Habe gestern Abend mit Phillip geplaudert, Probleme mit mDNS (Multicast DNSk, Apple Zeroconf) | Habe gestern Abend mit Phillip geplaudert, Probleme mit mDNS (Multicast DNSk, Apple Zeroconf) | ||
Zeile 4: | Zeile 6: | ||
Die Lösung könnte trivial werden, wenn mir ein Linux-IP-Guru im IP-Stack/Routing rumstierln hilft | Die Lösung könnte trivial werden, wenn mir ein Linux-IP-Guru im IP-Stack/Routing rumstierln hilft | ||
Grüsse, --[[Benutzer:MiKa|MiKa]] 17:36, 14. Feb. 2007 (CET) | Grüsse, --[[Benutzer:MiKa|MiKa]] 17:36, 14. Feb. 2007 (CET) | ||
== Findings == | |||
Im document ([http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt draft-cheshire-dnsext-multicastdns.txt]) zu mDNS habe ich folgendes gefunden: | |||
3. Multicast DNS Names | |||
This document proposes that the DNS top-level domain ".local." be | |||
designated a special domain with special semantics, namely that any | |||
fully-qualified name ending in ".local." is link-local, and names | |||
within this domain are meaningful only on the link where they | |||
originate. This is analogous to IPv4 addresses in the 169.254/16 | |||
prefix, which are link-local and meaningful only on the link where | |||
they originate. | |||
Any DNS query for a name ending with ".local." MUST be sent | |||
to the mDNS multicast address (224.0.0.251 or its IPv6 equivalent | |||
FF02::FB). | |||
Das bedeutet, dass wir einer gerouteten Umgebung verloren haben, außer wenn wir auf eine Bridging-Umgebumg migrieren. Nur die m-cast-packete mit 224.0.0.251 an die anderen Segmente weiterzureichen könnte zu Ambiguitäten führen, da nicht sichergestellt ist, 1) dass eine 169.254.0.0/16 Adresse nicht schon im anderen Segment vergeben ist und 2) dass die Zieladresse auch ins andere Segment geroutet wird, da der Router keine Route dafür aufbauen kann. | |||
Eine mögliche Lösung wäre, wenn wir selektiv nur IPv4 Link-Local Addressing transparent bridgen, um zu erreichen, dass 169.254.0.0/16 Adressen nicht mehrfach vergeben werden und sich die Geräte direkt ohne Routing sehen können. | |||
Die letzte Lösung die mir einfällt, wäre das Netz umzugestalten und die Segmente, die Bonjour mit IPv4LL und mDNS benötigen zu bridgen und mit Routing vom restlichen abzutrennen. | |||
Grüsse, --[[Benutzer:MiKa|MiKa]] 19:21, 14. Feb. 2007 (CET) | |||
[[Kategorie:Netzwerk]] | [[Kategorie:Netzwerk]] |