Cisco Teroria Modulo Quarto Lezione 2

RARP

Reverse arp fa l'opposto di arp noto l'indirizzo di livello 2 scopre l'indirizzo ip corrispondente. Arp manda in broadcast nella rete un pacchetto di richiesta dato un mac address (il proprio) chiede l'indirizzo ip. Il server RARP riceve e risponde in broadcast comunicando l'indirizzo ip che l'host deve assumere. Il server ha una corrispondenza di indirizzo ip e mac address.
L'host può cominciare con il server che da anche il s.o. così che l'host può caricarlo.
Con il RARP non vengono scambiati info di netmask e default gw quindi posso solo parlare con macchine nella mia lan al mio stesso livello.

BOOTP

ip con source address tutti 0 . 0.0.0.0 significa che io non conosco il mio indirizzo, ma l'indirizzo ip è valido. Non posso ricevere unicast senza sapere il mio indirizzo ip.
Nella risposta del bootp ci sta tutto gateway , maschera dns.
C'è il problema del riuso di indirizzi ip già assegnati. Si risolve al momento dell'assegnazione fornendo un tempo di scadenza.

DHCP

Fa lo stesso del bootp con la scadenza.
Ci sono tre modalità di assegnazione

1. manuale: ip e host sempre e solo gli stessi
2. automatica: assegno un pool di ip e il server li assegna ma sempre in maniera permanente
3. dinamica: alloca l'ip dinamicamente per un tempo predefinito leasing

Diagramma stati

1. il client dhcp manda un dhcpdiscover
2. si mette in uno stato pronto a ricevere il dhcpoffer. Client può ricevere più offerte perchè possono esserci più server
3. il client sceglie quale dhcp server e manda un messaggio in broadcast in modo che il server che è stato selezionato sa che è stato accettato, mentre quelli non selezionati sanno che non devono più parlare con quel client.
4. il server selezionato manda al client un messaggio di dhcphack con indirizzo ip che assegna al client. Nel messaggio di ack c'è anche il tempo di leasing
5. Quando è passato il 50% del tempo di leasing il client manda un messaggio al server con un dhcprequest per estendere il leasing, lo manda in unicast. Il server può rifiutare il messaggio di rinnovo con un dhcpnack
6. se il server non risponde al messaggio di rinnovo, perchè per esempio è andato giu, il client dopo 7/8 del tempo di leasing manda un dhcprequest in broadcast la richiesta di dhcp, con l'idea che ci sia un altro server anche di backup che sia in grado di rispondermi. Magari se ci sono più server c'è un coordinamento tra questi.
7. se il client non ha più bisogno di indirizzo ip per esempio perchè si spegne, manda un messaggio di dhcp relase

Formato della pdu

È uguale tra bootp e dhcp. Bootp utilizza udp e ha una porta dedicata.
Server ip address è il server a cui connettersi per scaricare il s.o. Boot file name è il file per scaricare il s.o. Ci sono le opzioni variabili che servono per specificare info varie descritte prima.
Il formato delle opzioni è il tag lenght values, formato TLV. Informazioni variabili di formato variabile. Il tag iniziale descrive che tipo di informazioni sto portando, il secondo la lunghezza del campo che viene dopo, il value è l'informazione vera e propria che voglio scambiare.
Esempio per la subnet mask, tag=1 leght=32 value=il valore vero e proprio della netmask.
Il tag 53 è quello di dhcp in questo modo si garantisce la compatibilità con il bootp. Tutte le informazioni del dhcp stanno nelle options

Relay Agents

Il problema è l'utilizzo dei messaggi in broadcast per la lan quindi il server deve stare sulla stessa lan. Il problema è che per un server voglio gestire diverse sottoreti in modo da semplificare la cosa.
Si usa un realay agent sul router. Il relay agent non fa altro che passare i messaggi dhcp tra le sottoreti.
Il router è sensibile alle richieste di dhcp sulle sue porte. Se riceve un messaggio con la porta del dhcp mandato in broadcast.
Il router riceve il messaggio di dhcp discover su una sua interfaccia lo inoltra all'altra modificando alcuni campi. Non è più broadcast ma destinato al server dhcp, l'ip gateway mette il suo dalla parte del client.
Il server si accorge che è un dhcp di relay agent dall'indirizzo di gateway che non è nullo e quindi deduce la sottorete che deve allocare, manda il messaggio verso il gateway che lo inoltra all'interfaccia corretta.

Problema sulla sicurezza

Finti client che si presentano al server dhcp in maniera diversa e che possono saturare le risorse.
Difficile autenticare il client perchè presupporrebbe una condivisione di infomazioni.
Ci sono dei metodi per autenticare descritti nella rfc 3118 ma questo complica il metodo e annulla molti dei vantaggi dei dhcp.