Le RARP (Reverse Address Resolution Protocol) n'est pas vraiment étudié au départ pour résoudre notre problème, mais il est un peu l'ancêtre des 2 autres. Commençons par le commencement, à savoir l'ARP : Address Resolution Protocol. Sur un réseau Ethernet, quand une machine doit envoyer un paquet à une autre, elle doit connaître l'adresse Ethernet de cette dernière. Les adresses Ethernet sont sur 6 octets, du genre 00:80:c0:45:7a:99. Afin d'apprendre cette adresse, l'expéditeur utilise le protocole ARP (en gros, il crie très fort sur le réseau : ``Qui est 192.168.9.1?'' et l'intéressé lui répond ``Moi, 00:05:00:cf:a0:4b''). On a développé plus tard le RARP, qui permet à une machine sans disque dur (ou même avec) qui ne connaît pas son adresse IP, mais qui connaît son adresse Ethernet, de s'autoconfigurer via le réseau avec l'aide d'un serveur.
L'intérêt de ces techniques est d'installer la même configuration à l'octet près sur un ensemble de machine, puis que ces machines puissent se différencier les unes des autres et obtenir les fichiers de configurations qui leur sont propres via le réseau, auprès d'un serveur central.
Traditionnellement, les stations Sun qui doivent booter en ``diskless'' font une requête RARP, puis, connaissant leur adresse IP et celle de la machine qui a répondu à leur requête RARP, elles demandent via le protocole tftp un fichier à cette machine. Ce fichier, très petit (quelques dizaines de ko) va ensuite être exécuté, et appeler un serveur bootparam en RPC (différent de bootp!), afin d'obtenir l'adresse du serveur qui héberge ses fichiers. Ensuite, le noyau va être récupéré depuis ce serveur via le protocole NFS, et être exécuté. L'enfance de l'art, quoi :-).
Pour simplifier un peu les choses, le protocole bootp est apparu. Il combine le RARP et le bootparam, puisqu'il permet à une machine d'apprendre son adresse IP, et éventuellement une foule de paramètres, comme : l'adresse du serveur DNS, du routeur local, le masque de sous-réseau, le serveur qui héberge ses fichiers, le noyau à utiliser, etc. Sur certaines stations DEC et sur les Powermac (par exemple), la machine fait une requête bootp, puis télécharge le noyau via tftp, et le noyau est exécuté directement.
Enfin, le DHCP (Dynamic Host Configuration Protocol) est apparu afin de combler quelques lacunes du bootp. Le DHCP permet de transmettre des paramètres du serveur vers le client, mais aussi du client vers le serveur (exemple : sous MS Winzob configuré pour obtenir une adresse IP en DHCP, l'ordinateur envoie au serveur le nom sous lequel il apparaît dans le voisinage réseau). De plus, le DHCP exploite le concept de ``bail'' (``lease'', en anglais), pour gérer les adresses dynamiques : quand un hôte demande au serveur DHCP de lui fournir une adresse IP, le serveur indique pendant combien de temps cette adresse va être valide. C'est au client de renouveler le bail avant la fin de la période de validité s'il veut conserver son adresse. Les baux peuvent être aussi courts que 15 minutes (pour un banc de test TCP/IP) et aussi longs que plusieurs années (dans une université où le parc ne bouge que tous les ans, aux vacances).
On entend aussi parfois parler de PXE ; le PXE est une méthode de boot reposant entièrement sur le réseau. Ce n'est pas à proprement parler un protocole, puisqu'il utilise le DHCP et le TFTP ; on le trouve sur certaines cartes réseau et sur les PCs ``diskless'', sans lecteur de disquette ni lecteur de CD-ROM.