Mise en réseau sans configuration

La mise en réseau sans configuration ( zeroconf ) est un ensemble de technologies qui crée automatiquement un réseau informatique utilisable basé sur la suite de protocoles Internet (TCP/IP) lorsque des ordinateurs ou des périphériques réseau sont interconnectés. Elle ne nécessite pas l'intervention manuelle d'un opérateur ni de serveurs de configuration spéciaux. Sans zeroconf, un administrateur réseau doit configurer des services réseau , tels que le protocole DHCP (Dynamic Host Configuration Protocol ) et le système de noms de domaine (DNS), ou configurer manuellement les paramètres réseau de chaque ordinateur.

Zeroconf s'appuie sur trois technologies de base : l'attribution automatique d' adresses réseau numériques pour les périphériques en réseau, la distribution et la résolution automatiques des noms d'hôtes des ordinateurs et la localisation automatique des services réseau , tels que les périphériques d'impression.

Les réseaux informatiques utilisent des adresses réseau numériques pour identifier les points de terminaison des communications dans un réseau d'appareils participants. Cela est similaire au réseau téléphonique qui attribue une chaîne de chiffres pour identifier chaque téléphone. Dans les protocoles réseau modernes , les informations à transmettre sont divisées en une série de paquets réseau . Chaque paquet contient les adresses source et de destination de la transmission. Les routeurs réseau examinent ces adresses pour déterminer le meilleur chemin réseau pour transmettre le paquet de données à chaque étape vers sa destination.

De la même manière que les téléphones étaient étiquetés avec leur numéro de téléphone, il était courant dans les premiers réseaux d'apposer une étiquette d'adresse sur les périphériques en réseau. La nature dynamique des réseaux modernes, en particulier les réseaux résidentiels dans lesquels les périphériques ne sont mis sous tension qu'en cas de besoin, nécessite des mécanismes d'attribution d'adresses dynamiques qui ne nécessitent pas l'intervention de l'utilisateur pour l'initialisation et la gestion. Ces systèmes se donnent automatiquement des noms communs choisis soit par le fabricant de l'équipement, comme une marque et un numéro de modèle, soit par les utilisateurs pour identifier leur équipement. Les noms et adresses sont ensuite automatiquement saisis dans un service d'annuaire .

Les premiers réseaux informatiques reposaient sur les technologies des réseaux de télécommunications et les protocoles tendaient donc à se diviser en deux groupes : ceux destinés à connecter des appareils locaux à un réseau local (LAN) et ceux destinés principalement aux communications longue distance. Ces derniers systèmes de réseau étendu (WAN) avaient tendance à avoir une configuration centralisée, où un administrateur réseau attribuait manuellement des adresses et des noms. Les systèmes LAN avaient tendance à fournir une plus grande automatisation de ces tâches afin que de nouveaux équipements puissent être ajoutés à un LAN avec un minimum d'intervention de l'opérateur et de l'administrateur.

AppleTalk est un exemple précoce de système LAN sans configuration. Il s'agit d'un protocole introduit par Apple Inc. pour les premiers ordinateurs Macintosh dans les années 1980. Les Mac, ainsi que d'autres appareils prenant en charge le protocole, pouvaient être ajoutés au réseau en les branchant simplement ; toute configuration ultérieure était automatisée. Les adresses réseau étaient automatiquement sélectionnées par chaque appareil à l'aide d'un protocole appelé AppleTalk Address Resolution Protocol (AARP), tandis que chaque machine créait son propre service d'annuaire local à l'aide d'un protocole appelé Name Binding Protocol (NBP). Le NBP comprenait non seulement un nom, mais aussi le type d'appareil et toute information supplémentaire fournie par l'utilisateur, comme son emplacement physique ou sa disponibilité. Les utilisateurs pouvaient rechercher n'importe quel appareil sur le réseau avec l'application Chooser , qui filtrait les noms en fonction du type d'appareil.

Sur les réseaux IP ( Internet Protocol ), la base de données du système de noms de domaine d'un réseau était initialement gérée manuellement par un administrateur réseau. Les efforts visant à automatiser la maintenance de cette base de données ont conduit à l'introduction d'un certain nombre de nouveaux protocoles fournissant des services automatisés, tels que le protocole DHCP ( Dynamic Host Configuration Protocol ).

Les hôtes d'un réseau doivent se voir attribuer des adresses IP qui les identifient de manière unique par rapport aux autres périphériques du même réseau. Sur certains réseaux, une autorité centrale attribue ces adresses à mesure que de nouveaux périphériques sont ajoutés. Des mécanismes ont été introduits pour gérer cette tâche automatiquement, et IPv4 et IPv6 incluent désormais des systèmes d' autoconfiguration d'adresse , qui permettent à un périphérique de déterminer une adresse sûre à utiliser via des mécanismes simples. Pour l'adressage local par lien , IPv4 utilise le bloc spécial 169.254.0.0/16 , tandis que les hôtes IPv6 utilisent le préfixe fe80:: / 10 . Le plus souvent, les adresses sont attribuées par un serveur DHCP , souvent intégré au matériel réseau courant comme les hôtes informatiques ou les routeurs.

La plupart des hôtes IPv4 n'utilisent l'adressage lien-local qu'en dernier recours, lorsqu'un serveur DHCP n'est pas disponible. Un hôte IPv4 utilise par ailleurs son adresse attribuée par DHCP pour toutes les communications, globales ou lien-local. L'une des raisons est que les hôtes IPv4 ne sont pas obligés de prendre en charge plusieurs adresses par interface, même si beaucoup le font. Une autre raison est que tous les hôtes IPv4 n'implémentent pas la résolution de noms distribuée (par exemple, DNS multidiffusion ), de sorte que la découverte de l'adresse lien-local configurée automatiquement d'un autre hôte sur le réseau peut être difficile. La découverte de l'adresse attribuée par DHCP d'un autre hôte nécessite soit une résolution de noms distribuée, soit un serveur DNS monodiffusion avec ces informations ; certains réseaux disposent de serveurs DNS qui sont automatiquement mis à jour avec les informations d'adresse et d'hôte attribuées par DHCP.

Les hôtes IPv6 doivent prendre en charge plusieurs adresses par interface. De plus, chaque hôte IPv6 doit configurer une adresse locale de lien même lorsque des adresses globales sont disponibles. Les hôtes IPv6 peuvent également configurer eux-mêmes des adresses supplémentaires à la réception de messages d'annonce de routeur, éliminant ainsi le besoin d'un serveur DHCP.

Les hôtes IPv4 et IPv6 peuvent générer de manière aléatoire la partie spécifique à l'hôte d'une adresse autoconfigurée. Les hôtes IPv6 combinent généralement un préfixe de 64 bits maximum avec une adresse EUI-64 64 bits dérivée de l' adresse MAC IEEE 48 bits attribuée en usine . L'adresse MAC a l'avantage d'être unique au niveau mondial, une propriété de base de l'EUI-64. La pile de protocoles IPv6 inclut également la détection d'adresses en double pour éviter les conflits avec d'autres hôtes. Dans IPv4, la méthode est appelée autoconfiguration d'adresse locale de lien . Cependant, Microsoft fait référence à cela sous le nom d'adressage IP privé automatique (APIPA) ou de configuration automatique du protocole Internet ( IPAC ). Cette fonctionnalité est prise en charge dans Windows depuis au moins Windows 98. [

Les protocoles Internet utilisent des adresses IP pour les communications, mais celles-ci ne sont pas faciles à utiliser pour les humains. IPv6 en particulier utilise de très longues chaînes de chiffres qui ne sont pas faciles à saisir manuellement. Pour résoudre ce problème, Internet utilise depuis longtemps le DNS, qui permet d'associer des noms lisibles par l'homme à des adresses IP, et inclut un code permettant de rechercher ces noms dans un système de base de données hiérarchique. Les utilisateurs saisissent des noms de domaine, tels que example.org , que le logiciel DNS de l'ordinateur recherche dans les bases de données DNS pour récupérer une adresse IP, puis transmet cette adresse à la pile de protocoles pour les communications ultérieures.

Pour rechercher une adresse à l'aide du DNS, il faut connaître l'adresse IP du serveur DNS. Pour cela, il faut généralement saisir l'adresse d'un serveur connu dans un champ de l'un des appareils du réseau. Dans les premiers systèmes, cette opération était normalement requise sur chaque appareil, mais elle a été reportée d'un niveau supérieur dans la hiérarchie jusqu'aux serveurs DHCP ou aux appareils à large bande comme les modems câblés qui reçoivent ces informations de leur fournisseur d'accès Internet . Cela a réduit les exigences d'administration côté utilisateur et fournit un élément clé de l'accès sans configuration.

Le DNS a été conçu pour fournir des noms uniformes à des groupes de périphériques au sein du même domaine d'administration, tels que example.org , fournis par un service de noms. L'attribution d'une adresse à un périphérique local, par exemple thirdfloorprinter.example.org , nécessite normalement un accès administrateur au serveur DNS et est souvent effectuée manuellement. De plus, les serveurs DNS traditionnels ne sont pas censés corriger automatiquement les changements de configuration. Par exemple, si une imprimante est déplacée d'un étage à un autre, une nouvelle adresse IP peut lui être attribuée par le serveur DHCP local.

Pour répondre au besoin de configuration automatique, Microsoft a mis en œuvre le service de noms NetBIOS , dont fait partie le service de navigation informatique déjà présent dans Microsoft Windows for Workgroups 3.11 dès 1992. Le service de noms NetBIOS ne nécessite aucune configuration sur les réseaux à un seul sous-réseau et peut être utilisé en conjonction avec un serveur WINS ou un serveur DNS Microsoft qui prend en charge l'enregistrement automatique sécurisé des adresses. Ce système a une charge de gestion faible, mais pas nulle, même sur les très grands réseaux d'entreprise. Les protocoles que NetBIOS peut utiliser font partie de la suite de protocoles ouverts Server Message Block (SMB) qui sont également disponibles sur Linux et iOS, bien que Windows prenne généralement en charge une gamme plus large de dialectes qui peuvent être négociés entre les clients Windows qui le prennent en charge. Par exemple, les services de navigation informatique exécutés sur des systèmes d'exploitation serveur ou des versions ultérieures de Windows sont élus comme navigateurs maîtres par rapport à ceux qui n'exécutent pas de système d'exploitation serveur ou qui exécutent des versions plus anciennes de Windows.

En 2000, Bill Manning et Bill Woodcock ont ​​décrit le service de noms de domaine multidiffusion qui a donné naissance aux implémentations d'Apple et de Microsoft. Les deux implémentations sont très similaires. Le DNS multidiffusion (mDNS) d'Apple est publié sous la forme d'une proposition de suivi des normes RFC 6762, tandis que la résolution de noms multidiffusion locale (LLMNR) de Microsoft est publiée sous la forme d' une RFC 4795 informative. LLMNR est inclus dans toutes les versions de Windows à partir de Windows Vista et agit comme une alternative côte à côte pour le service de noms NetBIOS de Microsoft sur IPv4 et comme un remplacement sur IPv6, puisque NetBIOS n'est pas disponible sur IPv6. L'implémentation d'Apple est disponible sous le nom de service Bonjour depuis 2002 dans Mac OS X v10.2. L'implémentation de Bonjour (mDNSResponder) est disponible sous la licence open source Apache 2 et est incluse dans Android Jelly Bean et plus tard sous la même licence.

L'utilisation des services NetBIOS ou LLMNR sous Windows est essentiellement automatique, car l'utilisation des API client DNS standard entraînera l'utilisation de NetBIOS ou LLMNR en fonction du nom résolu (que le nom soit un nom local ou non), de la configuration réseau en vigueur (par exemple, les suffixes DNS en vigueur) et (dans les réseaux d'entreprise) des politiques en vigueur (que LLMNR ou NetBIOS soient désactivés), bien que les développeurs puissent choisir de contourner ces services pour les recherches d'adresses individuelles.

Les protocoles mDNS et LLMNR présentent des différences mineures dans leur approche de la résolution de noms. mDNS permet à un périphérique réseau de choisir un nom de domaine dans l' espace de noms DNS local et de l'annoncer à l'aide d'une adresse IP multidiffusion spéciale. Cela introduit une sémantique spéciale pour le domaine de premier niveau local , qui est considéré comme un problème par certains membres de l'IETF. Le projet LLMNR actuel permet à un périphérique réseau de choisir n'importe quel nom de domaine, ce qui est considéré comme un risque de sécurité par certains membres de l'IETF. mDNS est compatible avec DNS-SD comme décrit dans la section suivante, alors que LLMNR ne l'est pas.

Les services de noms tels que mDNS, LLMNR et autres ne fournissent pas d'informations sur le type de périphérique ou son état. Un utilisateur recherchant une imprimante à proximité, par exemple, pourrait être gêné si l'imprimante porte le nom « Bob ». La découverte de services fournit des informations supplémentaires sur les périphériques. La découverte de services est parfois combinée à un service de noms , comme dans le protocole Name Binding Protocol d'Apple et le protocole NetBIOS de Microsoft .

NetBIOS sur Windows prend en charge les hôtes individuels du réseau pour annoncer des services, tels que les partages de fichiers et les imprimantes. Il prend également en charge, par exemple, une imprimante réseau pour s'annoncer comme hôte partageant un périphérique d'impression et tous les services associés qu'il prend en charge. Cela dépend de la manière dont un périphérique est connecté (directement au réseau ou à l'hôte qui le partage) et des protocoles pris en charge. Cependant, les clients Windows qui s'y connectent peuvent préférer utiliser SSDP ou WSD à l'aide de NetBIOS. NetBIOS est l'un des fournisseurs sur Windows qui implémentent le processus de découverte plus général appelé fonction de découverte qui comprend des fournisseurs intégrés pour PnP, Registry, NetBIOS, SSDP et WSD dont les deux premiers sont uniquement locaux et les trois derniers prennent en charge la découverte des périphériques en réseau. Aucun de ceux-ci ne nécessite de configuration pour être utilisé sur le sous-réseau local. NetBIOS n'a traditionnellement été pris en charge que sur les imprimantes coûteuses destinées à une utilisation en entreprise, bien que certaines imprimantes d'entrée de gamme avec Wi-Fi ou Ethernet le prennent en charge nativement, ce qui permet à l'imprimante d'être utilisée sans configuration même sur des systèmes d'exploitation très anciens.

Web Services Dynamic Discovery ( WS-Discovery ) est une spécification technique qui définit un protocole de découverte multidiffusion pour localiser des services sur un réseau local. Il fonctionne sur le port TCP et UDP 3702 et utilise l'adresse IP multidiffusion 239.255.255.250 . Comme son nom l'indique, la communication réelle entre les nœuds s'effectue à l'aide de normes de services Web, notamment SOAP-over-UDP . Windows le prend en charge sous la forme de Web Services for Devices et de Devices Profile for Web Services . De nombreux appareils, tels que les imprimantes HP et Brother, le prennent en charge.

DNS-SD (DNS Service Discovery) permet aux clients de découvrir une liste nommée d'instances de service et de résoudre ces services en noms d'hôtes à l'aide de requêtes DNS standard. La spécification est compatible avec les logiciels client et serveur DNS monodiffusion existants, mais fonctionne tout aussi bien avec mDNS dans un environnement sans configuration. Chaque instance de service est décrite à l'aide d'un enregistrement DNS SRVet DNS TXT. Un client découvre la liste des instances disponibles pour un type de service donné en interrogeant l'enregistrement DNS PTRdu nom de ce type de service ; le serveur renvoie zéro ou plusieurs noms de la forme <Service>.<Domaine>, chacun correspondant à une paire d'enregistrements SRV/TXT. L'enregistrement SRVrésout le nom de domaine fournissant l'instance, tandis que le TXT peut contenir des paramètres de configuration spécifiques au service. Un client peut ensuite résoudre l'enregistrement A/AAAA pour le nom de domaine et se connecter au service.

Les types de services sont attribués selon le principe du premier arrivé, premier servi. Un registre des types de services était à l'origine géré par DNS-SD.org, mais a depuis été fusionné avec le registre de l'IANA pour les enregistrements DNS SRV.

En 1997, Stuart Cheshire a proposé d'adapter le protocole de liaison de noms d'Apple aux réseaux IP pour remédier au manque de capacité de découverte de services. Cheshire a ensuite rejoint Apple et a rédigé des projets de propositions de l'IETF pour mDNS et la découverte de services basée sur DNS, soutenant la transition d'AppleTalk vers les réseaux IP. En 2002, Apple a annoncé une implémentation des deux protocoles sous le nom de Rendezvous (renommé plus tard Bonjour). Il a été inclus pour la première fois dans Mac OS X 10.2 , remplaçant le protocole de localisation de services (SLP) utilisé dans 10.1 . En 2013, les propositions ont été ratifiées sous les numéros RFC 6762 et RFC 6763.

mDNS utilise des paquets similaires au DNS monodiffusion pour résoudre les noms d'hôtes, sauf qu'ils sont envoyés via une liaison multidiffusion. Chaque hôte écoute sur le port mDNS, 5353, transmis à une adresse multidiffusion connue et résout les demandes d' enregistrement DNS de son nom d'hôte local (par exemple A , AAAA , CNAME ) en son adresse IP. Lorsqu'un client mDNS doit résoudre un nom d'hôte local en une adresse IP, il envoie une demande DNS pour ce nom à l'adresse multidiffusion connue ; l'ordinateur avec l'enregistrement A/AAAA correspondant répond avec son adresse IP. L'adresse multidiffusion mDNS est 224.0.0.251 pour IPv4 et ff02::fb pour l'adressage local par lien IPv6.

Les requêtes DNS Service Discovery, également appelées DNS-SD, peuvent également être envoyées à l'aide de mDNS pour générer un DNS-SD sans configuration. Cela utilise les enregistrements DNS PTR , SRV, TXT pour annoncer les instances de types de services, les noms de domaine pour ces instances et les paramètres de configuration facultatifs pour la connexion à ces instances. Mais les enregistrements SRV peuvent désormais se résoudre en noms de domaine .local , que mDNS peut résoudre en adresses IP locales.

DNS-SD est utilisé par les produits Apple, la plupart des imprimantes réseau, de nombreuses distributions Linux, dont Debian et Ubuntu , et un certain nombre de produits tiers pour divers systèmes d'exploitation. Par exemple, de nombreuses applications réseau OS X écrites par Apple, notamment Safari , iChat et Messages , peuvent utiliser DNS-SD pour localiser les serveurs à proximité et les clients peer-to-peer. Windows 10 inclut la prise en charge de DNS-SD pour les applications écrites à l'aide de JavaScript. Les applications individuelles peuvent inclure leur propre prise en charge dans les anciennes versions du système d'exploitation, de sorte que la plupart des clients de messagerie instantanée et VoIP sous Windows prennent en charge DNS-SD. Certaines distributions Unix , BSD et Linux incluent également DNS-SD. Par exemple, Ubuntu fournit Avahi , une implémentation mDNS/DNS-SD, dans sa distribution de base.

UPnP possède certains composants de protocole dans le but de découvrir des services.

Le protocole SSDP (Simple Service Discovery Protocol ) est un protocole UPnP utilisé dans Windows XP et versions ultérieures. Le SSDP utilise des notifications HTTP qui donnent un URI de type de service et un nom de service unique (USN). Les types de services sont réglementés par le comité directeur Universal Plug and Play. Le SSDP est pris en charge par de nombreux fabricants d'imprimantes, de NAS et d'appareils électroménagers tels que Brother. Il est pris en charge par certaines marques d'équipements réseau et par de nombreux pare-feu SOHO , où les ordinateurs hôtes situés derrière lui peuvent percer des trous pour les applications. Il est également utilisé dans les systèmes PC de cinéma maison pour faciliter l'échange de médias entre les ordinateurs hôtes et le centre multimédia.

Digital Living Network Alliance (DLNA) est une autre suite de normes qui utilise UPnP pour la détection des périphériques en réseau. DLNA est pris en charge par de nombreux fabricants de premier plan produisant des appareils tels que des téléviseurs, des périphériques NAS, etc. DLNA est pris en charge par tous les principaux systèmes d'exploitation. La découverte de services DLNA est superposée sur SSDP.

SLP est pris en charge par les imprimantes réseau de Hewlett-Packard , Novell et Sun Microsystems . SLP est décrit dans les RFC 2608 et RFC 3224 et des implémentations sont disponibles pour Solaris et Linux .

AllJoyn est une pile logicielle open source destinée à une multitude d'appareils, allant des appareils IoT aux ordinateurs de taille standard, pour la découverte et le contrôle des appareils sur les réseaux (Wifi, Ethernet) et autres liaisons (Bluetooth, ZigBee, etc.). Il utilise mDNS et HTTP sur UDP et d'autres protocoles.

La RFC 2608, la norme SLP permettant de déterminer où obtenir des services, a été publiée en juin 1999 par le groupe de travail SVRLOC de l'IETF.

La RFC 3927, une norme permettant de choisir les adresses des éléments en réseau, a été publiée en mars 2005 par le groupe de travail Zeroconf de l'IETF. Le groupe comprenait des personnes d'Apple, Sun et Microsoft.

Le LLMNR a été soumis à l'adoption officielle du groupe de travail DNSEXT de l'IETF, mais n'a pas réussi à obtenir un consensus et a donc été publié en tant que RFC 4795 à titre informatif en janvier 2007.

Suite à l'échec du LLMNR à devenir une norme Internet et étant donné que mDNS/DNS-SD est utilisé beaucoup plus largement que LLMNR, l'IETF a demandé à Apple de soumettre également les spécifications mDNS/DNS-SD pour publication en tant que RFC informatif.

En février 2013, mDNS et DNS-SD ont été publiés sous forme de propositions de normalisation RFC 6762 et RFC 6763.

Étant donné que le mDNS fonctionne selon un modèle de confiance différent de celui du DNS unicast (en faisant confiance à l'ensemble du réseau plutôt qu'à un serveur DNS désigné), il est vulnérable aux attaques d'usurpation d'identité par n'importe quel système au sein du même domaine de diffusion . Comme SNMP et de nombreux autres protocoles de gestion de réseau, il peut également être utilisé par des attaquants pour obtenir rapidement une connaissance détaillée du réseau et de ses machines. Pour cette raison, les applications doivent toujours authentifier et chiffrer le trafic vers les hôtes distants (par exemple via RSA , SSH , etc.) après les avoir découverts et résolus via DNS-SD/mDNS. LLMNR souffre de vulnérabilités similaires.

Bonjour d'Apple, utilise mDNS et DNS Service Discovery. Apple a changé sa technologie zeroconf préférée de SLP à mDNS et DNS-SD entre Mac OS X 10.1 et 10.2 , bien que SLP continue d'être pris en charge par Mac OS X.

Le mDNSResponder d'Apple possède des interfaces pour C et Java et est disponible sur BSD, Apple Mac OS X, Linux, d'autres systèmes d'exploitation basés sur POSIX et MS Windows. Les téléchargements Windows sont disponibles sur le site Web d'Apple.

Avahi est une implémentation Zeroconf pour Linux et BSD . Il implémente IPv4LL , mDNS et DNS-SD. Il fait partie de la plupart des distributions Linux et est installé par défaut sur certaines. S'il est exécuté en conjonction avec nss-mdns, il offre également la résolution du nom d'hôte.

Avahi implémente également des bibliothèques de compatibilité binaire qui émulent Bonjour et l'implémentation historique mDNS Howl, de sorte que les logiciels conçus pour utiliser ces implémentations peuvent également utiliser Avahi via les interfaces d'émulation.

Microsoft Windows CE 5.0 inclut la propre implémentation de LLMNR de Microsoft.

Systemd implémente à la fois mDNS et LLMNR dans systemd-resolved.

Lorsqu'aucun serveur DHCP n'est disponible pour attribuer une adresse IP à un hôte, l'hôte peut sélectionner sa propre adresse locale de lien . En utilisant une adresse locale de lien, les hôtes peuvent communiquer via cette liaison, mais uniquement localement. L'accès à d'autres réseaux et à Internet n'est pas possible. Il existe quelques implémentations d'adresses IPv4 locales de lien disponibles :

• Apple Mac OS et MS Windows prennent en charge les adresses locales depuis Windows 98 et Mac OS 8.5 (tous deux sortis en 1998). Apple a publié son implémentation open source dans le package Darwin bootp.
• Avahi contient une implémentation d'IPv4LL dans l'outil avahi-autoipd.
• IP zéro-conf (zcip)
• BusyBox peut intégrer une implémentation IPv4LL simple.
• Stablebox, un fork de Busybox, propose une implémentation IPv4LL légèrement modifiée nommée llad.
• Zeroconf est un package basé sur Simple IPv4LL, une implémentation plus courte d' Arthur van Hoff .

Les implémentations ci-dessus sont toutes des démons ou des plugins autonomes pour les clients DHCP qui ne traitent que des adresses IP locales. Une autre approche consiste à inclure la prise en charge dans les clients DHCP nouveaux ou existants :

• Elvis Pfützenreuter a écrit un patch pour le client/serveur uDHCP.
• dhcpcd est un client DHCP open source pour Linux et BSD qui inclut la prise en charge d'IPv4LL. Il est inclus en standard dans NetBSD .

Aucune de ces implémentations ne résout les problèmes du noyau tels que la diffusion des réponses ARP ou la fermeture des connexions réseau existantes.