Network Working Group Bill Croft (Stanford University)
Request for Comments : 951 John Gilmore (Sun Microsystems)
Septembre 1995 Protocole damorage (BOOTP) Table des matires 1 Statut de ce document 3 2 Rsum 3 3 Format des Paquets 4 4 Problme de luf et de la Poule 5 5 Utilisation dARP par le Client 6 6 Comparaison avec RARP 6 7 Traitement du Paquet 7 7.1 Transmission par le Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.2 Stratgie de Retransmission du Client . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.3 Le Serveur Reoit BOOTREQUEST . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.4 Le Serveur/Passerelle Reoit BOOTREPLY . . . . . . . . . . . . . . . . . . . . . . 9 7.5 Rception par le Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8 Amorage au travers de Passerelles 10 9 Exemple de Base de Donnes dun Serveur BOOTP 10 Remerciements 12 Bibliographie 13 1 Statut de ce document Ce RFC suggre un protocole pour la communaut ARPA-Internet, et invite toute discussion et suggestion visant son amlioration. La distribution de ce document est libre. Cette traduction franaise a t eectue par Frdric Delanoy. Vous pouvez le contacter ici. 2 Rsum Ce RFC dcrit un protocole damorage IP/UDP nomm BOOTP, qui permet une machine cliente sans disque dur de dcouvrir sa propre adresse IP, ladresse dun hte serveur, et le nom dun chier charger en mmoire pour excution. On peut se reprsenter lamorage comme une opration se produisant en deux phases. Ce RFC dcrit la premire phase, qui pourrait tre appele dtermination dadresse et slection de chier de dmarrage . Aprs lobtention de cette adresse et de linformation sur le nom de chier, on passe la seconde phase de lamorage o se produit un transfert de chier. Celui-ci utilisera typiquement le protocole TFTP [9], puisquil est escompt que les deux phases rsident dans la PROM du client. Nanmoins, BOOTP pourrait galement fonctionner avec dautres protocoles comme SFTP [3] ou FTP [6]. Nous suggrons que le logiciel de la PROM du client fournisse un moyen deectuer un amorage complet sans intervention de lutilisateur. Cest le type damorage qui se produirait lors dune mise sous tension inattendue. Un mcanisme devrait tre fourni pour que lutilisateur puisse fournir ma- nuellement ladresse et linformation sur le nom de chier ncessaires pour passer outre le protocole BOOTP et entrer directement dans la phase de transfert de chier. Si un moyen de stockage non vola- tile est disponible, nous suggrons dy conserver les rglages par dfaut et de passer outre le protocole BOOTP moins que ces rglages ne provoquent lchec de la phase de transfert de chier. Sil ny a pas dinformation cache 1 disponible, lamorage devrait revenir la phase 1 et utiliser BOOTP. Voici un bref aperu du protocole : 1. Un seul change de paquets est eectu. Des temporisateurs sont utiliss pour la retransmis- sion jusqu la rception dune rponse. La mme composition de paquet est utilise dans les deux directions. Des champs de longueur xe un maximum raisonnable sont utiliss pour simplier la dnition de structure et lanalyse syntaxique. 2. Un champ ' opcode ' (code opratoire) existe et comprend deux valeurs. Le client diuse un pa- quet ' bootrequest ' (requte damorage). Le serveur rpond ensuite avec un paquer ' bootreply ' (r- ponse damorage). La requte damorage contient ladresse matrielle du client et son adresse IP, sil la connat. 3. La requte peut optionnellement contenir le nom du serveur partir duquel le client veut obtenir une rponse. Cest prvu an que le client puisse exiger lamorage depuis un hte spcique (p.ex. sil existe de multiples versions du mme chier de dmarrage ou si le serveur est situ dans un rseau/domaine loign. Le client ne doit pas soccuper de services dannuaire/de noms de domaine ; au lieu de cela, la fonction est place sur le serveur BOOTP. 4. La requte peut optionnellement contenir le nom de chier gnrique partir duquel d- marrer. Par exemple, ' unix ' ou ' ethertip '. Quand le serveur envoie la rponse damorage, il 1 place en mmoire cache 3 remplace la valeur de ce champ par le nom de chemin compltement quali du chier de dmarrage appropri. Pour dterminer ce nom, le serveur peut consulter sa propre base de don- nes mettant en corrlation adresse et requte de nom de chier du client avec un chier de dmarrage particulier personnalis pour ce client particulier. Si le nom de chier de la requte damorage est une chane de caractres vide, alors le serveur renvoie un champ nom de chier indiquant que le chier par dfaut doit tre charg pour ce client. 5. Dans le cas de clients qui ne connaissent pas leur adresse IP, le serveur doit galement disposer dune base de donnes associant adresses matrielles et adresses IP. Ladresse IP du client est ensuite place dans un champ de la requte damorage. 6. Certaines topologies de rseau (comme celle de Stanford) peuvent tre telles quil nexiste pas de serveur TFTP directement raccord sur un cble physique donn (p.ex. quand tous les htes et passerelles prsents sur un cble ne possdent pas de disque dur). En cooprant avec des passerelles voisines, BOOTP peut permettre aux clients de dmarrer depuis des serveurs situs plusieurs sauts, au travers de ces passerelles. Voyez la section Amorage au travers de Passerelles plus bas. Cette partie du protocole ne requiert aucune action spciale de la part du client. Limplmentation est optionnelle et requiert une petite quantit de code supplmentaire dans les passerelles et serveurs. 3 Format des Paquets Tous les nombres prsents sont dcimaux, moins dune indication contraire. Le paquet BOOTP est encapsul dans un datagramme UDP [7] IP [8] standard. Pour simplier, on suppose que le pa- quet BOOTP nest jamais fragment. Tous les champs numriques prsents dans l ordre des octets standard , c.--d. que les bits dordre suprieur (de poids fort) sont envoys en premier. Dans len-tte IP dune requte damorage, le client fournit sa propre adresse IP source sil la connat, ou zro sinon. Quand ladresse du serveur est inconnue, ladresse IP destination sera ladresse de diusion 255.255.255.255 (broadcast). Cette adresse signie diuser sur le cble local (je ne connais pas mon adresse rseau) [4]. Len-tte UDP contient les numros de port source et destination. Le protocole BOOTP utilise deux numros de ports rservs, client BOOTP (n o de port 68) et serveur BOOTP (n o de port 67). Le client envoie ses requtes en utilisant serveur BOOTP comme port de destination, habituel- lement ladresse de diusion. Le serveur envoie ses rponses en utilisant client BOOTP comme port de destination ; en fonction des facilits oertes par le noyau ou le pilote du serveur, cela peut tre envoy ou non ladresse de diusion (voir les explication plus loin dans la section intitule Pro- blme de lOeuf et de la Poule plus bas). La raison pour laquelle deux ports rservs sont utiliss, est que lon veut viter de rveiller et de programmer les dmons serveurs BOOTP, quand une rponse damorage doit tre diuse vers un client. Puisque le serveur et les autres htes ncouteront pas le port client BOOTP , de telles diusions entrantes seront ltres au niveau du noyau. Nous ne pourrions pas simplement permettre au client de choisir un numro de port alatoire pour le champ de port source UDP, puisque tant donn que la rponse du serveur peut tre diuse, un numro de port choisi alatoirement pourrait troubler les autres htes qui sont justement en train dcouter sur ce port. Le champ de longueur UDP est x la somme des longueurs des parties UDP et BOOTP du paquet. Le champ de total de contrle UDP peut tre x zro par le client (ou le serveur) sil le 4 souhaite, pour viter cette surcharge supplmentaire dans une implmentation PROM. Dans la section Traitement des Paquets plus bas, lexpression [Total de contrle UDP] est utilise chaque fois que le total de contrle peut tre vri ou calcul. CHAMP OCTETS DESCRIPTION op 1 Type de message/code opratoire du paquet 1 = BOOTREQUEST (requte damorage) 2 = BOOTREPLY (rponse damorage) htype 1 Type dadresse matrielle Voyez la section ARP dans le RFC "Assigned Numbers" 1 = 10mb ethernet hlen 1 Longueur de ladresse matrielle (p.ex. 6 pour ethernet 10 Mbps). hops 1 Fix par le client zro ; peut tre utilis par des passerelles lors de damorages au travers de passerelles. xid 4 ID de transaction : nombre alatoire utilis pour associer cette requte de dmarrage avec la rponse quelle gnre. secs 2 Rempli par le client, secondes coules depuis le dbut de sa tentative damorage. Inutilis ciaddr 4 Adresse IP du client ; remplie par le client dans la requte damorage si elle est connue yiaddr 4 Votre adresse IP (client) ; remplie par le serveur si le client ne connat pas sa propre adresse (si ciaddr valait 0). siaddr 4 Adresse IP du serveur ; renvoye dans rponse damorage par le serveur giaddr 4 Adresse IP de la passerelle ; utilise dans lamorage au travers de passerelles optionnel. chaddr 16 Adresse matrielle du client ; remplie par le client. sname 64 Nom de lhte serveur, chane de caractres termine par un caractre NUL. le 128 Nom du chier de dmarrage, chane de caractres termine par un caractre NUL; nom gnrique ou null dans la requte damorage, nom de chemin de rpertoire compltement quali dans la rponse damorage. vend 64 zone optionnelle spcique au vendeur pourrait p.ex. tre le type/numro de srie du matriel dans la requte, ou une capa- cit /handle 2 du systme de chiers distant lors de la rponse. Cette information peut tre mise de ct pour utilisation lors dune troisime phase damor- age ou par le noyau. 4 Problme de luf et de la Poule Comment le serveur peut-il envoyer un datagramme IP au client, si celui-ci ne connat pas (encore) sa propre adresse IP ? chaque fois quune rponse damorage est envoye, la machine mettrice eectue les oprations suivantes : 1. Si le client connat sa propre adresse IP (le champ ciaddr est dirent de zro), alors le paquet ne peut tre envoy comme un paquet normal, puisque le client rpondra aux requtes ARP [5] ; 2. Si le client ne connat pas encore sa propre adresse IP (ciaddr nul), alors le client ne peut rpondre aux requtes ARP transmises lors de la rponse damorage. Il y a deux options : 2 NdT : dicilement traduisible : manipulateur, gestionnaire 5 (a) Si le transmetteur dispose des points de raccordement (hooks) un pilote ou au noyau ncessaires pour construire manuellement une entre dans le cache dadresses ARP, alors il peut remplir une entre en utilisant les champs ' chaddr ' et ' yiaddr '. Bien sr, cette entre devrait faire lobjet dune temporisation, comme toute autre entre cre par le code ARP normal lui-mme. Le transmetteur de la rponse damorage peut ensuite envoyer simplement la rponse damorage ladresse IP du client. UNIX (BSD 4.2) dispose de cette capacit. (b) Si le transmetteur ne dispose pas de ces points de raccordement au noyau, il peut simple- ment envoyer la rponse damorage ladresse IP de diusion sur linterface approprie. Cela ne reprsente quune seule diusion supplmentaire par rapport au cas prcdent. 5 Utilisation dARP par le Client La PROM du client doit contenir une implmentation simple dARP, le cache dadresses pouvant p.ex. ne disposer que dune seule entre. Cela permettra un amorage utilisant uniquement la seconde phase (TFTP) quand le client connat les adresse IP et chier de dmarrage. chaque fois que le client sattend recevoir une rponse TFTP ou BOOTP, il devrait tre prpar rpondre une requte ARP pour sa propre association adresse IP/adresse matrielle (si elle est connue). Puisque la rponse damorage contiendra (dans lencapsulation matrielle) ladresse source ma- trielle du serveur/de la passerelle, le client PEUT viter denvoyer une requte ARP pour obtenir ladresse IP du serveur/passerelle utiliser dans la phase TFTP suivante. Nanmoins, cela ne devrait tre trait que comme un cas spcial, car il est dsirable de toujours permettre un amorage utilisant uniquement la seconde phase comme dcrit plus haut. 6 Comparaison avec RARP Un protocole plus ancien, le Reverse Address Resolution Protocol (protocole de rsolution dadresse inverse, RARP) [1], a t propos pour permettre un client de dterminer son adresse IP, connaissant son adresse matrielle. Nanmoins, RARP avait linconvnient dtre un protocole de la couche liai- son de donnes (non bas sur IP/UDP). Cela signie que RARP ne pouvait tre implment que sur les htes ayant subi des modications spciales au niveau noyau ou pilote pour accder aux paquets bruts . Puisquil existe beaucoup de noyaux rseaux actuellement, pour lesquels chaque source est maintenue par des organisations direntes, un protocole damorage qui ne requiert pas de modi- cations au noyau jouit dun avantage dcisif. BOOTP fournit cette fonction de recherche adresse IP vers adresse matrielle, en plus des autres fonctionnalits utiles dcrites dans les sections prsentes plus haut. 6 7 Traitement du Paquet 7.1 Transmission par le Client Avant de crer le paquet pour la premire fois, cest une bonne ide de nettoyer entirement le tampon de paquets en le remplissant avec des zros ; cela placera tous les champs dans leur tat par dfaut. Le client cre ensuite un paquet avec les champs suivants. Ladresse IP destination est xe 255.255.255.255 (ladresse de diusion) ou ladresse IP du serveur (si elle est connue). Ladresse IP source et ' ciaddr ' sont xs ladresse IP du client si elle est connue, ou 0 sinon. Len-tte UDP est dni avec la longueur adquate ; port source = ' client BOOTP ', port destination = ' serveur BOOTP'. ' op ' est x ' 1 ', c.--d. BOOTREQUEST. ' htype ' est x au type dadresse matrielle comme aect dans la section ARP du RFC "Assigned Numbers". ' hlen ' est x la longueur de ladresse matrielle, p.ex. ' 6 ' pour ethernet 10 Mbps. ' xid ' est x un id de transaction alatoire . ' secs ' est x au nombre de secondes qui se sont coules depuis que le client commenc dmarrer. Cela permettra aux serveurs de savoir depuis combien de temps un client essaie de samorcer. Quand le nombre devient grand, certains serveurs peuvent devenir plus compatissants envers un client quils ne servent normalement pas. Si un client na pas dhorloge adquate, il pourrait construire une estimation grossire en utilisant un temporisateur sous forme de boucle. Ou bien il pourrait choisir de simplement envoyer ce champ avec toujours la mme valeur xe, disons 100 secondes par exemple. Si le client connat son adresse IP, ' ciaddr ' (et ladresse IP source) sont xs cette valeur. ' chaddr ' est rempli par ladresse matrielle du client. Si le client veut restreindre lamorage un nom de serveur particulier, il peut placer une chane de caractre termine par un caractre NUL dans ' sname '. Le nom utilis devrait tre nimporte lequel des noms ou surnoms permis pour lhte dsir. Le client a plusieurs possibilits pour remplir le nom de champ ' le ' (chier). Sil est laiss vide, la signication est Je veux dmarrer partir du chier par dfaut pour ma machine . Un nom de chier vide peut galement signier Je ne mintresse qu la dcouverte des adresses IP des client/serveur/passerelle, je ne me soucie pas des noms de chiers . Le champ peut galement tre un nom gnrique comme ' unix ' ou ' gateway ' (passerelle) ; cela signie amore le programme nomm congur pour ma machine . Finalement, le champ peut tre un nom de chemin de rpertoire compltement quali. Le champ ' vend ' peut tre rempli par le client avec des chanes ou structures spciques au ven- deur. Le type/numro de srie du matriel peut par exemple y tre plac. Nanmoins, le fonctionne- ment du serveur BOOTP ne devrait pas dpendre de lexistence de cette information. Si le champ ' vend ' est utilis, il est recommand dy placer un nombre magique de 4 octets comme premier lment. Cela permet un serveur de dterminer quel type dinformation il voit dans ce champ. Les nombres peuvent tre aects en utilisant le processus de nombre magique habituel vous en prenez un et il est magique. Des nombres magiques dirents pourraient tre utiliss lors des rponses damorage et lors des requtes damorage pour permettre au client dentreprendre des actions spciales avec linformation de rponse. [Total de contrle UDP] 7 7.2 Stratgie de Retransmission du Client Si aucune rponse nest reue durant une certaine priode de temps, le client devrait retransmettre la requte. Lintervalle de temps doit tre choisi prudemment an de ne pas inonder le rseau. R- chissez au cas dun cble supportant 100 machines qui viennent de redmarrer aprs une coupure de courant. Le simple fait de retransmettre la requte toutes les quatre secondes inondera le rseau. Comme stratgie possible, vous pourriez envisager la mthode appele exponentiel binaire 3 , semblable celle utilise par ethernet lors des collisions 4 . Ainsi, par exemple, si le premier paquet arrivait lheure 0:00, le deuxime serait l :04, ensuite :08, :16, :32 et enn :64. Vous devriez galement rendre chaque temps alatoire ; cela se ferait de faon similaire la spcication ethernet en dmarrant avec un masque de bits et en lassociant via un ET binaire avec un nombre alatoire pour obtenir la premire transmission. chaque transmission russie, le masque est incrment dune longueur de 1 bit. Cela double le dlai moyen entre chaque transmission. Aprs que le dlai de transmission moyen ait atteint environ 60 secondes, il ne devrait plus tre augment, mais toujours tre alatoire. Avant chaque retransmission, le client devrait mettre jour le champ ' secs '. [Total de contrle UDP] 7.3 Le Serveur Reoit BOOTREQUEST [Total de contrle UDP] Si le port UDP destination be correspond pas au port ' serveur BOOTP', jeter le paquet. Si le champ de nom du serveur (sname) est vide (aucun serveur particulier spci), ou si ' sname ' est spci et correspond notre nom ou surnom, alors continuer le traitement du paquet. Si le champ sname est spci, mais ne vaut pas us , alors il y a plusieurs possibilits : Vous pouvez choisir de simplement jeter ce paquet. Si un recherche de nom sur sname montre quil est sur ce mme cble, jeter le paquet. Si sname est situ dans un rseau dirent, vous pouvez choisir de faire suivre le paquet cette adresse. Si cest le cas, vriez le champ ' giaddr ' (adresse de passerelle). Si ' giaddr ' est nul, remplissez-le avec mon adresse ou avec ladresse dune passerelle qui peut tre utilise pour aller dans ce rseau. Ensuite, faites suivre le paquet. Si ladresse IP du client (ciaddr) est zro, alors le client ne connat pas sa propre adresse IP. Essayez de rechercher ladresse matrielle du client (chaddr, hlen, htype) dans notre base de donnes. Si aucune correspondance nest trouve, jetez le paquet. Sinon, nous avons maintenant une adresse IP pour ce client ; utilisez-la pour remplir le champ ' yiaddr ' (votre adresse IP). Nous vrions maintenant le champ de nom du chier de dmarrage (le). Le champ sera vide si le client ne sintresse pas aux noms de chiers, ou dsire utiliser le chier de dmarrage par dfaut. Si le champ nest pas vide, il est utilis en tant que cl de recherche dans une base de donnes, comme lest ladresse IP du client. Sil y a un chier par dfaut ou un chier gnrique (ventuellement index par ladresse du client) ou un nom de chemin compltement spci qui correspond, alors remplacez le champ ' le ' par le nom de chemin compltement spci du chier de dmarrage slectionn. Si 3 exponential backo 4 attente entre 0 et i -1 units de temps pour mettre aprs la i me collision 8 le champ nest pas vide et quaucune correspondance nest trouve, alors le client demande un chier que nous navons pas ; jetez le paquet, quelque autre serveur BOOTP pourrait en disposer. Le champ de donnes spcique au vendeur ' vend ' devrait prsent tre vri et, si un type de donnes reconnu est spci, des actions spciques au client devraient tre entreprises, et une rponse devrait tre place dans le champ de donnes ' vend ' du paquet rponse. Par exemple, une station de travail cliente pourrait fournir une cl dauthentication et recevoir du serveur un moyen daccs des chiers distants, ou un jeu doptions de conguration, qui peuvent tre passes au systme dexploitation qui va tre lanc sous peu. Placez mon adresse IP (serveur) dans le champ ' siaddr '. Fixez le champ ' op ' BOOTREPLY. Le port UDP destination est x ' client BOOTP'. Si ladresse du client (' ciaddr ') est non nulle, envoyez- y le paquet ; sinon, si ladresse de passerelle ' giaddr ' est non nulle, xez le port UDP destination ' serveur BOOTP' et envoyez le paquet ' giaddr ' ; sinon, le client est prsent sur lun de nos cbles mais ne connat pas encore sa propre adresse IP utilisez lune des mthodes dcrites dans la section Problme de lOeuf et de la Poule plus haut pour lenvoyer au client. Si vous le faites et quil y a de multiples interfaces sur cet hte, utilisez le champ ' yiaddr ' (votre adresse IP) pour trouver sur quel rseau (cble/interface) envoyer le paquet. [Total de contrle UDP] 7.4 Le Serveur/Passerelle Reoit BOOTREPLY [Total de contrle UDP] Si ' yiaddr ' (votre adresse IP [celle du client]) se rfre lun de nos cbles, utilisez lune des mthodes dcrite dans la section 4 plus haut pour le propager vers le client. Assurez-vous de lenvoyer vers le port UDP destination ' client BOOTP' 7.5 Rception par le Client Noubliez pas de traiter les requtes ARP pour ma propre adresse IP (si je la connais). [Total de contrle UDP] Le client devrait liminer les paquets qui ne sont pas adresss (IP/UDP) au port damorage ne sont pas des rponses damorage ne correspondent pas mon adresse IP (si je la connais) ou mon adresse matrielle ne correspondent pas mon id de transaction. Autrement, nous avons reu une rponse couronne de succs. ' yiaddr ' contiendra mon adresse IP, si je ne la connaissais pas avant. ' le ' est le nom de chier de la ' read request ' (requte de lecture) TFTP. Ladresse du serveur est dans ' siaddr '. Si ' giaddr ' (adresse de passerelle) est non nulle, alors les paquets devraient y tre achemins en premier lieu, an darriver au serveur. 8 Amorage au travers de Passerelles Cette partie du protocole est optionnelle et requiert du code supplmentaire pour la coopration entre passerelles et serveurs, mais il permet un amorage par lintermdiaire de passerelles. Cest principalement utile quand les passerelles sont des machines sans disque dur. Les passerelles conte- nant des disques dur (p.ex. une machine UNIX faisant oce de passerelle), pourraient galement faire tourner leurs propres serveurs BOOTP/TFTP. 9 Les passerelles coutant les requtes damorage diuses peuvent dcider de rediriger ou de re- diuser ces requtes lorsque cela est appropri . Par exemple, la passerelle pourrait disposer, dans ses tables de conguration, dune liste dautres rseaux ou htes devant recevoir une copie de toute requte damorage diuse. Mme si un champ ' hops ' existe, cest une mauvaise ide de rediu- ser globalement les requtes, car il y a de grandes chances que des boucles dues la diusion se produisent. La propagation pourrait commencer immdiatement, ou attendre que le champ ' secs ' (secondes coules depuis que le client essaye de dmarrer) dpasse un certain seuil. Si une passerelle dcide de propager la requte, elle devrait examiner la valeur du champ ' giaddr ' (adresse IP de la passerelle). Si elle est nulle, elle devrait placer sa propre adresse IP (sur le cble de rception) dans ce champ. Elle peut galement utiliser le champ ' hops ' pour contrler optionnellement quelle distance le paquet est propag. Hops devrait tre incrment lors de chaque redirection. Par exemple, si hops dpasse ' 3 ', le paquet devrait probablement tre limin. [Total de contrle UDP] Nous recommandons de placer cette fonction de redirection spciale dans les passerelles. Mais cela ne doit pas forcment tre le cas. Pour autant quexiste un quelconque agent de redirection BOOTP sur le rseau comprenant le client en phase damorage, lagent peut eectuer la redirection lorsque cela est appropri. Ainsi, ce service peut tre ou pas situ sur la passerelle. Au cas o un agent de redirection nest pas situ dans la passerelle, lagent pourrait spargner un peu de peine en plaant ladresse de diusion de linterface recevant la requte damorage dans le champ ' giaddr '. Ainsi, la requte serait redirige en utilisant des passerelles normales, nimpliquant pas dagent de redirection. Bien sr, le dsavantage de cette situation est que vous perdez la possibilit dutiliser la mthode non-diuse 5 de renvoi de la rponse, causant une surcharge supplmentaire pour chaque hte sur le cble du client. 9 Exemple de Base de Donnes dun Serveur BOOTP des ns de suggestion, nous prsentons ici un exemple de base de donnes constitue dun chier texte que le programme serveur BOOTP pourrait utiliser. La base de donnes possde deux sections, dlimites par une ligne contenant un signe % en colonne 1. La premire section contient un rpertoire par dfaut et des associations entre noms gnriques et rpertoires/noms de chemin. Le premier nom gnrique dans cette section est le chier par dfaut que vous obtenez quand la requte damorage contient un champ ' le ' vide. La seconde section convertit une adresse/un type dadresse matrielle en adresse IP. Vous pou- vez optionnellement surcharger le nom gnrique par dfaut en fournissant un nom gnrique spci- que une adresse IP. Un lment ' suxe ' est galement optionnel ; sil est fourni, tout nomgnrique spci par le client sera accd en suxant au pralable ' suxe ' au ' nomDeChemin ' appropri ce nom gnrique. Si ce chier nest pas trouv, alors on cherchera le simple ' nomDeChemin '. Cette option ' suxe ' permet deectuer un tas de rglages gnriques personnels en un minimum deorts. Ci-dessous, le format gnral est prsent ; les champs sont dlimits par un ou plusieurs espaces ou tabulations ; les champs vides de queue peuvent tre omis ; les lignes blanches et celles commenant par ' # ' sont ignores. 5 cfr section 4 10 # ligne de commentaire rpertoirePersonnel nomGnrique1 nomDeChemin1 nomGnrique2 nomDeChemin2 ... % fin des noms gnriques, dbut des conversions dadresses nomHte1 typeMatriel adresseMatrielle1 adresseIP1 nomGnrique suffixe nomHte2 typeMatriel adresseMatrielle2 adresseIP2 nomGnrique suffixe ... Voici un exemple spcique. Notez que le nombre ' hardwaretype ' est le mme que celui fourni dans la section ARP du RFC ' Assigned Numbers '. Les nombres ' hardwaretype ' et ' ipaddr ' sont spcis en dcimal ; ' hardwareaddr ' est en hexadcimal. # dernire mise jour par smith /usr/boot vmunix vmunix tip ethertip watch /usr/diag/etherwatch gate gate. % fin des noms gnriques, dbut des conversions dadresses hamilton 1 02.60.8c.06.34.98 36.19.0.5 burr 1 02.60.8c.34.11.78 36.44.0.12 101-gateway 1 02.60.8c.23.ab.35 36.44.0.32 gate 101 mjh-gateway 1 02.60.8c.12.32.bc 36.42.0.64 gate mjh welch-tipa 1 02.60.8c.22.65.32 36.47.0.14 tip welch-tipb 1 02.60.8c.12.15.c8 36.46.0.12 tip Dans lexemple ci-dessus, si ' mjh-gateway ' eectue un amorage par dfaut, il ira chercher le chier ' /usr/boot/gate.mjh. 11 Remerciements Ross Finlayson (et. al.) a produit deux RFC plus anciens discutant de lamorage via TFTP [2] en utilisant RARP [1]. Nous voudrions galement remercier Noel Chiappa, Bob Lyon, Je Mogul, Mark Lewis et David Plummer pour les travaux prcdents et commentaires quils nous ont fournis. 12 Bibliographie [1] Ross Frxix.sox, Timothy Mxxx, Jerey Mooti, Marvin Tnrrmra, A Reverse Address Resolution Protocol, RFC 903, NIC, Juin 1984. [2] Ross Frxix.sox, Bootstrap Loading using TFTP, RFC 906, NIC, juin 1984. [3] Mark Lorroa, Simple File Transfer Protocol, RFC 913, NIC, septembre 1984. [4] Jerey Mooti, Broadcasting Internet Packets, RFC 919, NIC, octobre 1984. [5] David Pitmmra, An Ethernet Address Resolution Protocol, RFC 826, NIC, septembre 1982. [6] Jon Posrri, File Transfer Protocol, RFC 765, NIC, juin 1980. [7] Jon Posrri, User Datagram Protocol, RFC 768, NIC, aot 1980. [8] Jon Posrri, Internet Protocol, RFC 791, NIC, septembre 1981. [9] K. R. Soiirxs, Noel Cnrxrrx, The TFTP Protocol, RFC 783, NIC, juin 1981. 13