El Nivel de Red en TCP/IP

Nivel de red en TCP/IP

El Nivel de Red en TCP/IP está formado por: El protocolo IP: IPv4, IPv6 Los protocolos de control, ej.: ICMP, ARP,

RARP, BOOTP, DHCP, IGMP Los protocolos de routing, ej.: RIP, OSPF, IS-

IS, IGRP, EIGRP, BGP Toda la información en Internet viaja en

datagramas IP

IP (Internet Protocol)

Protocolo de conmutación de paquetes, tanto a nivel de servicio como de implementación.

No orientado a conexión. Cada paquete se enruta de forma independiente.

NO garantiza: entrega, orden y la no duplicidad de la información (NO CONFIABLE)

No detecta ni corrige errores en el Payload. Solo detecta errores en el encabezado

descartando el paquete cuando este llega mal.

Internet es un conjunto de redes interconectadas

El protocolo IP es el ‘pegamento’ que mantiene unidas esas redes

Principios de diseño de Internet (según Tanenbaum)

Asegúrate de que funciona. Mantenlo tan simple como sea posible. Cuando tomes decisiones haz elecciones

claras. Aprovecha la modularidad. Ten en cuenta la heterogeneidad. Evita opciones y parámetros estáticos. Busca un buen diseño (no necesita ser

perfecto). Piensa en la escalabilidad. Sé estricto al enviar y tolerante al recibir

Versión: siempre vale 4

Longitud Cabecera: en palabras de 32 bits

DS (Differentiated Services): Para Calidad de Servicio

Longitud total: en bytes, máximo 65535 (incluye la cabecera)

Campos de Fragmentación: Identificación, DF, MF, Desplaz. Fragmento

Tiempo de vida (TTL): cuenta saltos hacia atrás (se descarta cuando es cero)

Checksum: comprueba toda la cabecera (pero no los datos)

32 bits

Cabecera de un datagrama IPv4

Versión Lon Cab DS (DiffServ) Longitud Total

Identificación DF MF Desplazamiento del Fragmento

Tiempo de vida (TTL) Protocolo Checksum

Dirección de origen

Dirección de destino

Opciones (de 0 a 40 bytes)

Valor Protocolo Descripción

1 ICMP Internet Control Message Protocol

2 IGMP Internet Group Management Protocol

3 GGP Gateway-to-Gateway Protocol

4 IP IP en IP (encapsulado)

5 ST Stream

6 TCP Transmission Control Protocol

8 EGP Exterior Gateway Protocol

17 UDP User Datagram Protocol

29 ISO-TP4 ISO Transport Protocol Clase 4

80 CLNP Connectionless Network Protocol

88 IGRP Interior Gateway Routing Protocol

89 OSPF Open Shortest Path First

Algunos valores del campo Protocolo

DIRECCIONAMIENTO IP V4

Cada nodo tiene por lo menos una dirección única IP de 32 bits.Por facilidad se escriben como 4 valores decimales separados por puntos.Ej: 129.0.0.1Se soporta unicast, multicast y broadcastGeneralmente a una red física corresponde una red lógica.Nodos con más de una interfaz reciben el nombre de multi-homed. Tienen una dirección por puerto.Un una interfaz puede tener varias direcciones.

DIRECCIONAMIENTO IP V4

•La dirección de cada nodo se puede asignar de dos formas:Estática: se configura en cada nodo manualmente.Dinámica: a través de un servicio se asigna automáticamente.

•Se estructuran los 32 bits así: Una parte para identificar la red.Otra parte para identificar el nodo dentro de la red.

•Con base en la parte que identifica la red, el nodo se da cuenta si el destino esta en su misma red o en otra.

0 Red(128) Host (16,777,216)

10 Red (16,384) Host (65,536)

110 Red (2,097,152) Host (256)

1111 Reservado

1110 Grupo Multicast (268,435,456)

Clase

A

B

C

D

E

Rango

0.0.0.0127.255.255.255

128.0.0.0191.255.255.255

192.0.0.0223.255.255.255

224.0.0.0239.255.255.255

240.0.0.0255.255.255.255

32 bits

Formato de direcciones IP

Dirección Significado Ejemplo

255.255.255.255 Broadcast en la propia red o subred

0.0.0.0 Identifica al host que envía el datagrama Usado en BOOTP

Host a ceros Identifica una red (o subred) 147.156.0.0

Host a unos Broadcast en esa red (o subred) 147.156.255.255

Red a ceros Identifica un host en la propia red (o subred)

0.0.1.25

127.0.0.1 Dirección Loopback

224.0.0.1 Todos los hosts multicast

Direcciones IP especiales

Red o rango Uso

127.0.0.0 Reservado (fin clase A)

128.0.0.0 Reservado (ppio. Clase B)

191.255.0.0 Reservado (fin clase B)

192.0.0.0 Reservado (ppio. Clase C)

224.0.0.0 Reservado (ppio. Clase D)

240.0.0.0 – 255.255.255.254 Reservado (clase E)

10.0.0.0 Privado

172.16.0.0 – 172.31.0.0 Privado

192.168.0.0 – 192.168.255.0 Privado

Direcciones IP reservadas y privadas (RFC 1,918)

172.16.1.10

NAT

172.16.1.2

Empresa X172.16.0.0

147.156.1.2

Utilidad de las direcciones privadas

Empresa Y147.156.0.0

Internet

147.156.1.10

NAT

147.156.1.10

130.15.12.27202.34.98.10

152.48.7.5

172.16.1.1

Rtr 172.16.1.1

Rtr 172.16.1.1

147.156.1.1

Rtr 147.156.1.1

Rtr 147.156.1.1

A B

Subredes

Dividen una red en partes mas pequeñas.

Nivel jerárquico intermedio entre red y host

‘Roba’ unos bits de la parte host para la subred.

Permite una organización jerárquica. Una red compleja (con subredes) es vista desde fuera como una sola red.

Dividamos la red 147.156.0.0 (clase B) en cuatro subredes:

147 . 156 Subred

Host

16 bits 2 bits 14 bits

Bits subred Subred Máscara Rango

00 (0) 147.156.0.0 255.255.192.0 147.156.0.0 – 147.156.63.255

01 (64) 147.156.64.0 255.255.192.0 147.156.64.0 – 147.156.127.255

10 (128) 147.156.128.0 255.255.192.0 147.156.128.0 – 147.156.191.255

11 (192) 147.156.192.0 255.255.192.0 147.156.192.0 – 147.156.255.255

Máscara: 11111111 . 11111111 . 11 000000 . 00000000

255 . 255 . 192 . 0

Ejemplo de Subredes

Subredes

La máscara identifica que parte de la dirección es red-subred y que parte es host.

Si la parte host es cero la dirección es la de la propia subred

La dirección con la parte host toda a unos esta reservada para broadcast en la subred

En cada subred hay siempre dos direcciones reservadas, la primera y la última.

Ejemplo: Red 156.134.0.0, máscara 255.255.255.0. 256 subredes identificadas por el tercer byte:

156.134.subred.host 156.134.subred.0 identifica la subred 156.134.subred.255 es el broadcast en la subred.

Subredes

Red 156.134.0.0, máscara 255.255.255.0 256 subredes (de 156.134.0.0 a 156.134.255.0) pero

¿Dirección 156.134.0.0 identifica red o subred? ¿Dirección 156.134.255.255 identifica broadcast en la red

o en la subred? Solución: no utilizar la primera y la última subred (las

que tienen el campo subred todo a ceros o todo a unos).

Esta norma se puede infringir (se hace a menudo) con la declaración de ‘subnet zero’.

Permite aprovechar mejor el espacio disponible (p. Ej. Red 147.156.0.0 con máscara 255.255.128.0).

Bitssubred

Nºsubredes

Nº subredes (subnet zero)

Bits host

Nº hosts

Máscara Último byte de la máscara en

binario

0 0 0 8 254 255.255.255.0 00000000

1 0 2 7 126 255.255.255.128 10000000

2 2 4 6 62 255.255.255.192 11000000

3 6 8 5 30 255.255.255.224 11100000

4 14 16 4 14 255.255.255.240 11110000

5 30 32 3 6 255.255.255.248 11111000

6 62 64 2 2 255.255.255.252 11111100

7 126 128 1 0 255.255.255.254 11111110

8 254 256 0 0 255.255.255.255 11111111

Posibles subredes de una red clase C

Subred Máscara Subred/bits

156.134.0.0 255.255.255.0 156.134.0.0/24

156.134.1.0 255.255.255.0 156.134.1.0/24

156.134.2.0 255.255.255.0 156.134.2.0/24

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

156.134.15.0 255.255.255.0 156.134.15.0/24

156.134.16.0 255.255.252.0 156.134.16.0/22

156.134.20.0 255.255.252.0 156.134.20.0/22

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

156.134.76.0 255.255.252.0 156.134.76.0/22

156.134.80.0 255.255.240.0 156.134.80.0/20

156.134.96.0 255.255.240.0 156.134.96.0/20

156.134.112.0 255.255.240.0 156.134.112.0/20

156.134.128.0 255.255.128.0 156.134.128/17

16 Subredes de 256 direcciones

16 Subredes de 1024 direcciones

3 Subredes de 4096 direcciones

Subred de 32768direcciones

Ejemplo de subredes con máscara de tamaño variable

158.42.20.12255.255.255.0

158.42.20.1255.255.255.0

158.42.30.1255.255.255.0

158.42.30.12255.255.255.0

A 158.42.30.0 255.255.255.0 por 192.168.1.2

192.168.1.1255.255.255.252

192.168.1.2255.255.255.252

A 158.42.20.0 255.255.255.0 por 192.168.1.1

Subred de cuatro direcciones

(192.168.1.0 - 192.168.1.3)158.42.30.25

255.255.255.0

Enrutamiento de dos subredes

LAN A 158.42.20.0

255.255.255.0

LAN B 158.42.30.0

255.255.255.0

X Y

147.156.176.7/20Rtr 147.156.176.1

147.156.176.1/20

147.156.183.5/20Rtr 147.156.176.1

147.156.191.12/20Rtr: 147.156.176.1

147.156.13.5/17Rtr 147.156.0.1

147.156.0.1/17

147.156.24.12/17Rtr 147.156.0.1

147.156.14.17/17147.156.14.24/17Rtr 147.156.0.1

Internet

192.168.0.1/30

192.168.0.2/30192.168.1.2/30

A 0.0.0.0/0 por 192.168.0.2

A 147.156.176.0/20 por 192.168.0.1A 0.0.0.0/0 por 192.168.1.1

192.168.1.1/30

Oficina Principal

147.156.0.0/17

Sucursal 147.156.176.0/20

A 147.156.0.0/16 por 192.168.1.2....................................................................................................

Conexión a Internet de oficina principal y sucursal configurando subredes

Host multihomed virtual

X

YZ

158.42.20.12/24

158.42.20.1/24 158.42.30.1/24

158.42.30.12/24

158.42.40.25/24158.42.30.25/32

A 158.42.30.0/24 por 192.168.1.2A 158.42.40.0/24 por 192.168.1.6A 158.42.30.25/32 por 192.168.1.6

192.168.1.1/30

192.168.1.2/30

A 0.0.0.0/0 por 192.168.1.1A 158.42.30.25/32 por 192.168.1.1

192.168.1.5/30

TokenRing

192.168.1.6/30

A 0.0.0.0/0 por 192.168.1.5A 158.42.30.25/32 158.42.40.25

158.42.40.1/24

Ejemplo de ruta host

Host multihomed

virtual

X Y

Z

W

LAN A 158.42.20.0/24

LAN B 158.42.30.0/24

LAN C 158.42.40.0

255.255.255.0

Superredes

Problema: agotamiento del espacio de direcciones IP.

Causa: Clase A inaccesible, Clase B excesiva, C demasiado pequeña. Muchas organizaciones solicitaban clases B y usaban solo una pequeña parte.

Solución: asignar grupos de clases C a una organización.

Nuevo problema: explosión de las tablas de rutas. Nueva solución: considerar un grupo contiguo de

redes clase C como una sola red. Hacer superredes.

Red Host

SubredesSuperredes

Las ‘superredes’ se definen mediante máscaras, igual que las subredes

Ej.: Red 195.100.16.0/21 (máscara 255.255.248.0)

Incluye desde 195.100.16.0 hasta 195.100.23.0

También se puede partir en trozos más pequeños partes de una clase A (de las que quedan libres). Por eso esta técnica se llama CIDR (Classless InterDomain Routing).

Superredes

Además de asignar grupos de redes C a las organizaciones se hace un reparto por continentes y países:

Multi regional: 192.0.0.0 - 193.255.255.255 Europa: 194.0.0.0 - 195.255.255.255 Otros: 196.0.0.0 - 197.255.255.255 Norteamérica: 198.0.0.0 - 199.255.255.255 Centro y Sudamérica: 200.0.0.0 - 201.255.255.255 Anillo Pacífico: 202.0.0.0 - 203.255.255.255 Otros: 204.0.0.0 - 205.255.255.255 Otros: 206.0.0.0 - 207.255.255.255

Así se pueden ir agrupando entradas en las tablas de rutas

CIDR (RFC 1466)

Asignación de direcciones IP

Las organizaciones obtienen sus direcciones IP del proveedor correspondiente

Los proveedores pequeños (tier-2 a tier-n) las obtienen de los proveedores grandes (tier-1)

Los proveedores grandes las obtienen de los registros regionales (RIR, regional internet registry)

Cada RIR dispone de una base de datos (whois) para búsqueda de direcciones IP

Registro Regional Área geográfica

ARIN (American Registry for Internet Numbers) www.arin.net

•América•Caribe•África Subsahariana

APNIC (Asia Pacific Network Information Centre) www.apnic.net

•Asia oriental•Pacífico

RIPE (Réseaux IP Européenes) www.ripe.net

•Europa•Medio Oriente•Asia Central•África Sahariana

Protocolos de Control de Internet

Permiten realizar labores diversas: ICMP (Internet Control Message

Protocol): mensajes de error y situaciones anómalas

ARP: Resolución de direcciones MAC RARP, BOOT, DHCP: Resolución de

direcciones IP IGMP: Gestión de grupos multicast

ICMP

Permite reportar diversas incidencias que pueden producirse en el envío de un datagrama.

Todos los mensajes ICMP se envían en datagramas IP (valor 1 en el campo protocolo).

Mensaje Explicación

Destination Unreachable (Destino inaccesible)

Red, host, protocolo o puerto (nivel de transporte) inaccesible o desconocidoDatagrama con bit DF puesto no cabe en la MTU

Source quench (apagar la fuente)

Ejerce control de flujo sobre el emisor en casos de congestión. No se utiliza.

Echo request y Echo reply

Sirve para comprobar la comunicación (comando ping).

Time exceeded (Tiempo excedido)

Datagrama descartado por agotamiento del TTL (usado en comando traceroute)

Redirect (Cambio de ruta)

El router nos sugiere un camino más óptimo

Principales mensajes de ICMP

Iluso_$ ping –s www.uv.es 64 4PING video.ci.uv.es: 64 bytes packets64 bytes from 147.156.1.46: icmp_seq=0. time=1. ms 64 bytes from 147.156.1.46: icmp_seq=1. time=1. ms 64 bytes from 147.156.1.46: icmp_seq=2. time=1. ms 64 bytes from 147.156.1.46: icmp_seq=3. time=1. ms ---video.ci.uv.es PING Statistics ----5 packets transmitted, 5 packets receivded, 0% packet lossRound-trip (ms) min/avg/max = 1/1/1

Iluso_$ ping –s www.cmu.edu 64 4PING server.andrew.cmu.edu: 64 bytes packets64 bytes from 128.2.72.5: icmp_seq=0. time=287. ms64 bytes from 128.2.72.5: icmp_seq=1. time=290. ms 64 bytes from 128.2.72.5: icmp_seq=2. time=285. ms 64 bytes from 128.2.72.5: icmp_seq=3. time=277. ms ---server.andrew.cmu.edu PING Statistics ----5 packets transmitted, 5 packets receivded, 0% packet lossRound-trip (ms) min/avg/max = 277/285/290

ICMP ECHO REQUEST y ECHO REPLY

Comando PING

Iluso_$ traceroute www.uniovi.estraceroute to dana.vicest.uniovi.es (156.35.34.1), 30 hops max,

40 byte packets 1 cisco.ci.uv.es (147.156.1.11) 3 ms 3 ms 2 ms 2 A1-0-2.EB-Valencia1.red.rediris.es (130.206.211.181) 2 ms 2 ms 2 ms 3 A1-0-2.EB-Madrid1.red.rediris.es (130.206.224.5) 8 ms 7 ms 7 ms 4 A3-0-1.EB-Oviedo1.red.rediris.es (130.206.224.34) 22 ms 17 ms 17 ms 5 rcpd02.net.uniovi.es (156.35.11.205) 16 ms 17 ms 16 ms 6 156.35.12.253 (156.35.12.253) 20 ms 19 ms 19 ms 7 rest34.cpd.uniovi.es (156.35.234.201) 24 ms 26 ms 26 ms 8 dana.vicest.uniovi.es (156.35.34.1) 28 ms 28 ms 28 msIluso_$

Comando Traceroute

ICMP TIME EXCEEDED

Resolución de direcciones

Normalmente el paquete del nivel de red se ha de enviar en una trama con una dirección de destino (p. ej. MAC en LANs). Dada la dirección de destino a nivel de red el emisor ha de saber que dirección de enlace le corresponde para ponerla en la trama.

Imaginemos que X quiere hacer ping a Y. Comparando la dir. IP de Y con la suya y con la máscara sabe que Y está en su misma LAN. Ha de meter el paquete IP en una trama Ethernet con una MAC de destino, pero no sabe cual poner.

147.156.1.1/16

147.156.1.4/16Rtr: 147.156.1.1

147.156.1.3/16Rtr: 147.156.1.1

147.156.1.2/16Rtr: 147.156.1.1

Internet

X Y Z130.206.211.5/30

A 0.0.0.0/0 por 130.206.211.6

W

Resolución de direcciones

Algunas soluciones empleadas para resolver el problema de la resolución de direcciones son las siguientes:

Fijar la dirección de enlace a partir de la de red. Ej.: en DECNET la dir. MAC se pone a partir de la de red. (se usan direcciones MAC locales)

Construir manualmente una tabla estática de equivalencias. Ej.: RDSI, X.25, FR, ATM.

Crear una tabla dinámica que se mantiene de forma automática en un servidor en el que se registra cada equipo. Ej.: ATM.

Lanzar una pregunta broadcast a la red para localizar al propietario de la dirección de red buscada. Solo se puede usar en las redes broadcast (LANs).Ej.: Protocolo ARP (Address Resolution Protocol).

1. El usuario X teclea ‘ping 147.156.1.3’

2. X genera ARP request (broadcast): ¿quién es 147.156.1.3?

3. Todos (Y, Z y W) capturan la pregunta y ‘fichan’ a X, es decir le incluyen en su ARP cache (esta parte es opcional).

4. Y responde ARP reply (unicast) diciendo que él es ese (y su dir. MAC)

5. X recoge la respuesta, la pone en su ARP cache y envía el ping

• La entrada ARP en X caduca pasados unos 15 minutos de inactividad• Cuando el mensaje es para una dirección de fuera el ARP de X busca al router;

si el router ya estaba en su ARP cache X le envía el ping directamente, sin más.

147.156.1.1/16

147.156.1.4/16Rtr: 147.156.1.1

147.156.1.3/16Rtr: 147.156.1.1

147.156.1.2/16Rtr: 147.156.1.1

Internet

X Y Z130.206.211.5/30

A 0.0.0.0/0 por 130.206.211.6

Funcionamiento de ARP

W

Se usa en todo tipo de LANs broadcast Especificado en RFC 826. Diseñado para soportar todo

tipo de protocolos y direcciones de red, no solo IP. ARP tiene sus propios paquetes (no usa los de IP). En

Ethernet usa Ethertype X’806’ (formato DIX). Los paquetes ARP contienen en la parte de datos las

direcciones IP y MAC; las direcciones MAC que aparecen en la trama MAC no deben utilizarse

ARP (Address Resolution Protocol)

Resolución inversa de direcciones

A veces se plantea el problema inverso al de ARP, es decir conocemos la MAC y queremos averiguar la IP que le corresponde. Ejemplos: Estaciones ‘diskless’ que al arrancar solo saben

su MAC. No tienen información de configuración. Red administrada de forma centralizada en la

que se quiere concentrar en un servidor la correspondencia IP-MAC para poder cambiar las IP cuando se quiera sin tener que tocar la máquina del usuario.

RARP (Reverse Address Resolution Protocol)

Debe haber un servidor en la red donde se registran todas las máquinas con su dir. MAC asignándole a cada una dir. IP

El host (cliente) que quiere saber su IP envía un mensaje broadcast; el mensaje llega al servidor RARP que busca en sus tablas y devuelve un mensaje con la dirección IP

RARP utiliza el Ethertype x’8035’ (distinto de ARP) Problemas de RARP:

Solo devuelve la dirección IP, no la máscara, router, MTU, etc.

El servidor RARP ha de estar en la misma LAN que el cliente

Tipo de hardware (1=Enet) Tipo de protocolo (800=IP)

Lon. Dir. Hard. (6) Lon. Dir. Red (4) Operación (1-2: ARP, 3-4: RARP)

Dir. MAC Emisor (octetos 0-3)

Dir. MAC Emisor (oct 4-5) Dir. IP emisor (octetos 0-1)

Dir. IP emisor (octetos 2-3) Dir. MAC destino (oct. 0-1)

Dir. MAC destino (octetos 2-5)

Dir. IP destino

32 bits

Formato de mensaje ARP y RARP para IP en Ethernet.

BOOTP (Bootstrap Protocol)

Función análoga a RARP, pero: Permite suministrar todos los parámetros de

configuración al cliente, no solo la dir. IP El servidor y el cliente pueden estar en LANs

diferentes. En la LAN del cliente debe haber un agente responsable de capturar la pregunta BOOTP (broadcast) para reenviarla al servidor remoto

A cada dirección MAC se le asigna una dirección IP de forma estática (correspondencia biunívoca)

Los mensajes BOOTP viajan en datagramas IP

Funcionamiento de BOOTP

El host cliente cuando arranca envía un ‘BOOTP request’ a la dirección 255.255.255.255 (broadcast en la LAN) con dirección de origen 0.0.0.0 (pues aun no sabe su IP)

El servidor recibe el mensaje, busca en su tabla la MAC del solicitante y si la encuentra prepara el ‘BOOTP reply’

Para enviar el BOOTP reply en unicast la MAC del cliente debe estar en la ARP cache del servidor, lo cual requiere que el cliente responda a un ARP request. Pero el cliente no puede responder pues aun no sabe su IP. Esto se resuleve de una de las dos maneras siguientes:

Enviar la respuesta en broadcast. Si el kernel lo permite el proceso BOOTP modifica

‘ilegalmente’ la tabla ARP y responde entonces en unicast.

A 165.12.32.5

A

Tabla BOOTP

A 165.12.32.5/24

Servidor BOOTP

4. b) B modifica su ARP cache para incluir en ella a A y le envía el BOOTP reply en unicast

BARP cache

Funcionamiento de BOOTP

1¿IP?

D.O.: 0.0.0.0 (A)D.D.: 255.255.255.255 (F)

2

¿A?

4 aIP 165.12.32.5/24

D.O.: 165.12.32.2 (B)D.D.: 255.255.255.255 (F)

165.12.32.2

4 bIP 165.12.32.5/24

D.O.: 165.12.32 (B)D.D.: 165.12.32.5 (A)(F): Dirección MAC broadcast

Dirección MAC

3

¿165.12.32.5?

1. A lanza BOOTP request en broadcast preguntando su IP

2. B busca en su tabla la MAC de A. Encuentra que su IP es 165.12.32.5

3. B no puede enviar un datagrama a 165.12.32.5 porque no esta en su ARP cache; tampoco puede enviar un ARP request pues A no responderá

4. a) B lanza BOOTP reply en broadcast, o bien

BOOTP con servidor remoto

Si el servidor BOOTP es remoto algún equipo de la LAN (normalmente un router) actúa como BOOTP relay y redirige las ‘BOOTP request’ al servidor

El router anota en el BOOTP request su dirección; así cuando vuelva el BOOTP reply sabe que lo ha de distribuir por broadcast

En la LAN del cliente tanto el BOOTP request como el reply viajan normalmente en tramas broadcast. En el resto de la red viajan en unicast (transporte UDP).

LAN A165.12.32.0/24

LAN B165.12.40.0/24

LAN C165.34.0.0/16

W X

U V Y

Tabla BOOTP

U 165.12.32.5/24

V 165.12.32.7/24

Y 165.34.56.3/16

Funcionamiento de BOOTP entre LANs

Z

165.12.32.1/24

165.12.40.1/24165.34.0.1/24

BOOTP requests a 165.34.0.2

165.12.40.2/24 Servidor BOOTP

local

Tabla BOOTP

W 165.12.40.3/24

X 165.12.40.7/24

192.168.1.1/30

192.168.1.2/30

A 165.34.0.0/16 por 192.168.1.2

A 165.12.32.0/24 por 192.168.1.1A 165.12.40.0/24 por 192.168.1.1

165.34.0.2/16 Servidor BOOTP local y remoto

DHCP (Dynamic Host Configuration Protocol)

Es como BOOTP pero en vez de dar direcciones IP ‘en propiedad’ las ‘alquila’.

El alquiler puede ser: Indefinido y estático (fijado por el administrador), equivale

a BOOTP. Automático (también estático, pero las da según le llegan

peticiones) Dinámico (se asigna la dirección de un pool).

Si la IP puede variar el nombre del ordenador también. Para asignar nombres permanentes el DHCP ha de interaccionar con el DNS (actualizaciones dinámicas).

Usa el mismo mecanismo broadcast que BOOTP para acceder a servidores en otras LANs

Es lo más parecido a la autoconfiguración

Parámetros BOOTP/DHCP

Dirección IP del cliente Hostname del cliente Máscara de subred Dirección(es) IP de:

Router(s) Servidor(es) de nombres Servidor(es) de impresión (LPR) Servidor(es) de tiempo

Nombre y ubicación del fichero que debe usarse para hacer boot (lo cargará después por TFTP)