Zeroconf

A nulla konfigurációjú hálózat vagy aZeroconfaz általános név annak aprotokollkészletnek, amelyautomatikusan létrehoz egyIP-hálózatot ,amely különösebb konfiguráció vagy dedikált szerverek nélkül használható.

Ez lehetővé teszi a kezdő felhasználók számára, hogy számítógépeket, nyomtatókat és más perifériákat csatlakoztassanak a hálózathoz, és elvárják, hogy az automatikusan működjön. Zeroconf nélkül a felhasználónak vagy speciális szolgáltatásokat kell beállítania, például DNS-t és DHCP-t , vagy manuálisan kell konfigurálnia az egyes eszközök hálózati beállításait, ami nehéz lehet azok számára, akik nem ismerik ezeket a technikákat.

A Zeroconf protokollok a következő funkciókat kínálják:

Dinamikus IP-cím kiosztás: IPv4LL / APIPA

Az IPv4 és az IPv6 egyaránt szabványosított technikákkal rendelkezik a hálózati interfészek címeinek automatikus konfigurálásához.

Az IPv4 esetében az IETF RFC  3927 meghatározza az IP-címek dinamikus allokálását a 169.254.0.0/16 tartományban. Az RFC ezt a technikát IPv4 link-local (IPv4LL) címkiosztásnak hívja . Azonban a Microsoft utal rá, mint APIPA vagy Internet Protocol Automatic Configuration (IPAC).

Az IPv6 esetében az automatikus link-helyi cím kiosztást az RFC  4862 írja elő.

Névfeloldás

Kezdetek

Az első javasolt névfeloldási protokollt Bill Manning és Bill Woodcock jelentette meg 2000-ben Multicast Domain Name Service néven . Ezt az Apple és a Microsoft munkaalapként használta fel saját protokolljaik kidolgozásához.

Multicast DNS (mDNS)

A Multicast DNS (mDNS) protokollt az Apple javasolja szabványtervezetként. Jelenleg a leggyakrabban használt.

A multicast DNS (mDNS) az unicast DNS-hez hasonló , de másképp megvalósított datagram protokoll . A helyi hálózat minden számítógépe megtartja a saját DNS-rekordjainak listáját (pl. A, MX, SRV  stb. ), És amikor egy mDNS kliens a nevéből meg akarja tudni a hálózati eszköz IP-címét, akkor az eszköz egy megfelelő A rekorddal IP címével válaszol. Az mDNS által használt multicast cím 224.0.0.251.

Link-local Multicast Name Resolution (LLMNR)

A Link-local Multicast Name Resolution (LLMNR) protokollt a Microsoft hivatalosan elfogadta internetes szabványként az IETF DNSEXT munkacsoportja által , de nem sikerült konszenzust elérni, és csak RFC informális formában jelent meg ( RFC  4795). Ma még kevéssé használt.

Összehasonlító

A két protokoll kisebb eltéréseket mutat a névfeloldás megközelítésében. Az mDNS lehetővé teszi egy hálózati eszköz számára, hogy domain nevet válasszon a ".local" névtérből, és egy speciális multicast IP- címmel hirdesse . Ez különböző szemantikát vezet be a ".local" névtérre, amelyet problémának tekintenek az IETF tagjai . Az LLMNR jelenlegi specifikációja lehetővé teszi a hálózati eszköz számára, hogy bármely tartománynevet kiválasszon, amelyet az IETF tagjai biztonság szempontjából kockázatosnak tartanak. Ezenkívül az mDNS kompatibilis a következő szakaszban leírt - és az Apple által is javasolt - DNS-SD protokollal, míg az LLMNR nem.

Miután az LLMNR nem működött internetes szabványként, és tekintettel arra, hogy az mDNS és a DNS-SD protokollokat sokkal szélesebb körben használják, mint az LLMNR-t, az IETF felkérte az Apple-t, hogy nyújtsa be két protokolljának specifikációit, hogy azokat informális RFC-ként tegye közzé.

Szolgáltatások keresése

DNS-szolgáltatás felderítése (DNS-SD)

A DNS-Service Discovery (DNS-SD) protokoll az mDNS használatán alapul. Az Apple termékek, sok hálózati nyomtató, valamint számos termék és alkalmazás használja különböző operációs rendszereken. A Microsoft versengő SSDP technológiájától eltérően a DNS-SD a HTTP helyett a DNS-t használja . SRV , TXT  (en) és PTR  (en) típusú DNS rekordokat használ az elérhető szolgáltatások reklámozásához. A szolgáltatásokat kínáló házigazdák közzéteszik a szolgáltatás részleteit, például a szolgáltatás típusát, a domain nevet és az opcionális konfigurációs paramétereket. A DNS-SD.org webhely frissíti és közzéteszi a meglévő (nem teljes) típusú szolgáltatásokat. A szolgáltatások típusait informálisan, a sorrendben nyilvántartják.

Számos Mac OS X-hez tartozó hálózati szoftver , például a Safari böngésző , az iChat azonnali üzenetküldő szoftver a DNS-SD-t használja a szerverek vagy társak felkutatására a helyi hálózaton. Más Mac OS X szoftverek, például az iPhoto fotókezelő szoftver vagy az iTunes zenekezelő szintén DNS-SD-t használnak tartalmuk megosztására. Windows rendszeren néhány azonnali üzenetküldő és VoIP kliens, például a Gizmo5, használja a DNS-SD-t. Egyes Linux disztribúciók tartalmazzák a DNS-SD támogatását is.

Az MDNS és a DNS-SD protokollokat Stuart Cheshire  (in) , az Apple alkalmazottja fejlesztette ki , amikor a vállalat elhagyta az AppleTalk protokollt az IP protokollhoz .

Az Simple Service Discovery Protocol (SSDP) egy IETF nélküli UPnP protokoll,amelyet a Windows XP és számos márkájú hálózati hardverhasznál. Az SSDP HTTP-értesítéseken keresztül jeleníti meg a hirdetéseket, URI szolgáltatástípustés egyedi szolgáltatásnevet (USN) szolgáltatva. A szolgáltatások típusait az UPnP irányítóbizottsága szabályozza.

Az SSDP-t sok tűzfaleszköz támogatja , ahol a mögötte álló számítógépek lyukakat üthetnek az alkalmazások számára. Néhány médiaközpont típusú berendezés is használja , ahol az adathordozók cseréjét a gazda és a médiaközpont között megkönnyíti az SSDP használata.

A Service Location Protocol (SLP) az egyetlen protokoll az IETF Standard javaslat állapotát elért szolgáltatások megkeresésére. Ezt a protokollt a Hewlett-Packard , a Novell , a Sun Microsystems, valamint az Apple hálózati számítógépek és hálózati nyomtatók használják, de néhány más nagyobb gyártó figyelmen kívül hagyja. Az SLP-t az IETF SVRLOC munkacsoportja által kiadott RFC  2608 és RFC 3224írja le,és a megvalósítások elérhetőek Mac OS X , Solaris és Linux operációs rendszerekhez .

NAT átjáró bejárása

Az Apple által RFC projektként javasolt NAT- port-hozzárendelési protokoll (NAT-PMP) lehetővé teszi, hogy egy magánhálózaton (egy NAT- átjáró mögött ) lévő számítógép automatikusan konfigurálja az átjárót, hogy a magánhálózaton kívüli gépek kapcsolatba léphessenek vele.

A Protocol Gateway Device Internet  (en) (IGD) egy olyan protokoll, amelyet az UPnP egyes NAT átjárókban támogat. Ez a port-továbbítás általánosan használt módszer, de még nem nyújtották be az IETF-hez.

Főbb megvalósítások

Az alábbi szakaszok az IETF Zeroconf protokollok legnépszerűbb megvalósításait mutatják be.

Apple Hello

Az Apple által kifejlesztett Bonjour ( korábban Rendez-vous néven ismert) az mDNS, DNS-SD és NAT-PMP protokollok legnépszerűbb megvalósítása, elsősorban Mac OS X rendszeren (ez elérhető a Microsoft Windows számára is) ). Eredetileg az SLP kínálta a Bonjour keresési szolgáltatásait, de az Apple az SLP-t mDNS-re és DNS-SD-re cserélte a Mac OS X 10.1 és 10.2 között , bár az SLP-t továbbra is támogatja a Mac OS X.

Avahi

Az Avahi egy szoftverkönyvtár, amely az IPv4LL, mDNS és DNS-SD protokollok ingyenes megvalósítását biztosítja . Számos GNU / Linux és * BSD disztribúció használja .

Az Avahi megvalósítása teljesen kompatibilis a Bonjouréval. Az Avahi kompatibilitási könyvtárakat biztosít a Bonjour vagy az mDNS régi ingyenes Howl implementációját használó alkalmazásokhoz. Avahi is biztosít interfészeket különböző programozási nyelvek ( Python , Mono ,  stb ), és kínál egy D-Bus interfész .

Windows CE 5.0

A Windows CE 5.0 biztosítja az LLMNR protokoll Microsoft általi megvalósítását.

IPV4LL / APIPA megvalósítások

Hivatkozások

  1. (in) "  Dynamic Configuration IPv4 link-local címek  " Request for Comments n o  3927,2005. május.
  2. (a) "  IPv6 automatikus címbeállítást  " Request for Comments n o  4862,2007. szeptember.
  3. (in) Multicast Domain Name Service , Internet Draft , 2000 ietf.org.
  4. (in) Multicast DNS , Internet Draft 2011. multicastdns.org.
  5. (in) Internet Engineering Task Force , ietf.org.
  6. (in) "  Link-Local Multicast Name Resolution (LLMNR)  ," Request for Comments n o  4795,2007. január.
  7. (in) További részletek a különbségekről , mhonarc.org.
  8. (in) DNS SRV (RFC 2782) szolgáltatás típusa , dns-sd.org.
  9. DNS-SD.org .
  10. (in) "  Service Location Protocol Version 2  " Request for Comments n o  2608,1999. június.
  11. (in) "  Szolgáltatói kiterjesztések a szolgáltatás helye protokollhoz, 2. verzió  " Megjegyzések iránti kérelem, n o  3224,2002. január.
  12. (in) NAT Port Mapping Protocol (NAT-PMP) , Internet Draft , 2006, ietf.org.

Lásd is

Kapcsolódó cikkek

Külső linkek