Résumé

  • RFC 1931 autorisait plusieurs serveurs Dynamic RARP pour résister aux pannes, mais imposait à tous les serveurs d’un segment de consulter la même autorité logique d’adressage.
  • Cette autorité ne suffisait pas à établir la réalité : une adresse déclarée libre pouvait déjà être utilisée, d’où une vérification ARP ou ICMP avant attribution.
  • Publié en avril 1996 comme document Informational, aujourd’hui classé Legacy, le texte consignait un mécanisme employé sur certaines plates-formes Sun dès 1988 ; il ne normalisait ni l’autorité sous-jacente ni une filiation causale vers DHCP.

Ce que le silence ne disait pas

Le RARP défini par RFC 903 répondait à un besoin de démarrage : une machine connaissait son adresse matérielle mais ignorait son adresse de protocole. Elle diffusait une requête, et un ou plusieurs serveurs disposant d’une correspondance pouvaient répondre. Aucun paquet négatif n’était prévu, car l’ignorance d’un serveur ne préjugeait pas du savoir d’un autre.

Ce choix rendait pourtant l’absence de réponse indéchiffrable. Le paquet avait-il été perdu ? Le serveur compétent était-il arrêté ? La machine était-elle inconnue, branchée sur le mauvais segment, ou privée de tout serveur ? La retransmission avec temporisation exponentielle entretenait l’espoir sans fournir de diagnostic final.

L’installation automatique n’abolissait pas non plus le travail administratif. Le réseau IP et le système de noms devaient exister avant le branchement. Obtenir une adresse ne signifiait ni enregistrer un nom, ni recevoir des ressources d’amorçage, ni installer des clés ou un mot de passe initial.

RFC 1931 ajouta à ce dialogue trois opérations : une demande DRARP, une réponse temporaire et une erreur. Lorsqu’une correspondance permanente existait, le serveur renvoyait la réponse RARP ordinaire. Sinon, il pouvait créer une liaison temporaire ou annoncer explicitement une restriction de politique, l’épuisement du stock, l’indisponibilité de l’autorité, un déplacement vers le mauvais segment ou un échec non expliqué.

Le document précise son propre périmètre. La notice actuelle du RFC Editor le classe Informational dans le flux Legacy et rappelle qu’il ne définit aucune norme Internet. Certaines plates-formes Sun Microsystems utilisaient DRARP depuis 1988 ; elles n’étaient plus vendues lors de la publication, en avril 1996. DHCP avait déjà repris une partie de la fonction. Cette chronologie fait du texte un relevé historique, non un projet de succession.

La réponse était distribuée, la décision ne l’était pas

Plusieurs serveurs pouvaient entendre la même diffusion. RFC 1931 exigeait alors que leurs réponses soient identiques, hormis les champs propres à l’émetteur. Une divergence constituait une erreur de protocole. La règle transforme plusieurs processus en façades d’un seul service logique.

Un serveur par segment limitait le coût d’une partition ; plusieurs serveurs réduisaient la dépendance à une machine ou à un câble. Tous devaient cependant communiquer avec la même autorité d’adressage. Dans l’implémentation décrite, NIS et un service RPC centralisé nommé IPalloc tenaient ce registre. Des acteurs autorisés, notamment administrateurs et serveurs DRARP, pouvaient le modifier. Le RFC n’a ni normalisé ce protocole d’autorité ni résolu sa sécurité.

L’autorité gérait les liaisons permanentes, les liaisons temporaires et le stock disponible. Elle devait chercher, créer, supprimer et purger, arbitrer les demandes concurrentes et contrôler les droits de mutation. Son unicité était logique, pas nécessairement matérielle. Le texte envisageait un partitionnement, mais au prix d’une grande complexité technique et administrative.

Cette nuance évite un raccourci moderne : un groupe de serveurs ne décentralise pas la décision par sa seule multiplicité. Il peut répliquer une bonne décision, mais aussi propager avec une remarquable disponibilité une décision fausse.

Un registre cohérent peut être périmé

Le passage le plus lucide de RFC 1931 concerne les adresses marquées disponibles alors qu’une machine les utilise déjà. Le registre administratif n’était pas confondu avec l’état du câble. Avant d’attribuer, l’implémentation pouvait sonder le réseau par ARP ou ICMP Echo.

ARP, dans RFC 826, distribue à la demande des correspondances entre adresses de protocole et adresses matérielles. Une réponse constitue un indice local et daté d’utilisation. Elle ne prouve ni le propriétaire, ni l’autorisation, ni l’unicité future. Une absence de réponse n’est pas davantage un certificat perpétuel de vacance.

Il faut donc conserver trois énoncés distincts : l’identifiant matériel présenté, la liaison reconnue par l’autorité et l’observation faite sur un segment à un instant donné. Le déplacement d’une machine vers un autre segment nécessitait des autorités identiques ou communicantes, ainsi qu’un identifiant matériel d’une portée suffisamment large. Même dans ce cas, l’identifiant ne disait rien de l’identité humaine de son porteur.

Les serveurs pouvaient aussi écouter les annonces de leurs pairs et signaler un répondant apparemment non coordonné avant de passer en mode restreint. Aucun protocole d’arbitrage entre serveurs n’était défini. Détecter un écart ne donnait pas le pouvoir de juger qui était l’intrus ; l’autorité et l’administration restaient nécessaires.

Le temps de cache n’était pas une preuve de réussite

Une liaison temporaire devait survivre jusqu’à la fin de l’installation et à la propagation des enregistrements, y compris pendant une panne brève. Le texte rapporte qu’une heure avait suffi dans l’implémentation initiale. Il ne promulgue pas une durée universelle. L’expiration permet de reprendre une ressource rare ; elle ne certifie pas que la machine a achevé sa configuration.

DHCP rendit plus tard d’autres transitions explicites. RFC 1541 organisait plusieurs offres, le choix du client, l’identifiant du serveur et la durée du bail. RFC 2131 affina cette machine d’état et permit au client de refuser une offre lorsqu’un contrôle local révélait un conflit. La comparaison éclaire les choix d’architecture ; elle n’établit pas que DRARP causa DHCP.

À une autre échelle, RFC 3927 autorisa la sélection et la défense d’une adresse IPv4 link-local après sondage. Cette adresse n’est pas routable et ne fonde pas une identité durable. RFC 5227 généralisa la détection de conflits IPv4 par sondes et annonces ARP. La preuve reste locale, limitée dans le temps et vulnérable aux partitions ou aux répondants malveillants.

Trois couches, trois pouvoirs

La grille de Running-Code Primacy de Heng Lu aide à lire cette histoire. Le registre possède une force symbolique de coordination ; le trafic réel peut néanmoins le contredire. Soumettre l’attribution à une sonde ne supprime pas la règle administrative : cela empêche la règle de devenir action sans rencontrer le réel.

Minimum Initial Specification suggère de fixer strictement le petit noyau commun : réponses cohérentes, erreurs distinguables, état temporaire conservé jusqu’à la convergence de ses dépendances. NIS, RPC, durée de cache et politique locale peuvent rester des décisions remplaçables.

La séparation des couches de réalité complète le tableau. Un registre coordonne, une réponse configure, une sonde réfute. RFC 1931 n’a pas pris plusieurs machines pour plusieurs autorités ; plus remarquable encore, il n’a pas pris une autorité cohérente pour la réalité entière.

Sources

  1. RFC 1931 — Dynamic RARP Extensions for Automatic Network Address Acquisition
  2. RFC Editor — notice actuelle de RFC 1931
  3. RFC 903 — A Reverse Address Resolution Protocol
  4. RFC 826 — An Ethernet Address Resolution Protocol
  5. RFC 1541 — Dynamic Host Configuration Protocol
  6. RFC 2131 — Dynamic Host Configuration Protocol
  7. RFC 3927 — Dynamic Configuration of IPv4 Link-Local Addresses
  8. RFC 5227 — IPv4 Address Conflict Detection
  9. Heng Lu — Running-Code Primacy
  10. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  11. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile