Zeroconf-issues: Unterschied zwischen den Versionen
Pk (Diskussion | Beiträge) K (+ kat.) |
MiKa (Diskussion | Beiträge) |
||
| 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]] | ||
Version vom 14. Februar 2007, 18:21 Uhr
1st Contact
Habe gestern Abend mit Phillip geplaudert, Probleme mit mDNS (Multicast DNSk, Apple Zeroconf)
Durch die Trennung in 3 logische Segmente werden die Apple DNS-requests für die TLD .local nicht an alle IP-Netze weitergeleitet. Ich habe kurz recherchiert und bin schnell auf die Seite www.zeroconf.org gestossen, die vom Zeroconf-Erfinder Stuart Cheshire betrieben wird.
Die Lösung könnte trivial werden, wenn mir ein Linux-IP-Guru im IP-Stack/Routing rumstierln hilft
Grüsse, --MiKa 17:36, 14. Feb. 2007 (CET)
Findings
Im document (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, --MiKa 19:21, 14. Feb. 2007 (CET)
