IPv4 Fundamentos

UAX_Texto(01).
dot
Fundamentos de Redes de Comunicaciones
4. Nivel de red
pl
ap
la
DOCUMENTO1
ÍNDICE
MOTIVACIÓN ..................................................................... 3
PROPÓSITOS ..................................................................... 4
PREPARACIÓN PARA LA UNIDAD ........................................... 5
1. INTRODUCCIÓN Y SERVICIOS ........................................ 7
2. IP ............................................................................... 9
2.1. ESTRUCTURA DE IP ............................................................... 10
2.2. DIRECCIONES IP .................................................................... 11
2.2.1. CLASES DE DIRECCIONES ........................................................................ 12
2.2.2. MÁSCARA ........................................................................................... 15
2.3. MODOS DE DIRECCIONAMIENTO EN IPV4 .............................. 16
2.3.1. UNICAST ............................................................................................. 16
2.3.2. BROADCAST ......................................................................................... 18
2.3.3. MULTICAST .......................................................................................... 19
2.3.3.1. ENCAMINAMIENTO MULTICAST.................................................. 21
2.3.3.2. IGMP ........................................................................................ 21
2.3.4. ANYCAST ............................................................................................ 23
3. NAT .......................................................................... 24
4. SEGMENTACIÓN DE RED ......................................... 27
4.1. SUBREDES ............................................................................. 27
4.2. SUPERREDES ........................................................................ 29
5. IP Y LA CAPA DE ENLACE DE DATOS ......................... 31
5.1. TRADUCCIÓN DE DIRECCIONES LÓGICAS A DIRECCIONES
FÍSICAS .................................................................................. 31
1
5.2. TRADUCCIÓN DE DIRECCIONES FÍSICAS A DIRECCIONES
LÓGICAS ............................................................................... 32
6. ENCAMINAMIENTO ESTÁTICO EN IPV4 ..................... 37
7. ICMP EN IPV4 ........................................................... 41
7.1. CABECERA ICMP....................................................................... 41
7.2. TIPOS DE MENSAJES ICMP ......................................................... 42
7.2.1. MENSAJES DE ERROR ............................................................................ 42
7.2.2. MENSAJES DE CONSULTA ........................................................................ 44
CONCLUSIONES ................................................................. 45
RECAPITULACIÓN .............................................................. 46
PROPUESTAS DE AMPLIACIÓN ............................................. 47
BIBLIOGRAFÍA .................................................................. 49
2
MOTIVACIÓN
Saber cómo funcionan las direcciones IP y que alternativas existen para su uso
proporciona al alumno un poderoso conocimiento sobre el funcionamiento y la
organización de Internet.
3
PROPÓSITOS
El nivel de red, y más concretamente el protocolo que domina este nivel, IP, son
vitales para el funcionamiento de Internet tal y cómo se conoce hoy en día.
Conocer bien cómo funciona IP y el resto de protocolos que cohabitan este nivel
abrirá al alumno las puertas al conocimiento de cómo funciona Internet e incluso
empezar a poder planear el desarrollo de una pequeña red.
4
PREPARACIÓN PARA LA UNIDAD
El alumno deberá repasar las herramientas presentadas en el tema 1 de este

curso porque durante las explicaciones de los diferentes puntos del tema se hará
uso de ellas para ilustrar y clarificar la teoría expuesta.
Es importante que la máquina virtual está operativa para poder realizar los
ejemplos que se exponen.
5
1. INTRODUCCIÓN Y SERVICIOS
Al igual que en el tema anterior vamos a ver las funciones que pueden implementar
los protocolos que operen en la capa de red.
El protocolo de la capa de red define el formato de los paquetes que se van a
utilizar para transmitir la información que, en este nivel, se llaman datagramas.
Aunque en esta introducción vamos a hablar de protocolos

de nivel de red en genérico la verdad es que en este nivel el
protocolo principal y casi único es IP, en sus variantes IPv4
y IPv6.
Es objetivo de este tema el estudio de IPv4; IPv6 se dejará
para cursos posteriores.
Los protocolos del nivel de red pueden proporcionar o no los siguientes servicios.
Nótese que un protocolo puede implementar uno o varios servicios.
◼ Encapsulación: El protocolo toma los datos del nivel superior y lo
encapsula en un datagrama del nivel de red antes de hacérselo llegar al
nivel de enlace de datos.
◼ Fragmentación y reensamblado: El protocolo de red ha de ser capaz
de fragmentar la información que le llega del nivel superior para adaptarla
a sus necesidades y luego poder reensamblarla en el destino.
◼ Control de la conexión: El protocolo ha de ser capaz de establecer y
mantener una conexión entre emisor y receptor.
◼ Control de flujo: El protocolo ha de ser capaz de controlar la cantidad
de información que transmite por unidad de tiempo el emisor para no
saturar al receptor.
◼ Control de errores: El protocolo ha de ser capaz de detectar y
solucionar, si es posible, aquellos datagramas que lleguen con errores.
7
◼ Entrega ordenada: El protocolo ha de ser capaz de numerar los
fragmentos que transmite el emisor para que el receptor pueda
reordenarlos de forma correcta antes de reensamblarlos porque puede
darse en caso de que un datagrama llegue al destino antes que uno que
se ha transmitido anteriormente.
◼ Direccionamiento: El protocolo ha de ser capaz de identificar
unívocamente a emisor y receptor.
Las direcciones del nivel de red se conocen como

direcciones lógicas.
8
2. IP
Antes de empezar a entrar en materia con el protocolo IP (Internet Protocol) vamos
a ver unas características generales que son válidos tanto para IPv4 como para
IPv6.
La primera y más importante característica de IP es que es no orientado a
conexión, es decir, no se establece una conexión entre origen y destino por la
que van todos y cada uno de los datagramas, si no que cada uno de ellos se trata
como una unidad de datos independiente.
Esto implica que cada datagrama que envía el emisor puede seguir una ruta
distinta para llegar al receptor, pudiendo atravesar en el camino una o varias redes
de comunicaciones.
Aunque parezca contradictorio al ser un protocolo no orientado a conexión es
mucho más flexible y más tolerante a cambios en las condiciones de la red que si
se estableciera previamente una conexión de datos.
Al ser ambas implementaciones, IPv4 e IPv6, protocolos no orientados a conexión
cada datagrama ha de ser capaz de llegar desde el emisor al receptor atravesando
varias redes por lo que el propio datagrama ha de llevar toda la información
necesaria para realizar el encaminamiento cada vez que tenga que pasar a
través de una red.
Pero esto podría provocar que hubiera datagramas perdidos que, literalmente, se
perdieran y nunca pararan de dar vueltas por Internet. Para evitar esta situación a
cada datagrama se le asigna un tiempo de vida. Cada vez que atraviesa una red
se descuenta una unidad de su tiempo de vida y cuando llega a cero el datagrama
se descarta.
Otro problema que surge es que el datagrama puede, y normalmente lo hace,
atravesar redes de muy variado tipo y éste puede necesitar ser fragmentado de
nuevo en segmentos más pequeños o simplemente que lleguen desordenados.
El reensamblado de los datagramas se hace exclusivamente en el destino, de
ahí la necesidad de tener un identificador de secuencia para ayudar a realizarlo
correctamente
El control de errores, ya sea porque el mensaje ha sido descartado o bien porque
se ha producido algún tipo de corrupción en los datos es muy básico y
normalmente se limita a informar del emisor, cuando sea posible, de que se ha
producido un error en determinado datagrama.
Algo similar ocurre con el control de flujo ya que al ser no orientado a conexión lo
que puede hacer el protocolo es muy limitado. Se pueden enviar mensajes de
control de flujo intercalados con los datagramas de datos para comprobar el
estado del receptor.
9
2.1. ESTRUCTURA DE IP
En este tema vamos a examinar la versión 4 del protocolo IP (conocida
popularmente como IPv4) ya que la versión 6 es objeto de estudio en cursos
posteriores.
El protocolo IPv4 ofrece una serie de servicios para el envío y la recepción de
datos que requieren de una serie de parámetros.
Es más fácil verlos sobre la estructura de la cabecera IPv4 así que se estudiarán
haciendo referencia a los distintos campos presentes en la misma.
Imagen 1: Cabecera de IPv41
◼ Versión (4 bits): indica el número de la versión del protocolo, para

identificar la estructura del datagrama que se va a recibir. En IPv4 el valor
está fijado a 4.
◼ IHL (Internet Header Lenght, longitud de cabecera) (4 bits): longitud
de la cabecera expresada en palabras de 32 bits. El valor mínimo es de
cinco (20 octetos).
◼ Tipo de servicio (8 bits): inicialmente los parámetros de fiabilidad,
prioridad, retardo y rendimiento. Este campo era usado muy raramente
pero recientemente ha sido ha sido reformulado, tomando los 6 primeros
bits para los servicios diferenciados (DS, Differentiated Services) y los
otros 2 bits para el campo de notificación explícita de congestión (ECN,
Explicit Congestion Notification).
◼ Longitud total (16 bits): expresa la longitud total del datagrama, en
octetos.
◼ Identificador (16 bits): es un número de secuencia que, junto con la
dirección de origen, destino y el protocolo se utiliza para identificar de
forma única un datagrama.
1
Imagen cortesía de RFC-es.org (http://www.rfc-es.org/rfc/rfc0791-es.txt)
10
◼ Indicadores (Flags, 3 bits): solo los dos de estos bits se utilizan
actualmente. El primer bit está reservado y no debe utilizarse, estando
fijado a ‘0’. El segundo bit es el bit de “no fragmentación” que prohíbe la
fragmentación del datagrama cuando es “1”, pero si el datagrama excede
el tamaño al atravesar una red y este bit está fijado a “1” el datagrama
será descartado. El bit de “más datos” indica que el datagrama es parte
de una secuencia (si vale ‘1’) o si es el último (si está fijado a ‘0’) y se
utiliza para la fragmentación y reensamblado de los datagramas IP.
◼ Desplazamiento del fragmento (13 bits): indica dónde se ha de situar
el fragmento dentro de los datos que han llegado desde el nivel superior,
medido en unidades de 64 bits.
◼ Tiempo de vida (8 bits): especifica el tiempo de vida que tiene el
datagrama en saltos. Cada vez que se atraviesa una red distinta se resta
una unidad y cuando llega a cero el datagrama se descarta.
◼ Protocolo (8 bits): identifica el protocolo de la capa de transporte que va
a recibir el campo de datos del datagrama.
◼ Suma de comprobación de la cabecera (16 bits): es un código de
errores que sólo se aplica a la cabecera. Como esta puede variar en
cada salto se recalcula cada vez que varía.
◼ Dirección de origen (32 bits): dirección IP del emisor del mensaje.
◼ Dirección destino (32 bits): dirección IP del receptor o receptores del
mensaje.
◼ Opciones (variable): contiene las opciones solicitadas por el emisor del
mensaje.
◼ Relleno (variable): se usa para asegurar que la longitud de la cabecera
sea múltiplo de 32 bits.
◼ Datos (variable): campo de datos del datagrama. Aquí viaja la
información que IP ha recibido del protocolo del nivel superior. Debe ser
múltiplo de 8 bits y el valor máximo es de 65535 octetos.
2.2. DIRECCIONES IP
Las direcciones en IPv4 son de 32 bits y están compuestas por dos partes, una
que identifica la red a la que pertenece el equipo y otro que identifica al propio
equipo dentro de la red. Este espacio de direcciones proporciona un máximo
teórico de 232 direcciones, es decir, 4.294.967.296 direcciones
Para que un equipo sea utilizable dentro de una red debe

tener una dirección IP coherente con la red (parte del
identificador de red) y una parte de identificación de equipo
única en la misma.
11
Si además el equipo quiere ser visible en Internet esa
dirección ha de ser única en la red.
La dirección IP se suele anotar en cuatro octetos que se pueden representar en

formato binario o decimal, aunque por comodidad se prefiere la notación decimal.
Ejemplos de notación:
192.168.2.100
Dirección IP en notación decimal
11000000 10101000 00000010 01100100

Dirección IP en notación binaria
Imagen 2: Ejemplos de notación de direcciones IPv4
Es conveniente que el alumno llegue a cierto grado de habilidad en la conversión

de binario a decimal y para ayudar a ello se propone la siguiente tabla con los 8
bits de cada octeto y el valor que adopta la posición si el bit está a “1”.
x x x x x x x x
128 64 32 16 8 4 2 1
Imagen 3: Tabla resumen con el "peso" de cada bit
2.2.1. CLASES DE DIRECCIONES

En IPv4 hay distintas clases de red según el tamaño de la red y del número de
equipos que se quieran albergar en ella, desde una red de miles de equipos a
redes de un tamaño más modesto.
Para distinguirlas se utiliza el primer octeto de la dirección IP. Para distinguirlas y
ayudar a su comprensión se propone la siguiente tabla resumen:
12
Primeros
Rango Número de
bits del Número de
Clase primer equipos en la Uso
primer redes
octeto red
octeto
A 0xxx xxxx 0 – 127 128 16.777.216 Unicast
B 10xx xxxx 128 – 191 16.384 65.536 Unicast
C 110x xxxx 192 – 223 2.097.152 256 Unicast
D 1110 xxxx 224 – 239 1 268.435.456 Multicast
E 1111 xxxx 240 - 255 1 268.435.456 Reservado
Imagen 4: Tabla resumen de las clases de direcciones IPv4
En este tipo de direccionamiento para una dirección de clase A se utiliza el primer

octeto como identificador de red y los tres octetos restantes para identificar al
equipo. En una dirección de clase B se utilizan los dos primero octetos para
identificar a la red y los otros dos para identificar al host. Por otra parte en una
dirección de clase C se utilizan los tres primeros octetos para identificar a la red y
se deja al último octeto para identificar al equipo. Las direcciones de clase D y E
no se utilizan para identificar equipos individuales.
A continuación se muestran ejemplos de distintas direcciones de las clases A, B y
C. La parte de la dirección de red se coloca en color rojo y la parte del equipo en
verde:
◼ Clase A: 120.2.5.125, 10.32.0.34
◼ Clase B: 140.98.15.87, 188.77.1.22
◼ Clase C: 200.30.189.3, 221.122.45.99
Para identificar la red en su conjunto se conserva la parte de la dirección que

corresponde a la red y la parte de los equipos se colocan todos los bits a “0”. Por
ejemplo., para las redes de los ejemplos anteriores: 120.0.0.0, 10.0.0.0,
140.98.0.0, 188.77.0.0, 200.30.189.0, 221.122.45.0
Aparte hay una serie de direcciones IP que están reservadas que no pueden ser
utilizadas por nadie:
◼ 0.0.0.0 y 1.1.1.1 están reservadas para el protocolo BOOTP
◼ 127.0.0.1 es la dirección de loopback, es decir es una dirección interna
que corresponde al mismo equipo. Esta dirección se utiliza cuando desde
un equipo se quiere acceder a un servicio que proporciona el propio
equipo, así, en ese caso haciendo referencia a la dirección de loopback
las peticiones se redireccionan al equipo origen de las mismas.
13
Las direcciones IP se pueden configurar en Windows a través del "Centro de redes
y recursos compartidos" y en Linux mediante el comando ifconfig.
Imagen 5: Configuración de una dirección IP en Windows 7
Imagen 6: Configuración de una dirección IP en Linux
14
2.2.2. MÁSCARA
Para ayudar a distinguir entre la parte de la dirección de IP que corresponde a la
identificación de la propia red y la parte de que identifica a los equipos dentro de
la red se introdujo el concepto de máscara, que consiste en una serie de 1s en la
parte de la dirección que identifican la red seguidos de 0s en la parte del
identificador del equipo.
El concepto de máscara sólo aplica para direcciones de las

clases A, B y C.
En la siguiente tabla se muestran las máscaras por defecto para cada una de las
clases en tres notaciones, la binaria y decimal ya conocidas por el alumno y una
tercera nueva, reducida, consistente en una "/" seguida por el número de 1s que
tiene la máscara.
Clase Binario Decimal Reducida
A 11111111 00000000 00000000 00000000 255.0.0.0 /8
B 11111111 11111111 00000000 00000000 255.255.0.0 /16
C 11111111 11111111 11111111 00000000 255.255.255.0 /24

Imagen 7: Tabla de máscaras por defecto de cada clase
A partir de una dirección de un equipo y su máscara se puede conseguir la

dirección de red aplicando una operación lógica AND bit a bit entre ambas.
El direccionamiento con clases es muy estricto y como consecuencia se
desperdician direcciones IP, lo cual, unido al rápido crecimiento de Internet, ha
agotado las direcciones IP disponibles para nuevos equipos. Este ha sido, entre
otros, uno de los motivos para la migración a IPv6.
Si, en el momento de asignar la dirección IP, no se indica la máscara el sistema
siempre entenderá que se quiere usar la máscara por defecto de la clase a la que
pertenezca la dirección.
Gráficamente con una dirección clase A, en verde la asignación de la dirección y
en amarillo la máscara otorgada:
15
Imagen 8: Asignación de una dirección clase A
2.3. MODOS DE DIRECCIONAMIENTO EN IPV4

En IPv4 hay tres modos de direccionamiento según sea el destino del mensaje
que quiere enviar el emisor:
◼ Unicast o unidifusión: el emisor quiere enviar un mensaje a un y sólo
un destino. El datagrama va del equipo A al equipo B.
◼ Multicast o multidifusión: el emisor quiere enviar un mensaje a un
grupo concreto de equipos. El datagrama va del equipo A a un grupo
concreto de equipos.
◼ Broadcast o difusión: El emisor quiere enviar un mensaje a todos los
equipos de su red. El datagrama va del equipo A al resto de equipos de
la red donde esté conectado A.
También se va a hacer referencia a un tipo especial de direccionamiento, que

aunque no es uno propiamente dicho, también se usa en las redes de datos.
2.3.1. UNICAST
El direccionamiento unicast o unidifusión es simple, el equipo A quiere mandar un
mensaje al equipo B a través de la red. Un único mensaje parte del equipo A y
llega al equipo B.
Gráficamente:
16
RED
Imagen 9: Ejemplo de envío de un mensaje por unicast
Un ejemplo de un mensaje unicast se puede conseguir mediante el comando el

ping. A continuación se muestran dos imágenes, una desde el equipo que ejecuta
el ping y otra con la misma comunicación vista desde el wireshark.
Imagen 10: Captura de un ping
Imagen 11: Imagen del ping visto desde el Wireshark
17
2.3.2. BROADCAST
El concepto de envío de mensajes mediante broadcast o difusión es también muy
simple; la estación A quiere enviar un mensaje a todas las máquinas de la red a
la que está conectada.
Para evitar la saturación de Internet las peticiones de

broadcast nunca salen de la red donde se originan salvo
que los encaminadores se configuren específicamente para
permitirlo, situación que casi nunca se da.
Gráficamente:
RED
Imagen 12: Ejemplo de envío de un mensaje por broadcast
18
Para enviar un mensaje de broadcast también se puede hacer también con el
comando ping pero en la dirección de destino ha de ser la dirección de broadcast
de la red.
Para calcular la dirección de broadcast de una red basta

con, a partir de la dirección de red establecer a 1s todos los
bits correspondientes a la parte de equipos de la dirección.
Para el ejemplo que estamos utilizando la dirección de red es 192.168.2.0/24, así

que la parte de la dirección correspondiente a los equipos es el último octeto. Si
se coloca todo un octeto a 1s se obtiene el valor, en decimal, de 255, por lo que
la dirección de broadcast de la red es 192.168.2.255
Imagen 13: Captura de una petición de ping de broadcast
2.3.3. MULTICAST
Se ha dejado para el final el envío de mensajes por multicast o multidifusión por
dos motivos: es el más complicado de implementar de los tres y es el modo de
direccionamiento menos usado.
Multicast, al menos conceptualmente, es muy sencillo, el equipo A quiere mandar
un mensaje a un grupo concreto de equipos destino, todos ellos pertenecientes a
un mismo grupo multicast.
Gráficamente A quiere enviar un mensaje a los equipos pertenecientes al grupo
multicast G_1:
19
G_1
G_1
RED
G_1
G_1
Imagen 14: Ejemplo de envío de un mensaje de multicast
No hay que confundir entre multicast y una comunicación unicast múltiple. Cuando
se trata de unicast múltiple el equipo A genera tantos mensajes tipo unicast como
a destinatarios les tenga que hacer llegar el mensaje. Sin embargo en el caso de
multicast sólo se envía un mensaje que se va replicando cada vez que atraviesa
los encaminadores hasta llegar a todo los equipos pertenecientes al grupo.
Este método de funcionamiento supone una gran ventaja porque:
◼ Mejora la utilización del ancho de banda al eliminar el tráfico redundante.
◼ Permite tener menos carga de uso tanto en el host origen como en los
routers.
◼ Permite que no se tenga que conocer todas las direcciones IP de los
destinatarios simplemente basta con saber la IP del grupo multicast.
Algunos de los usos potenciales de multicast como modo de direccionamiento son:

◼ Acceso a base de datos distribuidas.
◼ Diseminación de la información entre múltiples destinatarios (por ejemplo
actualizaciones de software).
◼ Diseminación de noticias.
20
◼ Teleconferencias y teleformación.
2.3.3.1. ENCAMINAMIENTO MULTICAST

El mayor inconveniente de multicast es cómo puede construirse un algoritmo que
permita conocer el camino desde el origen hasta todos los destinos de un mensaje
multicast, porque cada router involucrado en la comunicación necesita construir
su propio camino a todos los grupos (normalmente en forma de un árbol).
Hay dos métodos para cubrir esta necesidad:
◼ Árbol basado en el origen: cada router almacena el árbol con el camino
más corto para cada grupo multicast que existe en la red.
Este algoritmo se conoce como SPT (Short Path Tree)
Ventajas: Se crea una ruta mínima entre el origen y todos los
participantes en el grupo multicast lo que garantiza un tiempo mínimo de
entrega de los mensajes.
Inconvenientes: Como cada router debe almacenar una tabla multicast
con todos los árboles de distribución para todos los grupos multicast en
el caso de redes muy grandes (como Internet) los recursos necesarios
tienden a infinito por lo que no es viable.
◼ Árbol compartido por el grupo: Existe un router núcleo, llamado RP
(Rendevouz Point), que es el único que almacena el árbol de distribución
de todos los grupos multicast de la red.
En este algoritmo, que se conoce como RPT (Rendevouz Point Tree), es
responsabilidad exclusiva del RP redistribuir los mensajes multicast entre
los miembros del grupo.
2.3.3.2. IGMP
El protocolo responsable de la gestión de los grupos multicast es IGMP (Internet
Group Management Protocol) que es el utilizado por los equipos para notificar su
pertenencia a determinado grupo.
Hay tres implementaciones del protocolo IGMPv1, IGMPv2 e IGMPv3 que son
acumulativas.
IGMPv1 fue la primera implementación del protocolo y fija la existencia de un
equipo, el querier, que es el encargado de conocer el estado de los destinatarios
de los mensajes multicast y normalmente es el router de la red.
IGMPv1 define dos tipos básicos de mensajes:
◼ IGMP Membership Queries: el querier pregunta a los equipos quién
pertenece a algún grupo multicast.
21
◼ IGMP Membership Report: los equipos que quieren participar en un
grupo multicast informan al querier de su pertenencia a determinado
grupo.
El principal problema de IGMPv1 es la no existencia de un mensaje de abandono

de grupo por lo que el querier sólo se entera cuando el equipo deja de responder.
Además los mensajes de pregunta son genéricos no pueden preguntar por grupos
específicos.
Para solucionar estos problemas se creó IGMPv2 que añade dos tipos más de
mensajes:
◼ IGMP Membership Queries v2: el querier puede preguntar ahora por
grupos específicos de multicast.
◼ IGMP Leave Group: los equipos pueden informar al querier cuando
abandonan el grupo.
IGMPv2 tenía una serie de deficiencias en materia de seguridad por lo que se hizo
un nuevo desarrollo IGMPv3 que no añade nuevos mensajes pero que incluye
medidas de seguridad.
La siguiente captura muestra los mensajes IGMP usados para comprobar la
pertenencia a grupos.
Imagen 15: Mensajes IGMP
Detalle del mensaje de consulta general de pertenencia a grupos (heredado de

IGMPv1):
Imagen 16: Mensaje de pertenencia a grupos
22
Imagen 17: Mensaje IGMP de pertenencia a grupo
2.3.4. ANYCAST
Este modo de direccionamiento no es muy común y, de hecho, normalmente ni se
menciona cuando se estudian porque no es más que una forma de mensaje
unicast a diferencia de cómo se comporta en IPv6, donde sí es un modo de
direccionamiento por derecho propio.
Cuando se envía un mensaje anycast el destino no va fijado previamente sino que
es el router de la red quien decide a quién se le envía, normalmente al router más
cercano al primero.
El uso de mensajes tipo anycast en IPv4 está casi reservado

a comunicación entre routers.
23
3. NAT
La primera de las soluciones que se propuso para paliar la escasez de direcciones
IP fue la creación del protocolo de traducción de direcciones de red NAT (Network
Address Translation).
Gran número de hogares y negocios pequeños usan Internet en su día a día.
Anteriormente sólo se podía conectarse a Internet a través de un ordenador y sólo
se necesitaba una dirección IP para el mismo, pero actualmente hay multitud de
dispositivos con capacidad de conectividad a Internet, ¿cómo conseguir que todos
esos dispositivos puedan acceder a Internet si cada uno de ellos necesita un
dirección IP propia?
NAT introduce el concepto de direcciones IP privadas que son unos rangos de
direcciones dentro de cada una de las clases que pueden ser utilizadas por
cualquier usuario sin necesidad de solicitar permiso a las autoridades de Internet
(cosa que si ocurre con las direcciones IP públicas) dentro de su red privada sin
conexión con Internet.
Los rangos de IP privadas se muestran en la siguiente tabla:
Clase Rango
A 10.0.0.0 a 10.255.255.255
B 172.16.0.0 a 172.31.255.255
C 192.168.0.0 a 192.168.255.255
Imagen 18: Tabla con los rangos de direcciones privadas
Por contraposición a las IP privadas estás las IP públicas que sí pueden usarse
para navegar por Internet pero requieren de la compra de tantas direcciones IP
públicas como equipos se quieran conectar directamente a Internet.
En apartados anteriores se ha comentado repetidamente que un equipo, para
poder conectarse en Internet, necesita una dirección única, y ahora además de
ser única esa dirección IP ha de ser pública, ¿cómo se consigue que una red con
direcciones IP privadas puedan conectarse a Internet?
NAT funciona con un equipo, normalmente llamado router NAT, que tiene una
dirección IP pública y otra dirección IP privada perteneciente a la misma red donde
están conectados el resto de equipos.
Gráficamente:
24
Dirección IP
Dirección IP privada
pública Direcciones IP
Internet privadas
ROUTER NAT
Imagen 19: Ejemplo de configuración con direcciones IP públicas y privadas
El router NAT realiza una traducción de las direcciones IP privada de los distintos
equipos de la red privada hacia la dirección IP pública del router, traducción que
hay tres maneras de realizar:
1. Usar una dirección IP:
 La tabla del router tiene dos columnas: IP destino y la IP origen
interno.
 Cuando un equipo de la red interna privada quiere conectarse con
un equipo de Internet almacena en la tabla la dirección IP a la que
quiere conectarse el equipo y la dirección IP interna del equipo
solicitante.
 Inconvenientes: Dos equipos no pueden solicitar comunicarse con
una misma dirección IP externa.
2. Usar un conjunto de direcciones IP:
 El router en lugar de tener una única dirección IP pública tiene
varias.
 Cada vez que un equipo interno quiere conectarse a Internet se le
asigna una IP pública mientras dure la conexión y cuando termina
se libera al dirección IP pública para que pueda ser usada por otro
host.
 La tabla está compuesta por las direcciones IP internas y la
dirección IP pública que tiene asignada al equipo interno
temporalmente.
 Inconvenientes: El número de conexiones simultáneas está
marcado por el número de IP públicas que tenga el router NAT.
3. Usar direcciones IP y número de puertos:
 El router almacena la IP destino, la IP origen interno junto con los
puertos y el protocolo que se utiliza en la conexión.
 Cuando un equipo interno quiere conectarse a un equipo de Internet
se almacena en una tabla las direcciones IP de la máquina destino,
el protocolo del nivel de transporte que se utiliza, el puerto del nivel
25
de transporte del destino junto con la dirección IP y el puerto de la
máquina origen.
 De esta manera se elimina la ambigüedad y no es necesaria una
gran cantidad de direcciones IP públicas.
En la gran mayoría de los hogares españoles se usa

direccionamiento privado para la red interna y un router NAT
para dar a los equipos acceso a Internet utilizando una única
dirección pública.
En el ejemplo de direcciones IP que se mostraron anteriormente las dos

direcciones usadas eran privadas; si el alumno quiere saber cuál es su dirección
IP pública puede usar una de las múltiples páginas disponibles en Internet como,
por ejemplo, http://www.cualesmiip.com
Imagen 20: IP pública del equipo2
2
Dirección IP obtenida gracias a http://www.cualesmiip.com
26
4. SEGMENTACIÓN DE RED
Otra solución que se adoptó para evitar que se desperdiciaran direcciones IP fue
la introducción de las subredes y las superredes y su uso con la máscaras de red
no estándares.
¿Qué ocurre si una organización necesita un número de

direcciones IP mayores que, por ejemplo, una clase C? ¿O
si no basta con una dirección clase B? ¿Cómo se
soluciona?
La idea en ambos casos es ajustar las direcciones IP públicas que se conceden a

una organización para evitar el desperdicio de direcciones.
4.1. SUBREDES
Si una organización disponía de varias redes independientes que tenían un
número elevado de equipos, con IP públicas, necesitaba de la concesión de varias
direcciones clase B y se desperdiciarían muchas de las mismas porque de las 256
máquinas que puede albergar una dirección de la clase C se salta a 65536
direcciones clase B.
El procedimiento de creación de las subredes está explicado en el RFC 9503 y
consiste en dividir una dirección, por ejemplo de clase B, en varios fragmentos
iguales para dar soporte a cada una de las redes en que se quiere dividir la
organización. Para ello la máscara aumenta su número de 1s con respecto a la
máscara por defecto de la clase.
Gráficamente una organización posee una dirección clase B:
3
El RFC se puede consultar en https://tools.ietf.org/html/rfc950
27
Red organización A
IP: 180.14.0.0/16
Imagen 21: Ejemplo de red que se quiere subdividir
Esta red se quiere dividir, por ejemplo, en dos subredes, así que se toma la
máscara y se amplía tantos bits como sean necesarios para dar cabida a las
subredes. En el ejemplo las 2 subredes se pueden codificar con 1 bit, así que la
máscara de las dos subredes será /17.
Ahora sólo queda asignar los valores del bit a cada una de las subredes que se
van a crear, 0 para una subred y 1 para la otra. Se representa gráficamente para
mayor comprensión, además se muestra el tercer octeto en binario y en decimal.
Subred 1 organización A
IP: 180.14.0.0/17
0000 0000
Red organización A
IP: 180.14.0.0/16
IP: 180.14.128.0/17
1000 0000
Imagen 22: Imagen de la red original y su división en dos subredes
El problema de este modo de creación de subredes se da cuando la organización

necesita subredes de tamaño distinto, por ejemplo, una subred de gran tamaño y
dos más pequeñas.
Con el método anterior no era posible porque todas las subredes que se creaban
debían tener el mismo tamaño, pero para eso se desarrollaron las máscaras de
28
subred de longitud variable, VLSM (Variable Lenght Subnetting Mask) que permite
la creación de subredes más pequeñas fragmentando otras subredes previamente
creadas. El procedimiento se describe en el RFC 18784.
El funcionamiento es muy parecido al caso anterior con la única diferencia en que
el usuario puede seguir particionando las subredes hasta que se adapten a las
necesidades de cada una de los departamentos de la organización.
Gráficamente, usando el mismo ejemplo anterior, (nótese como se ha
reparticionado el rango antes asignado a la subred 2 para la generación de dos
nuevas subredes más pequeñas):
IP: 180.14.0.0/17
0000 0000
Red organización A Subred 2 organización A

IP: 180.14.0.0/16 IP: 180.14.128.0/18
1000 0000
Subred organización A
IP: 180.14.128.0/17
1000 0000
IP: 180.14.192.0/18
1100 0000
Imagen 23: Imagen de la red original y su división en tres subredes utilizando

VLSM
4.2. SUPERREDES
La idea de las superredes es parecida a la de las subredes pero a la inversa, ya
que consiste en unir varias redes de una determinada clase (por ejemplo
direcciones clase C) para dar cabida a más equipos, desperdiciando siempre el
menor número posible de direcciones IP.
El procedimiento se especifica en el RFC 13385 y consiste en quitar 1s a la
máscara por defecto de la clase para unificar las direcciones de red concedidas,
que siempre han de ser contiguas.
En este caso una organización posee unas 500 máquinas que se requiere que
trabajen en la misma red. Antes de la existencia de las superredes la única opción
4
5
29
era la concesión de una dirección clase B, desperdiciándose más de 65000
direcciones.
Tras la implementación de las superredes surge la alternativa de la concesión de
dos direcciones clase C contiguas de manera que pueda crear una superred con
más capacidad.
Gráficamente:
Red organización A
Red organización A
IP: 200.40.192.0/24 SUPERRED
IP: 200.40.192.0/23
200.40.193.0/24
Imagen 24: Creación de una superred a partir de dos direcciones clase C
El uso tanto de subredes como de superredes ha perdido vigencia por la

introducción de NAT y las direcciones públicas y privadas pero se siguen usando
en organizaciones que quieren segmentar sus departamentos, porque son de
aplicación tanto si las direcciones IP que se utilizan son públicas o privadas.
30
5. IP Y LA CAPA DE ENLACE DE
DATOS
La relación entre las capas de red y de enlace es muy estrecha ya que una correcta
relación entre las direcciones lógicas (direcciones IP) y direcciones físicas
(direcciones MAC) es fundamental para que el equipo pueda conectarse a la red.
Internet está formada por un gran número de redes físicas conectadas entre sí por
una capa de abstracción que posibilita que se comuniquen entre sí. Esta
abstracción lo forman las direcciones lógicas.
Ahora bien, se necesitan protocolos que permitan traducir de direcciones físicas a
direcciones lógicas y viceversa de una forma rápida y sencilla.
Inicialmente existía una tabla estática que relacionaba las dos direcciones y que
estaba almacenada en cada máquina de la red.
¿Qué ocurriría si se estropea una tarjeta de la red?

Efectivamente habría que rehacer todas las tablas y volver a
distribuirlas por todo Internet, lo cual es muy ineficiente.
Es importante recordar que la traducción ha de realizarse en los dos sentidos.
5.1. TRADUCCIÓN DE DIRECCIONES LÓGICAS A

DIRECCIONES FÍSICAS
Para realizar la traducción de direcciones lógicas a direcciones físicas se usa el
protocolo de resolución de direcciones ARP (Address Resolution Protocol).
El funcionamiento del protocolo ARP es sencillo. Un equipo A quiere transmitir un
mensaje a un equipo B del que sólo conoce su dirección IP, pero para realizar la
transmisión por el medio físico necesita obligatoriamente conocer la dirección
física de B (su dirección MAC).
Antes de poder transmitir el mensaje propiamente dicho A transmite por su red a
todos el mundo (broadcast) una petición ARP indicando que está buscando un
nodo con la dirección IP que conoce (la de B). El equipo B al ver la petición
responde únicamente al equipo A (unicast) indicando cuál es la dirección física del
equipo B.
31
La respuesta se almacena temporalmente en la tabla ARP del equipo A y es usada
para toda la transmisión de datos. Al ser una tabla temporal (para evitar el
problema de un cambio de tarjeta de red) A borrará periódicamente su tabla.
La siguiente imagen muestra una captura de Wireshark del proceso de petición y
respuesta:
Imagen 25: Captura de Wireshark de petición y respuesta ARP
El alumno puede reproducir este comportamiento activando su Wireshark y

lanzando un ping desde un equipo a otro de la misma red. Antes de proceder al
envío de los ping siempre se podrá detectar los intercambios ARP.
5.2. TRADUCCIÓN DE DIRECCIONES FÍSICAS A

DIRECCIONES LÓGICAS
En este segundo escenario el equipo posee únicamente la dirección MAC pero no
tiene asignada todavía una dirección IP (necesaria si quiere comunicarse con
otros equipos), ¿cómo podría conseguirla de forma automática?
La primera aproximación al problema fue el protocolo RARP (Reverse ARP)
descrito en el RFC 9036.
En la red existía un servidor RARP que escuchaba las peticiones que enviaban
por broadcast los equipos. Cuando un equipo quería obtener una dirección IP
emitía un mensaje de petición RARP indicando su dirección física y el servidor
RARP consultaba su tabla y le indicaba en un mensaje unicast cuál era su
dirección IP.
El problema es que RARP sólo funciona en su segmento de red no pudiendo
atender peticiones de otras redes y sólo otorgaba direcciones IP a los equipos que
tenía registrados en su tabla. La inclusión de un nuevo equipo obligaba a modificar
la tabla, lo que implica un coste de mantenimiento.
No se ha de confundir RARP con el protocolo que permite a

partir de una dirección IP obtener el nombre de la máquina.
6
El RFC se puede consultar en http://tools.ietf.org/html/rfc903
32
La siguiente evolución fue el protocolo BOOTP (definido en el RFC 9517) que sí
era capaz de atender peticiones de distintas redes pero que, internamente, se
comportaba de forma similar a RARP.
El equipo que deseaba una dirección IP lanzaba por broadcast una petición
BOOTP pero como no tenía todavía dirección lógica usaba 1.1.1.1 como dirección
de destino y 0.0.0.0 como dirección de origen. El servidor BOOTP recibía la
petición, comprobaba su tabla de asignación y respondía al equipo solicitante con
la dirección IP que tenía registrada en la tabla.
El problema es que la tabla de direcciones en BOOTP tenía que seguir siendo
configurada manualmente y el mantenimiento de esa tabla era muy costoso
porque cada vez más equipos se unían a la red o cambiaban su ubicación.
Con intención solucionar este problema se desarrolló el protocolo DHCP (Dynamic
Host Configuration Protocol), para la asignación de direcciones de forma dinámica,
aunque sigue permitiendo la asignación estática de direcciones para permitir la
retro compatibilidad con BOOTP. El protocolo DHCP se encuentra definido en el
RFC 21318)
El funcionamiento de DHCP es similar a los anteriores, al menos al principio. El
equipo que necesita una dirección IP realiza una petición DHCP por broadcast que
es recogida por el servidor DHCP, quien consulta en su tabla dinámica de
asignación para determinar cuál es la siguiente dirección IP que tiene disponible
para asignársela al equipo A por un tiempo determinado, pasado el cual el
equipo debe renovar su dirección porque el servidor DHCP la marcará como
disponible.
Especificando concretamente los pasos de una petición y concesión de una
dirección IP usando el protocolo DHCP:
1. El cliente envía un mensaje tipo DHCP DISCOVER por broadcast.
2. El servidor DHCP recibe el paquete DHCP DISCOVER y ofrece la primera
dirección IP disponible mediante un mensaje tipo DHCP OFFER.
3. El cliente recibe el mensaje DHCP OFFER y contesta con un DHCP
REQUEST aceptando la dirección IP ofrecida.
4. El servidor recibe el mensaje y confirma la concesión oficialmente
mediante un mensaje DHCP ACK.
La imagen muestra una captura de Wireshark del proceso y detalle de la

respuesta:
Imagen 26: Captura del proceso de una solicitud y concesión DHCP
7
8
El RFC se puede consultar en https://www.ietf.org/rfc/rfc2131.txt
33
Imagen 27: Detalle del OFFER de proceso DHCP
Imagen 28: Detalle del ACK del proceso DHCP
Visto desde el cliente (nótese la concesión de la dirección IP por 30min):
34
Imagen 29: Captura de la concesión de una dirección IP por DHCP
Resumiendo DHCP admite dos modos de funcionamiento:

◼ Asignación estática de direcciones: DHCP permite que, para
determinados equipos, se les asigne siempre la misma dirección IP. Este
comportamiento asegura la compatibilidad con BOOTP.
◼ Asignación dinámica de direcciones: DHCP tiene un conjunto de
direcciones (también conocida como pool) disponibles para ser
asignadas a los equipos que así lo soliciten. Esta dirección podrá ser
diferente, o no, cada vez que el equipo se conecte a la red.
Además de la dirección IP, el protocolo DHCP también permite que el equipo

obtenga también la máscara de la red, la puerta de enlace predeterminada y la/s
dirección/es de los servidores DNS.
DHCP es el protocolo de asignación dinámica de

direcciones que se utiliza actualmente.
Junto con la dirección IP se otorga, normalmente, la
máscara, la dirección de la pasarela y los DNS. Estos datos
permiten al equipo ser operativo en Internet.
Recuperando el ejemplo anterior pero concentrando la atención en el mensaje de

ofrecimiento del protocolo DHCP:
35
Imagen 30: Detalle de todos los parámetros otorgados por DHCP
36
6. ENCAMINAMIENTO ESTÁTICO EN
IPV4
El uso de direcciones IP permite que redes distintas compartan mensajes entre sí,
cosa imposible con las direcciones físicas (MAC) pero se debe configurar los
elementos de unión entre las redes, llamados encaminadores, enrutadores o
routers para que sean capaces de realizar correctamente el tránsito entre las dos
redes.
El encaminamiento estático soluciona este problema creando una tabla estática,
llamada tabla de encaminamiento, para que el router sea capaz de transmitir
mensajes de una red a otra.
Un ejemplo con una tabla muy básica pero que puede servir para ilustrar los
fundamentos del encaminamiento estático:
RED1 RED3
Internet RED2
Router2
Router1
RED4
DESTINO RUTA
RED1 DIRECTA
RED2 DIRECTA
RED3 ROUTER2
RED4 ROUTER2
RED5 ROUTER2
RED6
RED6 ROUTER2
Por omisión DIRECTA Router3
RED5
Imagen 31: Imagen de una red con una tabla de encaminamiento estático
Es muy importante que el alumno se dé cuenta que incluso

cuando el Router 1 quiere acceder a las redes más alejadas
nunca puede conocer más que el encaminador al que está
conectado directamente a través de una red.
Esto quiere decir que, en el ejemplo, el Router 1 no puede
hacer nunca referencia al Router 3 en su tabla de rutas.
37
Además cada vez que configuremos un router debemos establecer siempre la
ruta por defecto, o ruta por omisión, que es la que utilizará el enrutador cuando no
sea capaz de resolver hacia donde debe enviar un mensaje que le ha llegado por
alguno de sus interfaces.
Normalmente esta ruta por defecto se llama puerta de enlace predeterminada y
suele configurarse para que utilice el camino hacia Internet.
La tabla se compone con una serie de direcciones de red con la máscara que se
utiliza, el interfaz que se ha de utilizar (por si el equipo tiene varios) y, muy
importante la pasarela (conocida también como siguiente salto) si para llegar a
una red es necesario hacerlo a través de otro router.
La estructura de la tabla (el orden de la tabla puede variar) contiene los siguientes
campos: Dirección IP de la red destino, máscara de la red destino, puerta de
enlace (si es necesaria) y la interfaz (la del propio router).
Ejemplo de una tabla de rutas de un equipo:
Imagen 32: Tabla de rutas de un equipo
Se va a desarrollar un ejemplo de una red y se va a generar paso a paso la tabla

de encaminamiento del router 2.
Internet 192.168.2.0 /24

eth1:
eth0 192.168.2.1
Router 1
eth0:
192.168.2.200
eth2:
172.25.200.200
Router 2 172.25.0.0 /16
eth1:
10.14.200.200
eth0:
10.14.0.1
Router 3 10.14.0.0 /16
eth1:
192.168.10.1
192.168.10.0 /24
Imagen 33: Red ejemplo
38
Inicialmente la tabla está vacía:
Dirección IP de Máscara de la red

Puerta de enlace Interfaz
la red destino destino
Imagen 34: Tabla inicial del router R1
1. Se identifica las redes a las que está conectado el router 2 directamente

y se reflejan en la tabla de encaminamiento. Como son redes directas no
se necesita puerta de enlace:

192.168.2.0 255.255.255.0 o /24 eth0
10.14.0.0 255.255.0.0 o /16 eth1
172.25.0.0 255.255.0.0 o /16 eth2

Imagen 35: Tabla de encaminamiento del router R1 tras conocer a sus router
vecinos
2. Se identifican el resto de redes que existen en la organización pero que

no están conectadas al router 2. En este segundo paso sí se necesita
indicar la puerta de enlace del router:

192.168.2.0 255.255.255.0 o /24 eth0
10.14.0.0 255.255.0.0 o /16 eth1
172.25.0.0 255.255.0.0 o /16 eth2
192.168.10.0 255.255.255.0 o /24 R3 (10.14.0.1) eth1

Imagen 36: Tabla de encaminamiento de router R1 para acceder al resto de
redes
3. El tercer y último paso es indicar cuál será la ruta por defecto y la puerta
de enlace adecuada:
39
192.168.2.0 255.255.255.0 o /24 eth0
10.14.0.0 255.255.0.0 o /16 eth1
172.25.0.0 255.255.0.0 o /16 eth2
192.168.10.0 255.255.255.0 o /24 R3 (10.14.0.1) eth1
0.0.0.0 o default 0.0.0.0 o /0 R1 (192.168.2.1) eth0

Imagen 37: Tabla de encaminamiento final de router R1
El mantenimiento de las tablas se ha de hacer manualmente lo que conlleva un

gran coste asociado cuando las redes, por ejemplo si están activas o no, cambian
de una forma más o menos constante como pasa en Internet. Para evitar este
inconveniente se desarrollaron los protocolos de encaminamiento dinámico.
40
7. ICMP EN IPV4
Un protocolo como IP que proporciona un envío de datagramas no fiable y no
orientado a conexión casi obliga a la existencia de otro protocolo que complemente
las carencias de IP, sobre todo en lo referido a control de errores.
Para ello se diseñó el protocolo de control de mensaje de Internet, más conocido
como ICMP (Internet Control Message Protocol).
ICMP cohabita en el mismo nivel que IP pero usa sus servicios para el envío de
los mensajes ICMP, ya que estos mensajes se encapsulan y envían en
datagramas IP.
Nivel de aplicación
Nivel de transporte
ICMP IGMP
IP
ARP
Nivel de enlace
Nivel físico
Imagen 38: Ubicación del protocolo ICMP dentro del nivel de red
ICMP tiene dos tipos básicos de mensajes:

◼ Mensajes de error: informan de problemas que un equipo encuentra
cuando se procesa un datagrama IP.
◼ Mensajes de consulta: se envían entre iguales y ayudan a los equipos
a descubrir elementos de la red, vecinos, etc.
7.1. CABECERA ICMP

Los mensajes ICMP constan de una cabecera fija de 8 bytes junto con una sección
de datos de tamaño variable.
41
Imagen 39: Cabecera de ICMP9
Los campos de la cabecera son:

◼ Tipo (8 bits): especifica el tipo de mensaje ICMP.
◼ Código (8 bits): se usa para especificar parámetros del mensaje que se
pueden codificar en uno o pocos bits.
◼ Suma de comprobación (16 bits): es la suma de comprobación del
mensaje ICMP completo.
◼ Parámetro (32 bits): se usa para especificar parámetros más largos.
7.2. TIPOS DE MENSAJES ICMP

Antes se ha dicho que hay dos tipos básicos, mensajes de error y mensajes de
consulta. A continuación se van a especificar los tipos concretos englobados en
esos dos tipos antes mencionados.
Independientemente del tipo de mensaje todos presentan la misma cabecera.
7.2.1. MENSAJES DE ERROR
No se generan nunca mensajes de error ICMP cuando:

1. En respuesta a otro mensaje de error ICMP.
2. En respuesta a un datagrama IP fragmentado que
no sea el primer fragmento.
3. En respuesta a un mensaje multicast.
4. En respuesta a un datagrama de las redes
reservadas.
9
Imagen cortesía de RFC-es.org (http://www.rfc-es.org/rfc/rfc0792-es.txt)
42
Los mensajes ICMP de error son:
◼ Destino inalcanzable: se envía cuando el destino al que se le quiere
hacer llegar un datagrama no se encuentra disponible.
Imagen 40: Captura de un mensaje ICMP de error por destino inalcanzable
◼ Tiempo excedido: se envía cuando el tiempo de vida del datagrama ha

excedido o si el datagrama no ha podido ser reensamblado a tiempo en
el destino.
Imagen 41: Imagen del mensaje ICMP de error por tiempo excedido
◼ Problema de parámetro: un error en la cabecera de un datagrama IP

devolverá este tipo de mensaje ICMP.
◼ Ralentización de origen: proporciona un control de flujo muy
rudimentario. Cuando el emisor recibe un mensaje de este tipo, sea un
router o el destino quien lo envía, debe ralentizar la tasa de envío de los
mensajes. Este mensaje se suele enviar cuando se produce congestión
en la red.
◼ Redirección: se envía, por parte de un router, al emisor del datagrama
IP indicando que existe una ruta mejor para un destino en concreto.
43
7.2.2. MENSAJES DE CONSULTA
Los mensajes ICMP de consulta son:
◼ Eco y Respuesta a eco: proporcionan un mecanismo para comprobar
que la comunicación entre emisor y receptor es posible. Es,
posiblemente, el menaje ICMP más conocido.
Imagen 42: Imagen de mensaje ICMP de consulta por eco
Imagen 43: Captura de wireshark de los mensajes ICMP de consulta por eco y
respuesta de eco
◼ Marca de tiempo y Respuesta a marca de tiempo: proporcionan un

mecanismo para muestrear las características en cuanto al retardo de la
comunicación entre emisor y receptor.
◼ Petición de máscara de dirección y Repuesta de máscara de
dirección: se utilizan en entorno de subredes y superredes para que el
equipo conozca la máscara de la red a la que está conectado.
44
CONCLUSIONES
El nivel de red es, sin duda alguna, el más conocido de todos los que componen
la pila de protocolos TCP/IP porque quien más y quien menos ha oído hablar de
las direcciones IP.
Además conocer la estructura del protocolo es vital para poder aprovechar su gran
potencia.
De forma similar puede el alumno explotar sus conocimientos con la creación de
subredes y NAT, además de proporcionarle las herramientas necesarias para
comprobar, gracias al protocolo ICMP, el estado de los equipos de una red.
45
RECAPITULACIÓN
IP es el protocolo por excelencia, aunque no el único, de la capa de nivel de red.

Existen 2 versiones del protocolo, IPv4 e IPv6, pero sólo IPv4 se ha tratado en el
tema.
IPv4 usa direcciones de 32 bits que se dividen en 5 clases (A, B, C, D y E) que se
usan de manera distinta según sea las necesidades de la red a la que se quiere
dar servicio.
Además IPv4 divide sus direcciones en 2 tipos: públicas, que pueden ser utilizadas
en Internet, y privadas, que sólo pueden usarse en redes internas.
IPv4 ha agotado prácticamente sus direcciones IP públicas y se han adoptado
distintas estrategias para intentar alargar la disponibilidad de las restantes: NAT y
la segmentación de redes (subredes y superredes).
Además se ha estudiado como se relaciona este nivel con la capa de enlace (en
las dos direcciones), de IP a MAC usando el protocolo ARP y para conseguir una
dirección IP automáticamente teniendo sólo una dirección MAC con el protocolo
DHCP.
Pero para comunicar redes distintas no basta con tener direcciones IP, hace falta
tener un encaminador que las una y poder configurarle para que realice el
enrutamiento.
46
PROPUESTAS DE AMPLIACIÓN
Las posibilidades a ampliación de un tema como este referido al nivel de red son
inabarcables pero en este epígrafe se va a centrar en algunos puntos que se
consideran interesantes para los alumnos.
El primer apartado es el estudio de las direcciones de IPv4, sobre todo en la
relación entre IP públicas y privadas cuando se usa NAT dentro de una red LAN.
También se recomienda la ampliación del estudio de la segmentación de subredes
y superredes porque pueden ser de aplicación cuando se diseña una red local.
Otro punto de estudio es la asignación dinámica de direcciones IP mediante el uso
de protocolo DHCP y podría ser de interés para el alumno establecer la
configuración de un sistema para que opere como servidor DHCP.
47
BIBLIOGRAFÍA
La bibliografía de este tema:

◼ Comunicaciones y redes de computadoras. 7ª Edición. Capítulo 18.
[Autor] William Stallings
[Editorial] Pearson Educación S.A.
◼ Transmisión de datos y redes de comunicaciones. 4ª Edición. Parte
4.
[Autor] Behrouz A. Forouzan
[Editorial] Mc Graw Hill
◼ Redes de computadores: Un enfoque descendente. 5ª Edición.
Capítulo 4
[Autor] James F. Kurose y Keith W. Ross
◼ Redes de computadoras. 4ª Edición. Tema 5
[Autor] Andrew S. Tanenbaum
49

IPv4 Fundamentos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

IPv4 Fundamentos

Cargado por

Copyright:

Formatos disponibles

UAX_Texto(01).

Fundamentos de Redes de Comunicaciones

El alumno deberá repasar las herramientas presentadas en el tema 1 de este

Aunque en esta introducción vamos a hablar de protocolos

Las direcciones del nivel de red se conocen como

Imagen 1: Cabecera de IPv41

◼ Versión (4 bits): indica el número de la versión del protocolo, para

Para que un equipo sea utilizable dentro de una red debe

La dirección IP se suele anotar en cuatro octetos que se pueden representar en

11000000 10101000 00000010 01100100

Imagen 2: Ejemplos de notación de direcciones IPv4

Es conveniente que el alumno llegue a cierto grado de habilidad en la conversión

2.2.1. CLASES DE DIRECCIONES

A 0xxx xxxx 0 – 127 128 16.777.216 Unicast

B 10xx xxxx 128 – 191 16.384 65.536 Unicast

C 110x xxxx 192 – 223 2.097.152 256 Unicast

D 1110 xxxx 224 – 239 1 268.435.456 Multicast

E 1111 xxxx 240 - 255 1 268.435.456 Reservado

Imagen 4: Tabla resumen de las clases de direcciones IPv4

En este tipo de direccionamiento para una dirección de clase A se utiliza el primer

Para identificar la red en su conjunto se conserva la parte de la dirección que

Imagen 5: Configuración de una dirección IP en Windows 7

Imagen 6: Configuración de una dirección IP en Linux

El concepto de máscara sólo aplica para direcciones de las

Clase Binario Decimal Reducida

A 11111111 00000000 00000000 00000000 255.0.0.0 /8

B 11111111 11111111 00000000 00000000 255.255.0.0 /16

C 11111111 11111111 11111111 00000000 255.255.255.0 /24

A partir de una dirección de un equipo y su máscara se puede conseguir la

2.3. MODOS DE DIRECCIONAMIENTO EN IPV4

También se va a hacer referencia a un tipo especial de direccionamiento, que

Imagen 9: Ejemplo de envío de un mensaje por unicast

Un ejemplo de un mensaje unicast se puede conseguir mediante el comando el

Imagen 10: Captura de un ping

Imagen 11: Imagen del ping visto desde el Wireshark

Para evitar la saturación de Internet las peticiones de

Imagen 12: Ejemplo de envío de un mensaje por broadcast

Para calcular la dirección de broadcast de una red basta

Para el ejemplo que estamos utilizando la dirección de red es 192.168.2.0/24, así

Imagen 13: Captura de una petición de ping de broadcast

Algunos de los usos potenciales de multicast como modo de direccionamiento son:

2.3.3.1. ENCAMINAMIENTO MULTICAST

El principal problema de IGMPv1 es la no existencia de un mensaje de abandono

Imagen 15: Mensajes IGMP

Detalle del mensaje de consulta general de pertenencia a grupos (heredado de

Imagen 16: Mensaje de pertenencia a grupos

El uso de mensajes tipo anycast en IPv4 está casi reservado

Imagen 19: Ejemplo de configuración con direcciones IP públicas y privadas

En la gran mayoría de los hogares españoles se usa

En el ejemplo de direcciones IP que se mostraron anteriormente las dos

Imagen 20: IP pública del equipo2

¿Qué ocurre si una organización necesita un número de

La idea en ambos casos es ajustar las direcciones IP públicas que se conceden a

Imagen 21: Ejemplo de red que se quiere subdividir

Imagen 22: Imagen de la red original y su división en dos subredes

El problema de este modo de creación de subredes se da cuando la organización

Red organización A Subred 2 organización A

Imagen 23: Imagen de la red original y su división en tres subredes utilizando

Imagen 24: Creación de una superred a partir de dos direcciones clase C

El uso tanto de subredes como de superredes ha perdido vigencia por la

¿Qué ocurriría si se estropea una tarjeta de la red?

Es importante recordar que la traducción ha de realizarse en los dos sentidos.

5.1. TRADUCCIÓN DE DIRECCIONES LÓGICAS A