Comportamiento de los mensajes DHCP según cada fabricante
Fecha: 4 al 11 de julio
del 2023
Escenario
Este laboratorio compara el comportamiento del DHCP
entre diferentes modelos y marcas implementadas como DHCP servers,
y diferentes clientes DHCP, para tener un
contraste con la RFC 1541 y su upgrade RFC 2141, que
detallan el protocolo, y verificar
si se utilizan broadcast o unicast en las negociaciones, y pings o ARP (o ninguno) en
las verificaciones antes de ofrecer una IP.
No entraremos en demasiados detalles de
configuraciones de los equipos, generalmente las pruebas son por default salvo
algo
interesante para analizar sobre cómo es la
conversación DHCP en sí misma.
Esto salió de la clase sobre la capa de
aplicación de CCNA1 del 3 de julio, donde comenté sobre el comportamiento del
protocolo
según los distintos fabricantes, y aquí estamos…
1.- RFC 1541 que detalla el
DHCP https://datatracker.ietf.org/doc/html/rfc1541
y https://datatracker.ietf.org/doc/html/rfc2131
Dentro del documento nos centramos en la sección 3.1 que describe la interacción cliente-servidor.
3.1 Client-server interaction - allocating a network address https://datatracker.ietf.org/doc/html/rfc1541#section-3.1
The following summary of the protocol exchanges between clients and
servers refers to the DHCP messages described in table 2.
The timeline diagram in figure 3 shows the timing relationships in a
typical client-server interaction. If
the client already knows its
address, some steps may be omitted; this abbreviated interaction is
described in section 3.2.
1. The client broadcasts a DHCPDISCOVER message on its local physical
subnet. The DHCPDISCOVER message may include options
that suggest
values for the network
address and lease duration. BOOTP relay
agents may pass the message
on to DHCP servers not on the same
physical subnet.
2. Each server may respond with
a DHCPOFFER message that includes an
available network address in
the 'yiaddr' field (and other
configuration parameters in
DHCP options). Servers need not
reserve the offered network
address, although the protocol will
work more efficiently if the
server avoids allocating the offered
network address to another
client. The server unicasts the
DHCPOFFER message to the client (using the DHCP/BOOTP relay
agent
if necessary) if possible, or may broadcast the message to a
broadcast address (preferably
255.255.255.255) on the client's
subnet.
3. The client receives one or
more DHCPOFFER messages from one or
more servers. The client may choose to wait for multiple
responses. The client chooses one server from which to
request
configuration parameters,
based on the configuration parameters
offered in the DHCPOFFER
messages. The client broadcasts a
DHCPREQUEST message that MUST include the 'server identifier'
option to indicate which
server it has selected, and may include
other options specifying
desired configuration values. This
DHCPREQUEST message is
broadcast and relayed through DHCP/BOOTP
relay agents. To help ensure that any DHCP/BOOTP relay
agents
forward the DHCPREQUEST
message to the same set of DHCP servers
that received the original
DHCPDISCOVER message, the DHCPREQUEST
message must use the same
value in the DHCP message header's
'secs' field and be sent to
the same IP broadcast address as the
original DHCPDISCOVER
message. The client times out and
retransmits the DHCPDISCOVER
message if the client receives no
DHCPOFFER messages.
4. The servers receive the
DHCPREQUEST broadcast from the client.
Those servers not selected by
the DHCPREQUEST message use the
message as notification that
the client has declined that server's
offer. The server selected in the DHCPREQUEST
message commits the
binding for the client to
persistent storage and responds
with a
DHCPACK message containing the configuration parameters for
the
requesting client. The combination of 'chaddr'
and assigned
network address constitute an
unique identifier for the client's
lease and are used by both
the client and server to identify a
lease referred to in any DHCP
messages. The 'yiaddr'
field in the
DHCPACK messages is filled in
with the selected network address.
2.- Ejemplo con Packet Tracer:
2.1.- La PC genera el
DHCP DISCOVER con SRC IP 0.0.0.0 y DST IP 255.255.255.255.
2.2.- El server genera
un ARP para verificar si la IP ya está en uso, si no hay respuesta la ofrece.
2.3.- El server genera
el DHCP OFFER con SRC IP 192.168.0.1 y DST IP 255.255.255.255 para que todos
los potenciales servidores
DHCP estén al tanto de la oferta.
2.4.- La PC genera el
DHCP REQUEST con SRC IP 0.0.0.0 y DST IP 255.255.255.255 para que todos los
potenciales servidores
DHCP estén al tanto de la oferta.
2.5.- El server genera
el DHCP ACK con SRC IP 192.168.0.1 y DST IP 255.255.255.255 para que todos los
potenciales servidores
DHCP estén al tanto de la oferta.
3.- Contra un router Cisco 1841:
Este es nuestro cuestionamiento, cuál sería el
motivo de generar un ping desde el DHCP server a la IP 192.168.0.100 con la MAC
e8:6a:64:dc:e2:f5 de
la PC solicitante, si lo que se busca es hallar
otro dispositivo diferente con dicha IP, lo mas
lógico sería generar un ARP viendo quién tiene (que equipo
y MAC) utilizando dicha IP. La PC solicitante no
la tendría ya que justamente está (valga la redundancia) solicitando una IP.
Esto es lo que obtuvimos de la página de Cisco:
https://www.cisco.com/en/US/docs/ios/12_4t/ip_addr/configuration/guide/htdhcpsv.html#wp1049200
Address Conflicts
An address conflict occurs when two hosts use the same IP address. During
address assignment, DHCP checks for conflicts using ping and gratuitous
Address Resolution Protocol (ARP). If a conflict is detected, the address
is removed from the pool. The address will not be assigned until the
administrator
resolves the conflict.
Conflictos de direcciones
Un conflicto de direcciones ocurre cuando dos
hosts usan la misma dirección IP. Durante la asignación de direcciones, DHCP
comprueba si hay conflictos
mediante ping y el protocolo de resolución de
direcciones (ARP) gratuito. Si se detecta un conflicto, la dirección se elimina
del grupo. La dirección no se
asignará hasta que el administrador resuelva el
conflicto.
https://www.cisco.com/en/US/docs/ios/12_4t/ip_addr/configuration/guide/htdhcpsv.html#wp1082847
Ping Packet Settings
By default, the DHCP server pings a pool address twice before assigning a
particular address to a requesting client. If the ping is unanswered, the DHCP
server assumes (with a high probability) that the address is not in use
and assigns the address to the requesting client.
By default, the DHCP server waits 2 seconds before timing out a ping
packet.
Configuración del paquete de
ping (frase intraducible…)
De forma predeterminada, el servidor DHCP hace
ping a una dirección de grupo dos veces antes de asignar una dirección
particular a un cliente solicitante.
Si no se responde al ping, el servidor DHCP asume
(con una alta probabilidad) que la dirección no está en uso y asigna la
dirección al cliente solicitante.
De forma predeterminada, el servidor DHCP espera
2 segundos antes de agotar el tiempo de espera de un paquete de ping.
En esta y otras pruebas, se utiliza como IP
destino la IP ofrecida al cliente, aunque este aún no la tenga configurada, en
vez de utilizar broadcast.
Podemos ver los envíos de ping y la ausencia de
respuestas ya que el cliente aún no adoptó la IP ofrecida.
4.- Contra un router Cisco 881:
En este caso, al ser otro router
IOS tenemos el mismo comportamiento.
5.- Contra un switch L3 Catalyst (IOS):
Aquí también se utiliza como destino la IP
ofrecida al cliente en vez de utilizar broadcast, pero al ser una variante IOS
para switches utiliza un ARP para descubrir si la
IP está potencialmente en uso.
5.1.- Con un cliente
Windows:
5.2.- Con un cliente Linux:
Mismo comportamiento, tanto del lado servidor
como cliente.
5.3.- Con ambos clientes:
En este caso la captura se realiza desde la PC
Windows, las tramas/paquetes 1 a 5 son capturadas en la propia PC,
las tramas/paquetes 6 a 8 son el pedido de la PC
Linux, donde 6 y 8 son los broadcasts DISCOVER y REQUEST, y
la trama/paquete 7 ene l broadcast del ARP
generado por el switch L3.
Aquí podemos ver el detalle de cómo se intercalan
los broadcasts y cuales se descartan y cuales se aceptan dependiendo del
cliente.
6.- Contra un firewall Cisco
ASA:
Aquí también se utiliza como destino la IP
ofrecida al cliente, en vez de utilizar broadcast, pero un ARP para descubrir
si la IP está potencialmente en uso.
7.- Contra un firewall Cisco
PIX:
Aquí también se utiliza como destino la IP
ofrecida al cliente, en vez de utilizar broadcast, pero un ARP para descubrir
si la IP está potencialmente en uso.
8.- Contra un router Mikrotik:
En este ejemplo podemos ver que en Mikrotik la asignación de las IP del pool son de manera
descendente (de IP más alta
a IP más baja), contrariamente a la asignación en
Cisco que es ascendente (de IP más baja a IP más alta), por lo que aquí
primero ofreció la .199 en lugar de la .100 (de
un pool de .100 a .199).
Mikrotik adhiere a los
standards RFC 2131, RFC 3315, RFC 3633 ( https://wiki.mikrotik.com/wiki/Manual:IP/DHCP_Server )
Se puede modificar al modo broadcast mediante la
opción always-broadcast=yes
No hay ni ARP ni pings para encontrar conflictos,
pero es configurable con la opción set conflict-detection=yes
9.- Contra un router Nokia:
Agregué como ejemplo el router
de mi ISP en mi casa mediante una conexión WiFi, por
eso el rango IP no es el mismo.
10.- Contra un server
Windows con TFTP32 como server DHCP:
Asumimos que mas allá
de la aplicación del DHCP server no es la nativa de Windows, el manejo del stack lo realiza el sistema
operativo mismo, por lo que el comportamiento
será similar en ambos casos. Este análisis también se hizo en otro escenario y
se recurrió a la página del comportamiento
DHCP de Microsoft.
Aquí se utiliza como destino la IP de broadcast,
y (varios) ARP para descubrir si la IP
está potencialmente en uso.
11.- Contra un server Linux:
Se utilizó un Debian 11 gentileza del mismísimo
Osvaldo Fabián Sanchez (el BB para los amigos), el
mago del software libre.
En este caso podemos ver un ping de verificación
al final de la secuencia DHCP.
12.- Detalle de los pedidos
desde el cliente (tanto Linux o Windows):
Cuando realizamos la disección de una trama DHCP
DISCOVER desde el cliente Windows, por más que se ejecutara un ipconfig /release
siempre (o casi siempre) solicitaba la última IP
obtenida, a menos que reiniciemos la PC, pero así y todo a veces perdura por
permanecer
en la registry \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\.
12.1.- Detalle de la IP
almacenada en la registry:
12.2.- Detalle de un DHCP DISCOVER
con IP source 0.0.0.0 y solicitando la IP
192.168.0.100:
Frame 1: 344 bytes on wire (2752 bits), 344 bytes captured (2752 bits)
Ethernet II, Src:
e8:6a:64:dc:e2:f5, Dst: ff:ff:ff:ff:ff:ff
(capa 2 del modelo OSI)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255 (capa 3 del modelo
OSI)
User Datagram Protocol, Src Port: 68, Dst Port: 67 (capa 4 del modelo OSI)
Dynamic Host Configuration
Protocol (Discover) (capa 7 del modelo OSI)
Message type: Boot Request (1)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0xeb005c05
Seconds elapsed: 0
Bootp
flags: 0x0000 (Unicast)
Client IP address: 0.0.0.0
Your (client) IP address:
0.0.0.0
Next server IP address: 0.0.0.0
Relay agent IP address: 0.0.0.0
Client MAC address:
e8:6a:64:dc:e2:f5
Client hardware address
padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type
(Discover)
Option: (61) Client identifier
Option: (50) Requested
IP Address (192.168.0.100) (generalmente
suele solicitar la misma IP que tuvo anteriormente,
Option: (12) Host Name si el equipo tuvo
un reboot suele no aparecer este campo)
Option: (60) Vendor class identifier
Option: (55) Parameter Request
List
Option: (255) End
13.- Detalle de los pings
desde los equipos Cisco IOS (no PIX):
Detallamos esto para cuestionar de que el ping va
directamente contra el equipo que solicita la IP y no contra otro potencial
equipo que pudiese tener la IP, para esto primero
se debería ejecutar un ARP tal como vimos en las implementaciones de
Windows y Cisco PIX.
14.- Detalle de la
bibliografía consultada:
Los libros Internetworking
with TCP/IP de Douglas Comer, en versiones español e
inglés, a veces en español las cosas son inentendibles.
15.- Otros labs de DHCP para meditar:
https://www.vilarrasa.com.ar/pruebas_dhcp.htm
https://www.vilarrasa.com.ar/snooping.htm
https://www.vilarrasa.com.ar/dhcpv6.htm
https://www.vilarrasa.com.ar/dhcp_pat.htm
https://www.vilarrasa.com.ar/starvation_asa.htm
https://www.vilarrasa.com.ar/pruebas_dhcp_relay.htm
https://www.vilarrasa.com.ar/relay_dhcp.htm
https://www.vilarrasa.com.ar/relay_dhcp_down.htm
https://www.vilarrasa.com.ar/smart_relay.htm
https://www.vilarrasa.com.ar/relay_timeout.htm
https://www.vilarrasa.com.ar/sw_aprende_mac.htm
(2023) Burning minds
with networking.
Rosario, Argentina