RFC 826 - Protocollo di risoluzione degli indirizzi Ethernet
An Ethernet Address Resolution Protocol
Sottotitolo: Conversione degli indirizzi dei protocolli di rete in indirizzi Ethernet a 48 bit per la trasmissione su hardware Ethernet
Autore: David C. Plummer (DCP@MIT-MC)
Data di pubblicazione: Novembre 1982
Stato: Protocollo standard (Standard)
Sommario (Abstract)
L'implementazione del protocollo P sull'host mittente S decide, attraverso il meccanismo di routing del protocollo P, che vuole trasmettere a un host di destinazione T situato da qualche parte su un cavo Ethernet 10Mbit connesso. Per trasmettere effettivamente il pacchetto Ethernet (Ethernet Packet), deve essere generato un indirizzo Ethernet a 48 bit (Ethernet Address). Gli indirizzi degli host all'interno del protocollo P non sono sempre compatibili con l'indirizzo Ethernet corrispondente (lunghezze o valori diversi). Il protocollo presentato qui consente la distribuzione dinamica delle informazioni necessarie per costruire tabelle per tradurre un indirizzo A nello spazio degli indirizzi del protocollo P in un indirizzo Ethernet a 48 bit.
Sono state effettuate generalizzazioni che consentono l'uso del protocollo su hardware diverso dall'Ethernet 10Mbit. Alcune reti radio a pacchetti (Packet Radio Networks) sono esempi di tale hardware.
Il protocollo qui descritto è stato il risultato di una grande quantità di discussioni con diverse altre persone, in particolare J. Noel Chiappa, Yogen Dalal e James E. Kulp, e commenti utili da David Moon.
[Lo scopo di questo RFC è presentare un metodo per convertire gli indirizzi di protocollo (ad es., indirizzi IP) in indirizzi di rete locale (ad es., indirizzi Ethernet). Questa è una questione di interesse generale nella comunità ARPA Internet in questo momento. Il metodo qui proposto è presentato per la vostra considerazione e commento. Questa non è una specifica di uno standard Internet.]
Note
Il protocollo è stato originariamente progettato per l'Ethernet DEC/Intel/Xerox 10Mbit. È stato generalizzato per consentirne l'uso su altri tipi di rete. Gran parte della discussione sarà orientata verso l'Ethernet 10Mbit. Le generalizzazioni, ove applicabili, seguiranno la discussione specifica per Ethernet.
Il protocollo Internet DOD (DOD Internet Protocol) sarà semplicemente chiamato Internet.
I numeri qui sono nello standard Ethernet, byte più significativo prima (High Byte First), che è l'opposto dell'indirizzamento dei byte di macchine come PDP-11 e VAX. Pertanto, deve essere prestata particolare attenzione al campo opcode (ar$op) descritto di seguito.
Esiste un'autorità per la gestione dei valori dello spazio dei nomi hardware (vedere di seguito). Prima che esistesse questa autorità ufficiale, le richieste dovevano essere inviate a:
David C. Plummer
Symbolics, Inc.
243 Vassar Street
Cambridge, Massachusetts 02139
Oppure, la posta di rete può essere inviata a <DCP@MIT-MC>.
Il problema (The Problem)
In generale, il mondo è una giungla, e il gioco delle reti contribuisce con molti animali. A quasi ogni livello di un'architettura di rete, ci sono diversi protocolli potenziali che potrebbero essere utilizzati. Ad esempio, a un livello alto, ci sono TELNET e SUPDUP per il login remoto. Da qualche parte sotto c'è un protocollo di flusso di byte affidabile (Reliable Byte Stream Protocol), che potrebbe essere il protocollo CHAOS, DOD TCP, Xerox BSP o DECnet. Ancora più vicino all'hardware c'è il livello di trasporto logico (Logical Transport Layer), che potrebbe essere CHAOS, DOD Internet, Xerox PUP o DECnet. L'Ethernet 10Mbit consente a tutti questi protocolli (e altri) di coesistere su un singolo cavo mediante un campo tipo (Type Field) nell'intestazione del pacchetto Ethernet. Tuttavia, l'Ethernet 10Mbit richiede indirizzi a 48 bit sul cavo fisico, ma la maggior parte degli indirizzi di protocollo non sono lunghi 48 bit, né hanno necessariamente una relazione con l'indirizzo Ethernet a 48 bit dell'hardware. Ad esempio, gli indirizzi CHAOS sono a 16 bit, gli indirizzi DOD Internet sono a 32 bit e gli indirizzi Xerox PUP sono a 8 bit. È necessario un protocollo per distribuire dinamicamente le corrispondenze tra una coppia <protocollo, indirizzo> e un indirizzo Ethernet a 48 bit.
Motivazione (Motivation)
Poiché sempre più produttori forniscono interfacce conformi alla specifica pubblicata da DEC, Intel e Xerox, la disponibilità di Ethernet 10Mbit sta aumentando. Con questa crescente disponibilità, viene scritto sempre più software per queste interfacce. Ci sono due alternative: (1) Ogni implementatore inventa il proprio metodo per eseguire una qualche forma di risoluzione degli indirizzi, o (2) ogni implementatore utilizza uno standard in modo che il suo codice possa essere distribuito ad altri sistemi senza modifiche. Questa proposta tenta di stabilire lo standard.
Definizioni (Definitions)
Definire quanto segue per fare riferimento ai valori inseriti nel campo TYPE dell'intestazione del pacchetto Ethernet:
ether_type$XEROX_PUPether_type$DOD_INTERNETether_type$CHAOS
e un nuovo valore:
ether_type$ADDRESS_RESOLUTION
Definire anche i seguenti valori (da discutere più avanti):
ares_op$REQUEST(= 1, byte più significativo inviato per primo)ares_op$REPLY(= 2)
e:
ares_hrd$Ethernet(= 1)
Formato del pacchetto (Packet Format)
Per comunicare le mappature dalle coppie <protocollo, indirizzo> agli indirizzi Ethernet a 48 bit, è necessario un formato di pacchetto che incarni il protocollo di risoluzione degli indirizzi (Address Resolution Protocol). Il formato è il seguente.
Livello di trasmissione Ethernet (non necessariamente accessibile all'utente):
48 bit: Indirizzo Ethernet di destinazione
48 bit: Indirizzo Ethernet di origine
16 bit: Tipo di protocollo = ether_type$ADDRESS_RESOLUTION
Dati del pacchetto Ethernet:
16 bit: (ar$hrd) Spazio degli indirizzi hardware (ad es., Ethernet, rete radio a pacchetti)
16 bit: (ar$pro) Spazio degli indirizzi di protocollo. Per l'hardware Ethernet, proviene dall'insieme di campi tipo ether_typ$<protocol>
8 bit: (ar$hln) Lunghezza in byte di ciascun indirizzo hardware
8 bit: (ar$pln) Lunghezza in byte di ciascun indirizzo di protocollo
16 bit: (ar$op) Opcode (ares_op$REQUEST | ares_op$REPLY)
n byte: (ar$sha) Indirizzo hardware del mittente di questo pacchetto, n dal campo ar$hln
m byte: (ar$spa) Indirizzo di protocollo del mittente di questo pacchetto, m dal campo ar$pln
n byte: (ar$tha) Indirizzo hardware della destinazione di questo pacchetto (se noto)
m byte: (ar$tpa) Indirizzo di protocollo della destinazione
Generazione del pacchetto (Packet Generation)
Quando un pacchetto viene inviato verso il basso attraverso i livelli di rete, il routing (Routing) determina l'indirizzo di protocollo del prossimo hop per il pacchetto e su quale hardware si aspetta di trovare la stazione con l'indirizzo di protocollo di destinazione immediato. Nel caso dell'Ethernet 10Mbit, è necessaria la risoluzione degli indirizzi e un livello inferiore (probabilmente il driver hardware) deve consultare il modulo di risoluzione degli indirizzi (Address Resolution Module) (probabilmente implementato nel modulo di supporto Ethernet) per convertire la coppia <tipo di protocollo, indirizzo di protocollo di destinazione> in un indirizzo Ethernet a 48 bit. Il modulo di risoluzione degli indirizzi tenta di trovare questa coppia in una tabella. Se trova la coppia, restituisce l'indirizzo Ethernet a 48 bit corrispondente al chiamante (driver hardware) che poi trasmette il pacchetto. Se non lo trova, probabilmente informa il chiamante che sta scartando il pacchetto (supponendo che il pacchetto verrà ritrasmesso da un livello di rete superiore) e genera un pacchetto Ethernet con un campo tipo di ether_type$ADDRESS_RESOLUTION. Il modulo di risoluzione degli indirizzi imposta quindi il campo ar$hrd su ares_hrd$Ethernet, ar$pro sul tipo di protocollo che viene risolto, ar$hln su 6 (il numero di byte in un indirizzo Ethernet a 48 bit), ar$pln sulla lunghezza di un indirizzo in quel protocollo, ar$op su ares_op$REQUEST, ar$sha sul proprio indirizzo Ethernet a 48 bit, ar$spa sul proprio indirizzo di protocollo e ar$tpa sull'indirizzo di protocollo della macchina a cui si sta cercando di accedere. Non imposta ar$tha su alcun valore particolare, poiché questo è il valore che sta cercando di determinare. Può impostare ar$tha sull'indirizzo di broadcast per l'hardware (tutti uno nel caso dell'Ethernet 10Mbit) se ciò è conveniente per alcuni aspetti dell'implementazione. Quindi fa sì che questo pacchetto venga trasmesso in broadcast a tutte le stazioni sul cavo Ethernet originariamente determinato dal meccanismo di routing.
Ricezione del pacchetto (Packet Reception)
Quando viene ricevuto un pacchetto di risoluzione degli indirizzi, il modulo Ethernet ricevente fornisce il pacchetto al modulo di risoluzione degli indirizzi che esegue un algoritmo simile al seguente. Le condizioni negative indicano una fine dell'elaborazione e uno scarto del pacchetto.
?Ho il tipo di hardware in ar$hrd?
Sì: (quasi certamente)
[opzionalmente controllare la lunghezza hardware ar$hln]
?Parlo il protocollo in ar$pro?
Sì:
[opzionalmente controllare la lunghezza del protocollo ar$pln]
Merge_flag := false
Se la coppia <tipo di protocollo, indirizzo di protocollo del mittente> è
già nella mia tabella di traduzione, aggiorna il campo dell'indirizzo hardware
del mittente della voce con le nuove informazioni nel pacchetto
e imposta Merge_flag su true.
?Sono io l'indirizzo di protocollo di destinazione?
Sì:
Se Merge_flag è false, aggiungi la tripla <tipo di protocollo,
indirizzo di protocollo del mittente, indirizzo hardware del mittente> alla
tabella di traduzione.
?L'opcode è ares_op$REQUEST? (ORA guarda l'opcode!!)
Sì:
Scambia i campi hardware e protocollo, mettendo gli indirizzi
hardware e di protocollo locali nei campi mittente.
Imposta il campo ar$op su ares_op$REPLY
Invia il pacchetto all'indirizzo hardware di destinazione (nuovo) sullo
stesso hardware su cui è stata ricevuta la richiesta.
Si noti che la tripla <tipo di protocollo, indirizzo di protocollo del mittente, indirizzo hardware del mittente> viene unita nella tabella prima che l'opcode venga esaminato. Questo si basa sull'assunzione che la comunicazione sia bidirezionale; se A ha qualche motivo per parlare con B, allora B avrà probabilmente qualche motivo per parlare con A. Si noti anche che se una voce esiste già per la coppia <tipo di protocollo, indirizzo di protocollo del mittente>, il nuovo indirizzo hardware sostituisce quello vecchio. Le questioni correlate (Related Issues) forniscono una certa motivazione per questo.
Generalizzazione: I campi ar$hrd e ar$hln consentono a questo protocollo e formato di pacchetto di essere utilizzati per Ethernet non 10Mbit. Per l'Ethernet 10Mbit, <ar$hrd, ar$hln> assume il valore <1, 6>. Per altre reti hardware, il campo ar$pro potrebbe non corrispondere più al campo tipo Ethernet, ma dovrebbe essere associato al protocollo di cui si cerca la risoluzione degli indirizzi.
Perché si fa in questo modo? (Why is it done this way?)
Il broadcasting periodico non è assolutamente desiderabile. Immaginate 100 workstation su un singolo Ethernet, ciascuna che trasmette in broadcast informazioni di risoluzione degli indirizzi una volta ogni 10 minuti (come un possibile insieme di parametri). Questo è un pacchetto ogni 6 secondi. Questo è quasi ragionevole, ma a cosa serve? Le workstation in genere non parleranno tra loro (e quindi avranno 100 voci inutili in una tabella); parleranno principalmente con un mainframe, un file server o un bridge, ma solo con un piccolo numero di altre workstation (ad esempio, per conversazioni interattive). Il protocollo descritto in questo documento distribuisce le informazioni secondo necessità e solo una volta (probabilmente) per avvio di una macchina.
Questo formato non consente di eseguire più di una risoluzione nello stesso pacchetto. Questo è per semplicità. Se le cose fossero multiplexate, il formato del pacchetto sarebbe considerevolmente più difficile da digerire e gran parte delle informazioni potrebbe essere gratuita. Pensate a un bridge che parla quattro protocolli che dice a una workstation tutti e quattro gli indirizzi di protocollo, tre dei quali la workstation probabilmente non userà mai.
Questo formato consente il riutilizzo del buffer del pacchetto se viene generata una risposta; una risposta ha la stessa lunghezza di una richiesta e diversi campi sono gli stessi.
Il valore del campo hardware (ar$hrd) è preso da un elenco per questo scopo. Attualmente l'unico valore definito è per l'Ethernet 10Mbit (ares_hrd$Ethernet = 1). Si è parlato di utilizzare questo protocollo anche per le reti radio a pacchetti (Packet Radio Networks), che richiederebbero un altro valore, così come altri futuri mezzi hardware che desiderano utilizzare questo protocollo.
Per l'Ethernet 10Mbit, il valore nel campo protocollo (ar$pro) è preso dall'insieme ether_type$. Questo è un riutilizzo naturale dei tipi di protocollo assegnati. Combinando questo con l'opcode (ar$op) si dimezzerebbe effettivamente il numero di protocolli che possono essere risolti sotto questo protocollo e renderebbe un monitor/debugger più complesso (vedere Monitoraggio e debug della rete di seguito). Si spera di non vedere mai 32768 protocolli, ma la legge di Murphy non ci consente di fare tale assunzione.
I campi di lunghezza (ar$hln e ar$pln) sono, in teoria, ridondanti, poiché la lunghezza di un indirizzo di protocollo dovrebbe essere determinata dal tipo di hardware (trovato in ar$hrd) e dal tipo di protocollo (trovato in ar$pro). Sono inclusi per il controllo opzionale della coerenza e per il monitoraggio e il debug della rete (vedere di seguito).
L'opcode è utilizzato per determinare se si tratta di una richiesta (che può causare una risposta) o di una risposta a una richiesta precedente. 16 bit per questo sono eccessivi, ma è necessario un flag (campo).
L'indirizzo hardware del mittente e l'indirizzo di protocollo del mittente sono assolutamente necessari. Sono questi campi che vengono inseriti in una tabella di traduzione.
L'indirizzo di protocollo di destinazione è necessario nella forma di richiesta del pacchetto in modo che una macchina possa determinare se inserire le informazioni del mittente in una tabella o inviare una risposta. Non è necessariamente necessario nella forma di risposta se si assume che una risposta sia provocata solo da una richiesta. È incluso per completezza, monitoraggio della rete e per semplificare l'algoritmo di elaborazione suggerito descritto sopra (che non guarda l'opcode fino a DOPO aver inserito le informazioni del mittente in una tabella).
L'indirizzo hardware di destinazione è incluso per completezza e monitoraggio della rete. Non ha significato nella forma di richiesta, poiché questo è il numero che la macchina sta richiedendo. Il suo significato nella forma di risposta è l'indirizzo della macchina che effettua la richiesta. In alcune implementazioni (che hanno bisogno di recuperare l'indirizzo hardware di destinazione), questo può risparmiare un po' di riorganizzazione dei registri o spazio dello stack inviando questo campo al driver hardware come indirizzo di destinazione hardware del pacchetto.
Non ci sono byte di riempimento tra gli indirizzi. I dati del pacchetto dovrebbero essere visti come un flusso di byte in cui solo 3 coppie di byte sono definite come parole (ar$hrd, ar$pro e ar$op) che vengono inviate con il byte più significativo per primo (stile byte Ethernet/PDP-10).
Monitoraggio e debug della rete (Network Monitoring and Debugging)
Il protocollo di risoluzione degli indirizzi sopra descritto consente a una macchina di acquisire conoscenze sull'attività di protocollo di livello superiore (ad es., CHAOS, Internet, PUP, DECnet) su un cavo Ethernet. Può determinare quali campi di tipo di protocollo Ethernet sono in uso (per valore) e gli indirizzi di protocollo all'interno di ciascun tipo di protocollo. Infatti, non è necessario che il monitor parli uno qualsiasi dei protocolli di livello superiore coinvolti. Può essere fatto come segue:
Quando un monitor riceve un pacchetto di risoluzione degli indirizzi, inserisce sempre il <tipo di protocollo, indirizzo di protocollo del mittente, indirizzo hardware del mittente> in una tabella. Può determinare la lunghezza dell'indirizzo hardware e di protocollo dai campi ar$hln e ar$pln del pacchetto. Se l'opcode è REPLY, il monitor può scartare il pacchetto. Se l'opcode è REQUEST e l'indirizzo di protocollo di destinazione corrisponde all'indirizzo di protocollo del monitor, il monitor invia una REPLY come farebbe normalmente. Il monitor otterrà solo una mappatura in questo modo, poiché la REPLY alla REQUEST verrà inviata direttamente all'host richiedente. Il monitor potrebbe provare a inviare la propria REQUEST, ma questo potrebbe mettere due monitor in un ciclo di invio di REQUEST e bisogna fare attenzione.
Poiché il protocollo e l'opcode non sono combinati in un campo, il monitor non ha bisogno di sapere quale opcode di richiesta corrisponde a quale opcode di risposta per lo stesso protocollo di livello superiore. I campi di lunghezza dovrebbero anche fornire informazioni sufficienti per consentirgli di "analizzare" gli indirizzi di protocollo, anche se non ha conoscenza di cosa significhino gli indirizzi di protocollo.
Un'implementazione funzionante del protocollo di risoluzione degli indirizzi può anche essere utilizzata per eseguire il debug di un'implementazione non funzionante. Presumibilmente un driver hardware trasmetterà con successo un pacchetto con campo tipo Ethernet di ether_type$ADDRESS_RESOLUTION. Il formato del pacchetto potrebbe non essere totalmente corretto, poiché le implementazioni iniziali possono avere bug e la gestione delle tabelle può essere un po' complicata. Poiché le richieste vengono trasmesse in broadcast, un monitor riceverà il pacchetto e potrà visualizzarlo per il debug se necessario.
Un esempio (An Example)
Supponiamo che esistano macchine X e Y che si trovano sullo stesso cavo Ethernet 10Mbit. Hanno indirizzi Ethernet EA(X) ed EA(Y) e indirizzi DOD Internet IPA(X) e IPA(Y). Sia il tipo Ethernet di Internet ET(IP). La macchina X è appena stata avviata e prima o poi vuole inviare un pacchetto Internet alla macchina Y sullo stesso cavo. X sa che vuole inviare a IPA(Y) e dice al driver hardware (qui un driver Ethernet) IPA(Y). Il driver consulta il modulo di risoluzione degli indirizzi per convertire <ET(IP), IPA(Y)> in un indirizzo Ethernet a 48 bit, ma poiché X è appena stato avviato, non ha questa informazione. Scarta il pacchetto Internet e crea invece un pacchetto ADDRESS RESOLUTION:
(ar$hrd) = ares_hrd$Ethernet
(ar$pro) = ET(IP)
(ar$hln) = length(EA(X))
(ar$pln) = length(IPA(X))
(ar$op) = ares_op$REQUEST
(ar$sha) = EA(X)
(ar$spa) = IPA(X)
(ar$tha) = non importa
(ar$tpa) = IPA(Y)
e trasmette in broadcast questo pacchetto a tutti sul cavo.
La macchina Y ottiene questo pacchetto e determina che comprende il tipo di hardware (Ethernet), che parla il protocollo indicato (Internet) e che il pacchetto è per lei ((ar$tpa)=IPA(Y)). Inserisce (probabilmente sostituendo qualsiasi voce esistente) l'informazione che <ET(IP), IPA(X)> corrisponde a EA(X). Quindi nota che è una richiesta, quindi scambia i campi, mette EA(Y) nel nuovo campo indirizzo Ethernet del mittente (ar$sha), imposta l'opcode su reply e invia il pacchetto direttamente (non in broadcast) a EA(X). A questo punto Y sa come inviare a X, ma X ancora non sa come inviare a Y.
La macchina X ottiene il pacchetto di risposta da Y, forma la mappatura da <ET(IP), IPA(Y)> a EA(Y), nota che il pacchetto è una risposta e lo scarta. La prossima volta che il modulo Internet di X cerca di inviare un pacchetto a Y sull'Ethernet, la traduzione avrà successo e il pacchetto arriverà (si spera). Se il modulo Internet di Y vuole quindi parlare con X, anche questo avrà successo poiché Y ha già ricordato le informazioni dalla richiesta di risoluzione degli indirizzi di X.
Questione correlata (Related Issue)
Potrebbe essere desiderabile avere l'invecchiamento delle tabelle e/o timeout. L'implementazione di questi è al di fuori dell'ambito di questo protocollo. Ecco una descrizione più dettagliata (grazie a MOON@SCRC@MIT-MC).
Se un host si sposta, qualsiasi connessione avviata da quell'host funzionerà, supponendo che la propria tabella di risoluzione degli indirizzi venga cancellata quando si sposta. Tuttavia, le connessioni avviate verso di esso da altri host non avranno alcun motivo particolare per sapere di scartare il vecchio indirizzo. Tuttavia, gli indirizzi Ethernet a 48 bit dovrebbero essere univoci e fissi per sempre, quindi non dovrebbero cambiare. Un host può "spostarsi" se il suo nome host (e indirizzo in qualche altro protocollo) viene riassegnato a un hardware fisico diverso. Inoltre, come sappiamo per esperienza, c'è sempre il pericolo che informazioni di routing errate vengano accidentalmente trasmesse attraverso errori hardware o software; non dovrebbe essere permesso che persistano per sempre. Forse il fallimento nell'avviare una connessione dovrebbe informare il modulo di risoluzione degli indirizzi di eliminare le informazioni, con il motivo che l'host non è raggiungibile, possibilmente perché è inattivo o la vecchia traduzione non è più valida. Oppure forse ricevere un pacchetto da un host dovrebbe resettare il timeout nella voce di risoluzione degli indirizzi utilizzata per trasmettere pacchetti a quell'host; se non vengono ricevuti pacchetti da un host per un periodo di tempo appropriato, la voce di risoluzione degli indirizzi viene dimenticata. Questo può causare un overhead aggiuntivo per scansionare la tabella per ogni pacchetto in arrivo. Forse l'uso di un hash o un indice può rendere questo più veloce.
L'algoritmo suggerito per la ricezione di pacchetti di risoluzione degli indirizzi cerca di ridurre il tempo necessario per il recupero se un host si sposta effettivamente. Ricordate che se la coppia <tipo di protocollo, indirizzo di protocollo del mittente> è già nella tabella di traduzione, il nuovo indirizzo hardware sostituisce la voce esistente. Pertanto, su un Ethernet perfetto in cui una REQUEST di broadcast raggiunge tutte le stazioni sul cavo, ogni stazione otterrà il nuovo indirizzo hardware.
Un'alternativa sarebbe avere un daemon che esegue i timeout. Dopo un tempo appropriato, il daemon considera la rimozione di una voce. Prima invia (con un piccolo numero di ritrasmissioni se necessario) un pacchetto di risoluzione degli indirizzi con opcode REQUEST direttamente all'indirizzo Ethernet nella tabella. Se una REPLY non viene vista in breve tempo, la voce viene eliminata. La richiesta viene inviata direttamente per non disturbare ogni stazione sull'Ethernet. Semplicemente dimenticare le voci probabilmente causerà la dimenticanza di informazioni utili, che devono essere riacquisite.
Poiché gli host non trasmettono informazioni su nessun altro se non se stessi, riavviare un host farà sì che la sua tabella di mappatura degli indirizzi sia aggiornata. Le cattive informazioni non possono persistere per sempre essendo passate da macchina a macchina; le uniche cattive informazioni che possono esistere sono in una macchina che non sa che qualche altra macchina ha cambiato il suo indirizzo Ethernet a 48 bit. Forse resettare manualmente (o cancellare) la tabella di mappatura degli indirizzi sarà sufficiente.
Se si ritiene che questo problema sia importante, è importante che il daemon scada e ponga nuovamente la domanda invece di rimuovere semplicemente la voce. Il daemon potrebbe anche fare un lavoro migliore di ritrasmissioni rispetto a questo protocollo, poiché una macchina di destinazione che è fisicamente connessa ma irraggiungibile (ad esempio, a causa di un guasto software) non dovrebbe dover rispondere alla richiesta. Questo protocollo verrà utilizzato per determinare l'indirizzo Ethernet del gateway del prossimo hop e quel gateway non dovrebbe dover rispondere a tutti i pacchetti di risoluzione degli indirizzi sull'Ethernet. Questo non è un problema significativo, poiché il daemon potrebbe utilizzare il protocollo di risoluzione degli indirizzi per porre la domanda, piuttosto che far utilizzare al modulo di risoluzione degli indirizzi il proprio protocollo.
Risorse correlate
- RFC ufficiale:
https://www.rfc-editor.org/rfc/rfc826.txt - Pagina ufficiale:
https://datatracker.ietf.org/doc/html/rfc826