Direccionamiento

Direccionamiento e
Fernando Boronat Seguí,

es Doctor Ingeniero de Telecomunicación
por la Universitat Politècnica de
interconexión de redes
València (UPV) y Profesor Titular del
Departamento de Comunicaciones de
dicha Universidad. Actualmente imparte
docencia sobre redes, protocolos y
basada en TCP/IP
ISBN 978-84-9048-037-3
servicios de comunicaciones en el
Grado de Ingeniería de Sistemas de
Telecomunicación, Sonido e Imagen,
que se imparte en el Campus de Gandia,
(IPV4/IPV6, DHCP, NAT, Encaminamiento RIP y OSPF) perteneciente a la UPV.
Direccionamiento e interconexión de redes basada en TCP/IP

Direccionamiento e interconexión de Fernando Boronat Seguí Mario Montagud Climent,
es Graduado en Ingeniería de Sistemas
redes basada en TCP/IP Mario Montagud Climent de Telecomunicación, Sonido e
(IPV4/IPV6, DHCP, NAT, Encaminamiento RIP y OSPF) Imagen y Máster Oficial de Posgrado
en Tecnologías, Sistemas y Redes de
Comunicación, ambos títulos obtenidos
en la UPV. Actualmente está realizando
Fernando Boronat Seguí el Doctorado bajo la supervisión del
Mario Montagud Climent profesor Fernando Boronat Seguí.
Este libro presenta la problemática del direccionamiento e Ambos trabajan actualmente en el área
interconexión de redes de datos, centrándose en la solución temática de las Redes de Ordenadores y
aportada por la pila de protocolos TCP/IP. Comunicaciones Multimedia.
En primer lugar se aborda, de manera general, la problemática
de la interconexión de redes de datos heterogéneas según
diversos factores como, por ejemplo, el tipo de servicio
ofrecido, las técnicas de encaminamiento a utilizar, tamaño
de los paquetes de datos, notificación de errores, etc. A
continuación, se centra en la solución más extendida hoy
en día en Internet, como es la ofrecida por la familia de
protocolos TCP/IP.
El libro describe con detalle las dos versiones del protocolo
IP, la versión 4 (IPv4) y la 6 (IPv6), así como protocolos
complementarios, como ARP e ICMP. Además, se profundiza en
diversos aspectos, como son la división de redes IP en subredes
(subnetting), así como su agregación (CIDR), la asignación de
direcciones IP mediante DHCP o BootP, el direccionamiento
público y privado, la traducción de direcciones mediante NAT
y, finalmente, también se aborda el encaminamiento en redes
IP, profundizando en dos de los protocolos más utilizados en
Internet, como son RIP y OSPF.
EDITORIAL
EDITORIAL UNIVERSITAT POLITÈCNICA DE VALÈNCIA

Los contenidos de esta publicación han sido revisados por el Departamento de
Comunicaciones de la UPV
Colección Académica
Para referenciar esta publicación utilice la siguiente cita: BORONAT, F. y MONAGUD, M.

(2013) Direccionamiento e interconexión de redes basada TCP/IP; IPV4/IPV6, DHC, NAT,
ENCAMINAMIENTO RIP Y OSPF. Valencia: Universitat Politècnica
Primera edición, 2013 (versión impresa)

Primera edición, 2013 (versión electrónica)
© Fernando Boronat
Mario Montagud
© de la presente edición: Editorial Universitat Politècnica de València
Distribución: pedidos@editorial.upv.es /
Telf.: 96 387 70 12/ www.editorial.upv.es / Ref.: 6113
ISBN: 978-84-9048-037-3 (versión impresa)

ISBN: 978-84-9048-061-8 (versión electrónica)
Queda prohibida la reproducción, la distribución, la comercialización, la

transformación y, en general, cualquier otra forma de explotación, por
cualquier procedimiento, de la totalidad o de cualquier parte de esta
obra sin autorización expresa y por escrito de los autores.
Acrónimos
Acrónimos
- ABR: Routers de Borde (fronterizos) de Área (Area Border Routers).

- AfriNIC: African Network Information Centre.
- ANS: Advanced Network and Services.
- APNIC: Asia-Pacific Network Information Centre.
- ARIN: American Registry for Internet Numbers.
- ARP: Protocolo de Resolución de Direcciones (Address Resolution Proto-
col).
- ARPA: Advanced Research and Projects Agency.
- ASBR: Routers de Borde (fronterizos) de un Sistema Autónomo (Auto-
nomous System Border Routers).
- BER: Tasa de Error de Bit (Bit Error Rate).
- BMA: Red de Acceso Múltiple con Broadcast (Broadcast Multiple-Access
Network).
- BOOTP: Bootstrap Protocol.
- BSD: Berkeley Software Distribution.
- CL: Sin Conexión (Connectionless).
- CIDR: Encaminamiento entre Dominios Sin Clase (Classless Inter-Domain
Routing).
- CO: Orientado a la conexión (Connection Oriented).
- CV: Circuito Virtual.
- CVP: Circuito Virtual Permanente.
- DCA: Agencia de Comunicación de Defensa (Defense Communication
Agency).
- DHCP: Dynamic Host Configuration Protocol.
- DNS: Sistema de Nombres de Dominio (Domain Name System).
- DRI: Defense Research Internet.
- EBONE: European Backbone.
- EUI: Identificador Único Extendido (Extended Unique Identifier).
33
Acrónimos
- FTP: File Transfer Protocol.

- HLEN: Longitud de la Cabecera o (Header length).
- HTTP: HyperText Transfer Protocol
- IAB: Junta de Arquitectura de Internet (Internet Activity Board).
- IANA: Internet Assigned Numbers Authority.
- IEEE: Instituto de Ingenieros Eléctricos y Electrónicos (The Institute of
Electric and Electronic Engineers).
- IETF: Internet Engineering Task Force.
- InterNIC: Internet Network Information Centre.
- IPSec: Internet Protocol Security.
- IPv4: Internet Protocol version 4.
- IPv6: Internet Protocol version 6.
- IRTF: Internet Research Task Force.
- ISATAP: Intra-Site Automatic Tunnel Addressing Protocol.
- ISO: International Standardization Organization.
- ISOC: Internet Society.
- ISP: Proveedores de Acceso a Internet (Internet Service Providers).
- IWU: Unidad de Interconexión (Internetworking Unit).
- LACNIC: Latin America and Caribbean Network Information Centre.
- LAN: Red de Área Local (Local Area Network).
- LSA: Publicaciones de Estado de Enlace (Link State Advertisement).
- LSP: Paquete de Estado de Enlace (Link State Packet).
- LSU: Actualización de Estado de Enlace (Link State Update).
- MILNET: Military Network.
- MTU: Unidad Máxima de Transferencia (Maximun Transmission Unit).
- NAT: Traducción de Direcciones de Red (Network Address Translation).
- NBMA: Red de Acceso Múltiple sin Broadcast (Non-Broadcast Multiple-
Access Network).
- NCC: Network Coordination Centre.
44
Acrónimos
Acrónimos
- NPA: Dirección de Punto de Conexión a la Red (Network Point of Attach-

ment).
- NSAP: Punto de Acceso al Servicio de Red (Network Service Access
Point).
- NSF: National Science Foundation.
- NSP: Proveedor de Servicio de Red (Network Service Provider).
- OSI: Interconexión de Sistemas Abiertos (Open Systems Interconnection).
- OSPF: Open Shortest Path First.
- PA: Point of Attachment.
- PAT: Traducción de Direcciones de Puerto (Port Address Translation).
- PDA: Asistente Personal Digital (Personal Digital Assistant).
- PDU: Unidad de Datos de Protocolo (Protocol Data Unit).
- PLP: X.25 Packet Layer Protocol.
- QoS: Calidad de Servicio (Quality of Service).
- RARP: Protocolo de Resolución de Direcciones Inverso (Reverse Address
Resolution Protocol).
- RDSI-BE: Red Digital de Servicios Integrados de Banda Estrecha.
- RFC: Request For Comments.
- RIP: Routing Internet Protocol.
- RIPE: Réseaux IP Européens
- RIR: Regional Internet Registry.
- RTB: Red Telefónica Básica.
- RTC: Red Telefónica Conmutada.
- SA: Sistema Autónomo.
- SI: Sistema Intermedio o de Interconexión.
- SF: Sistema Final.
- SMTP: Simple Mail Transfer Protocol.
- ST: Tipo de Servicio (Service Type).
- TCP: Transmission Control Protocol.
55
Acrónimos
- TFTP: Trivial File Transfer Protocol.

- TS: Tipo de Servicio (Type of Service).
- UDP: User Datagram Protocol.
- VLSM: Máscara de Subred de Longitud Variable (Variable Length Sub-
network Mask).
- VPN: Red Privada Virtual (Virtual Private Network).
- WAN: Red de Área Amplia (Wide Area Network).
- WINS: Windows Internet Naming Service.
66
Contenido
Contenido
Acrónimos ................................................................................................................. 3
Capítulo 1. Principios de Interconexión de Redes................................................... 11
1.1. Introducción ................................................................................................. 11
1.2. Interconexión a Nivel Físico ........................................................................ 13
1.3. Interconexión a Nivel de Enlace de Datos ................................................... 14
1.4. Interconexión a Nivel de Red...................................................................... 18
1.5. Interconexión a Nivel de Interred ................................................................ 19
1.6. Aspectos a tener en cuenta en la Interconexión de Redes ............................ 20
1.6.1. Servicio de Capa de Red ofrecido al Nivel de Transporte..................... 22
1.6.2. Direccionamiento .................................................................................. 22
1.6.3. Encaminamiento .................................................................................... 23
1.6.4. Calidad de servicio o QoS (Quality of Service) .................................... 25
1.6.5. Tamaño Máximo de PDU...................................................................... 26
1.6.6. Control de Flujo y Control de la Congestión......................................... 27
1.6.7. Notificación de Errores ......................................................................... 28
1.7. Diferentes Soluciones propuestas a la Interconexión de Redes ................... 28
1.7.1. Solución propuesta por ISO (International Standardization Organization)
......................................................................................................................... 28
1.7.2. Solución propuesta por el IAB (Internet Activity Board) ..................... 30
Capítulo 2. La familia de Protocolos TCP/IP .......................................................... 33
2.1. Introducción. ................................................................................................ 33
2.1.1. Breve historia de Internet ...................................................................... 33
2.1.2. Administración de Internet .................................................................... 34
2.2. Arquitectura TCP/IP..................................................................................... 36
2.3. Nivel de Interred. El protocolo IP ................................................................ 38
2.3.1. Servicio de Red ofrecido por IP ............................................................ 38
77
Contenido
2.3.2. Interredes IP........................................................................................... 39

2.3.3. Direcciones IP ....................................................................................... 43
2.3.4. Formato de un datagrama IP.................................................................. 49
2.4. ICMP (Internet Control Message Protocol) ................................................. 57
2.4.1. Introducción........................................................................................... 57
2.4.2. Tipos de mensajes ICMP. ...................................................................... 58
2.4.3. Utilidades de red basadas en el uso de mensajes ICMP ........................ 60
2.4.4. Observación con respecto a los mensajes ICMP ................................... 64
2.5. Envío de información en IP .......................................................................... 64
2.5.1. Entrega o Transmisión Directa. ............................................................. 65
2.5.2. Entrega o Transmisión indirecta. ........................................................... 66
2.5.3. Tablas de encaminamiento. ................................................................... 69
2.5.4. Resolución de Direcciones. ................................................................... 72
2.6. Subdivisión de redes IP en Subredes o Subnetting ....................................... 80
2.6.1. Subnetting de máscara variable (VLSM) .............................................. 85
2.7. Conceptos de Superredes. Supernetting y CIDR .......................................... 86
Capítulo 3. Asignación de Direcciones IP ............................................................... 91
3.1. Introducción.................................................................................................. 91
3.2. El Protocolo BOOTP (Bootstrap Protocol) .................................................. 92
3.3. El Protocolo DHCP (Dynamic Host Configuration Protocol) ..................... 94
3.3.1. Diferencias DHCP y BOOTP ................................................................ 95
3.3.2. Descripción de DHCP ........................................................................... 96
3.3.3. Funcionamiento de DHCP ..................................................................... 97
3.3.4. Estados DHCP. ...................................................................................... 99
3.3.5. Formato de los mensajes DHCP .......................................................... 101
3.3.6. Conmutación (relay) DHCP. El Relay Agent ...................................... 106
88
Índice
Contenido
Capítulo 4. NAT (Network Address Translation) ................................................. 109

4.1. Introducción ............................................................................................... 109
4.1.1. Tipos de redes...................................................................................... 109
4.2. Direccionamiento IP público y privado ...................................................... 113
4.3. Funcionamiento de NAT ............................................................................ 114
4.3.1. Terminología NAT .............................................................................. 116
4.3.2. Tablas NAT ......................................................................................... 117
4.3.3. NAT con una o varias direcciones públicas ........................................ 118
4.3.4. Sobrecarga NAT .................................................................................. 119
4.3.5. Ejemplo de ISP con NAT .................................................................... 120
4.4. Ventajas y desventajas del uso de NAT ..................................................... 121
4.4.1. Ventajas del uso de NAT..................................................................... 121
4.4.2. Desventajas del uso de NAT ............................................................... 122
Capítulo 5. IP versión 6 ......................................................................................... 123
5.1. Introducción ............................................................................................... 123
5.2. El Protocolo IPv6 ....................................................................................... 124
5.2.1. Principales diferencias con IPv4 ......................................................... 124
5.3. Cabecera de un datagrama IPv6 ................................................................. 126
5.3.1. Cabeceras de Extensión IPv6 .............................................................. 129
5.4. Direcciones en IPv6 ................................................................................... 132
5.4.1. Prefijo de Formato de las direcciones IPv6 ......................................... 134
5.4.2. Direcciones Multicast .......................................................................... 134
5.4.3. Direcciones Locales ............................................................................ 136
5.4.4. Direcciones Públicas Jerárquicas (RFC 3587). ................................... 137
5.4.5. Asignación del identificativo de interface. .......................................... 139
5.5. Autoconfiguración automática de equipos ................................................. 140
5.6. Retraso en la implantación de IPv6 ............................................................ 141
5.7. Estrategias de migración a IPv6 ................................................................. 142
99
Contenido
5.7.1. Dual-Stack o doble pila ....................................................................... 142

5.7.2. Tunneling IPv6 .................................................................................... 143
5.7.3. Traducción ........................................................................................... 145
Capítulo 6. Encaminamiento en IP ........................................................................ 147
6.1. Introducción................................................................................................ 147
6.1.1. Métrica y Distancia Administrativa (DA) ........................................... 151
6.1.2. Detección de redes ............................................................................... 152
6.2. Protocolo de encaminamiento RIP ............................................................. 153
6.2.1. Encaminamiento por vector distancias ................................................ 153
6.2.2. RIP versión 1 ....................................................................................... 154
6.2.3. RIP versión 2 ....................................................................................... 160
6.3. Protocolo de encaminamiento OSPF (Open Shortest Path First) .............. 161
6.3.1. Protocolos de estado del enlace ........................................................... 161
6.3.2. Funcionamiento del Protocolo OSPF .................................................. 162
Bibliografía............................................................................................................ 175
10
10
Principios de Interconexión de Redes
Capítulo 1. Principios de Interconexión de Redes

1.1. Introducción
El concepto de Interred o InterNetwork (abreviado internet) hace referencia a un

conjunto de redes (de cualquier naturaleza, ya sean de área local –LAN- o amplia –
WAN-, etc.), denominadas subredes, interconectadas entre sí formando una red
global que permite la comunicación entre los diferentes dispositivos conectados a
cualquiera de dichas subredes.
Las diferentes subredes que forman la interred pueden ser muy heterogéneas. Pue-
den estar basadas en el uso de la misma o distinta tecnología. Pueden utilizar me-
dios físicos diferentes, ya sean cableados (por ejemplo, fibra óptica, par trenzado,
coaxial fino o grueso, etc.) o inalámbricos (por ejemplo, WLAN, enlaces satelitales,
etc.). Pueden soportar diferentes velocidades (por ejemplo, FDDI a 100 Mbps, Et-
hernet a 10, 100 Mbps o 1 Gbps). Con respecto al tamaño máximo de transmisión,
cada red también puede permitir una MTU (Maximun Transmission Unit) diferente.
Además, cada subred puede ofrecer un tipo de servicio u otro (sin conexión -
ConnectionLess o CL- u orientado a la conexión - Connection Oriented o CO-,
servicios fiables o no fiables, etc.), así como también puede trabajar con diferente
organización o estructura interna (modo circuito virtual -CV- o modo datagrama).
Adicionalmente, cada una de las subredes puede utilizar un sistema de direcciona-
miento interno diferente al de las demás, que, lógicamente, debe ser soportado por
cada uno de los dispositivos conectados la propia subred. Por otro lado, en cuanto al
encaminamiento, cada subred puede estar empleando técnicas diferentes (estáticas o
adaptativas; centralizadas o distribuidas; etc.).
Todo lo anterior supone un problema a la hora de ofrecer una comunicación a los
dispositivos conectados a la red global (a la interred) extremo a extremo. El fin
último de la interred será que se comuniquen dispositivos conectados a las diferen-
tes subredes de distintas tecnologías (por ejemplo, Ethernet, Token-Ring, FDDI,
X.25, Frame-Relay o ATM) que la forman. Para ello se deberán superar todas las
dificultades anteriores. En este capítulo se va a abordar la problemática de la hete-
rogeneidad de las redes que conforman una interred.
La solución más simple de conectar las diferentes subredes consiste en utilizar los
denominados Sistemas Intermedios o de Interconexión (SI) que constituyen una
especie de pasarela entre las subredes de diferente (o igual) tecnología. En la figura
1.1 se presenta una interred formada por 4 subredes de diferente naturaleza (ATM,
Frame-Relay, Token-Ring y Ethernet), interconectadas entre sí mediante cinco SI.
En ella aparecen dos sistemas finales o SF (uno conectado a la subred ATM y otro a
la subred Ethernet) que son los dispositivos que desean comunicarse.
11
11
Direccionamiento
Principios e interconexión
de Interconexión de redes basada en TCP/IP
de Redes
Los sistemas intermedios, también denominados Internetworking Units (IWU), son

sistemas auxiliares que interconectan subredes y que no incluirán necesariamente
todos los niveles de la arquitectura OSI (Open System Interconnection). Normal-
mente incluirán, como máximo, hasta la capa 3, aunque pueden incluir capas supe-
riores o funcionalidades de las mismas. Pueden ser desde simples conectores o
adaptadores de medios hasta encaminadores o routers muy complejos.
SI 1
SF1
ATM F-R
F R
SI 2
SI 3 SI 4
Subredes
TR
T-R Ethernet
SF: Sistemas Finales

SI 5
SI: Sistemas de Interconexión
SF2
Figura 1.1. Interconexión de subredes mediante sistemas intermedios
La idea del modelo OSI (figura 1.2) es que sólo se pueda establecer un diálogo
directo entre niveles homólogos de las diferentes capas del modelo, es decir, entre
los mismos niveles (que hablan el mismo ‘idioma’ o protocolo de comunicaciones).
Cuando no lo son, se necesitará un sistema intermedio (SI) para la conversión de un
protocolo a otro.
N4 N4’
N4
N3 N3 N3’ N3’
N2 N2 N2’
N2 N2’
N2
N1 N1 N1’ N1’
SF SI SF’
Figura 1.2. Esquema OSI de una interconexión
12
12
Capítulo Principios
1. Principios
dede interconexiónde
Interconexión deRedes
redes
Según el nivel o capa que marque la diferencia entre las subredes a interconectar
mediante el SI, ya sea el nivel físico, el nivel de enlace o el nivel de red, tendremos
diferentes tipos de interconexión: Interconexión a nivel físico; a nivel de enlace; o a
nivel de red, respectivamente. A continuación se explica cada uno de estos tipos de
interconexión, además de otro tipo adicional que facilita la interconexión de redes
muy heterogéneas y que se basa en la existencia de un nivel adicional común a
todos los dispositivos a interconectar denominado nivel de interred.
1.2. Interconexión a Nivel Físico
Un sistema de interconexión de nivel 1 (nivel físico) será necesario cuando se desee

conectar dos subredes con todos los niveles iguales salvo el nivel físico. El SI reali-
zará funciones de pasarela entre, al menos, ambos niveles físicos, tal y como se
muestra en la figura 1.3.
N1 N1’
SI
Figura 1.3. Interconexión a Nivel Físico o de capa 1
Existen dos tipos de sistemas de interconexión de nivel físico: los activos y los pa-
sivos. Por un lado, tenemos los denominados adaptadores de impedancias, que son
dispositivos pasivos. Por otro lado, tenemos los repetidores que son activos ya que
regeneran, amplifican la señal y, si es necesario, convierten formatos.
Este tipo de interconexión permite solucionar problemas tanto de incompatibilidad
del medio físico de las redes a interconectar, como también de cobertura, tal y como
se describe en los siguientes ejemplos de interconexión a nivel físico:
a) Conexión de una red Ethernet con cable coaxial a una red Ethernet con cable
de par trenzado. En este caso ambas redes se basan en medios físicos diferen-
tes (cable coaxial y cable de pares).
b) Conexión de dos segmentos de red Ethernet, ambos con cable de par trenzado.
En este caso ambas redes se basan en el mismo medio físico. Se puede realizar
mediante un hub, que no es más que un repetidor (regenerador y amplificador)
que copia o replica cada trama que le llega a uno de sus puertos por el resto de
puertos. Cuando se utiliza un hub para formar una red, cada ordenador o dis-
positivo de red se conecta a un puerto del hub, con lo que éste les proporciona
13
13
Direccionamiento
de Redes
conectividad física. Conceptualmente es equivalente a que todos los dispositi-

vos estuvieran conectados al mismo medio.
Los dos ejemplos a y b se reflejan en la figura 1.4.
SF 1
Coaxial
HUB
Par
Trenzado
…
SF N
Figura 1.4. Conexión mediante un hub con puertos de par trenzado y puertos coaxiales
c) Caso de interconexión de dos subredes, aunque sean iguales, cuya conexión

directa mediante cableado convencional sea imposible. Este caso puede darse,
por ejemplo, bien porque haya un obstáculo infranqueable, como una autopista
o un río, entre los edificios en los que se emplazan cada una de las dos subre-
des, o bien porque la distancia entre ambos edificios sea excesiva para utilizar
una determinada tecnología cableada. Dependiendo de cada caso, se podría,
por ejemplo, usar un par de repetidores, uno en cada edificio y unirlos median-
te un radioenlace (en caso de que el cableado físico no sea posible) o mediante
cable de fibra óptica (en caso de que sí sea posible realizar cableado físico). En
la figura 1.5 se muestra un ejemplo de los dos casos.
1.3. Interconexión a Nivel de Enlace de Datos
Un sistema de interconexión de nivel 2 (nivel de enlace de datos), como el mostrado

en la figura 1.6 será necesario cuando es dicho nivel el que diferencia las subredes a
interconectar, con independencia de si el nivel 1 es igual o no. Como se verá más
adelante, también se podrán utilizar para interconectar subredes del mismo tipo (es
decir, con los niveles 1 y 2 iguales).
14
14
1. Principios
redes
Radioenlace
Rep
Rep
p
HUB HUB
a) Mediante radioenlace
Enlace de f.o.
HUB
HUB
b) Mediante enlace de fibra óptica
Figura 1.5. Solución al problema de cobertura
N2 N2’
N1 N1
SI
Figura 1.6. Interconexión a Nivel de Enlace de Datos o de capa 2
15
15
Direccionamiento
de Redes
A los SI que conectan dos subredes a nivel 2 se les denomina bridges, puentes o
incluso ‘conmutadores de nivel 2’1. Disponen de una cierta unidad inteligente (con
procesador y memoria), pues deben entender y procesar las tramas del nivel 2 de
cada una de las subredes que interconectan. El funcionamiento es muy simple y se
utilizará un sencillo ejemplo para su explicación.
Veamos un ejemplo del caso más sencillo, de interconexión de dos subredes cuyo
nivel 2 sea diferente, por ejemplo, una subred Token-Ring y una subred Ethernet
(figura 1.7). El puente recibirá por sus puertos tramas Token-Ring (TR) y tramas
Ethernet, según el tipo de puerto. Cada trama que llega por uno de sus puertos se
copiará en la memoria interna y se procesará.
Puente
ue te o Bridge
dge
Procesador o CPU
M
Memoria
i
C2 D t
Datos C2’ D t
Datos
T k Ri
Token-Ring Eh
Ethernet
Figura 1.7. Funcionamiento de un puente o bridge
Supongamos que llega una trama por el puerto Token-Ring del puente. El procesa-
dor analizará la cabecera de dicha trama (C2) e inspeccionará principalmente su
dirección de destino. Si el destino está en la propia subred Token-Ring la trama será
descartada y, por tanto, eliminada de la memoria. Por otro lado, si el destino está en
la red Ethernet, se eliminará la cabecera Token-Ring y se extraerá el campo de da-
tos para conformar una trama Ethernet a enviar por el puerto de salida Ethernet. Se
creará una trama con una cabecera Ethernet (C2') y se rellenará el campo de datos
1
Cuando nos referimos a un SI, la palabra ‘conmutador’ siempre debe ir acompañada del nivel más alto al que trabaja el
conmutador en cuanto a funciones de interconexión, ya que existen conmutadores que trabajan a diferentes niveles.
16
16
1. Principios
redes
de dicha trama con los datos originales (los que contenía el campo de datos de la
trama Token-Ring recibida). Dicha trama será transmitida por el puerto Ethernet del
puente. Nótese que en la cabecera C2’, la dirección de nivel 2 de origen será la del
equipo que generó la trama original y no la del puerto del puente por el que se va a
enviar dicha trama.
Este tipo de dispositivos se suele utilizar en entornos de red local, para unir subre-
des muy parecidas (como Ethernet y Token-Ring, por ejemplo), normalmente su-
bredes con tecnologías que han sido estandarizadas por el mismo organismo (por
ejemplo, el IEEE, The Institute of Electric and Electronic Engineers) y tienen una
estructura de cabeceras parecidas.
Por el contrario, cuando los protocolos de nivel 2 de ambas subredes son muy dis-
tintos, este modo de interconexión no es válido. Además, también es importante el
tamaño o longitud máxima de las tramas (MTU de enlace de datos), ya que, si es
diferente, los dispositivos conectados a ambas subredes deberían transmitir, como
mucho, a la longitud máxima limitada por la subred con menor MTU, o bien utilizar
un modo de interconexión de nivel superior (de nivel 3).
El uso de puentes para interconectar subredes puede tener varias utilidades. Por un
lado, es útil para unir subredes de la misma tecnología (por ejemplo, Ethernet) pero
con diferentes velocidades (por ejemplo, una a 10 Mbps y la otra a 100 Mbps).
También se pueden utilizar para unir varias subredes del mismo tipo, también de-
nominados segmentos (por ejemplo, Ethernet), con el fin de obtener mayor privaci-
dad (figura 1.8).
HUB HUB
PUENTE
HUB HUB
Figura 1.8. Ejemplo de utilización de un puente
17
17
Direccionamiento
de Redes
En la figura se muestra el caso de un puente interconectando cuatro segmentos de

red Ethernet. El tráfico local de cada segmento no será enviado por el puente a los
otros segmentos. Sólo se enviarán aquellas tramas que tengan dirección destino en
otro segmento. De esta forma, si se conectara un analizador de protocolos en cual-
quier segmento sólo se podría ver el tráfico que circule por dicho segmento, y no el
tráfico de toda la interred (tal y como ocurriría si se utilizaran hubs para interconec-
tar los segmentos, ya que éstos son meros repetidores).
1.4.- Interconexión a Nivel de Red
Un sistema de interconexión de nivel 3 (nivel de red ) será necesario será necesario

cuando es dicho nivel el que diferencia las subredes a interconectar, con indepen-
dencia de si los niveles inferiores son iguales o no. En este caso, se utilizan sistemas
intermedios de capa 3, y se suelen denominar routers2, encaminadores o enrutado-
res.
N3 N3’
N3
N2 N2’
N1 N1’
SI
Figura 1.9. Interconexión a Nivel de Red o de capa 3
En la figura 1.10 se muestra el funcionamiento de un router. En ella, además, se

puede observar cómo las PDUs (Unidades de Datos de Protocolo o Protocol Data
Unit) o paquetes del nivel de red (superior) se encapsulan en el campo de datos de
las PDUs o tramas del nivel de enlace de datos (inferior). El router, al recibir una
trama (PDU de nivel 2) de la subred 1, después de almacenarla en memoria, elimi-
nará la cabecera y procesará el paquete (PDU de nivel 3) que contiene el campo de
datos de dicha trama. A continuación, el procesador analizará la cabecera del pa-
quete (C3) y, en base a su contenido, encaminará el paquete adecuadamente a un
puerto de salida del router. Antes de esto, se tomarán los datos que contiene el pa-
quete recibido y se generará una cabecera de la tecnología de nivel 3 (C3’) corres-
2
Normalmente para referirse a este tipo de dispositivos se utiliza la palabra inglesa router.
18
18
1. Principios
redes
pondiente a la subred por la cual se vaya a enviar (o encaminar), dependiendo de la

información contenida en la cabecera C3 de la PDU recibida. Se habrá generado
una nueva PDU de nivel 3 (paquete) de la tecnología de la subred por la que se va a
enviar el paquete. Esta PDU deberá encapsularse en una PDU de nivel 2 (trama) de
dicha tecnología antes de enviarse al puerto de salida. Para ello, se generará una
trama de nivel 2 con su correspondiente cabecera (C2', que será independiente de
C2). En este caso, en la cabecera C2’, la dirección de nivel 2 de origen será la del
puerto del router por el que se va a enviar dicha trama.
R t
Router
Procesador o CPU
Memoria
C3 Datos C3’
C3 Datos
C2 C3 Datos C2’
C2 C3’
C3 Datos
Subred 1 (de nivel 3) Subred 2 (de nivel 3)
Figura 1.10. Funcionamiento de un router
Este tipo de interconexión es difícil de implementar y sólo es posible en el caso de

redes muy parecidas. Una manera muy sencilla de reducir esta complejidad consiste
en ocultar los problemas de incompatibilidad bajo un nuevo nivel insertado entre el
nivel 3 y 4 del modelo de capas, denominado nivel de interred. Ello llevará a otro
tipo de interconexión que se explica en el siguiente apartado.
1.5. Interconexión a Nivel de Interred
Cuando se realiza una interconexión a nivel de interred, se deberá añadir un nuevo

nivel (Nivel de Interred) a todos los sistemas involucrados en la comunicación
(desde sistemas finales hasta sistemas de interconexión), que evitará la conversión
entre protocolos (figura 1.11). Todos los sistemas hablarán el mismo ‘idioma’ o
protocolo de comunicaciones, con lo que la comunicación entre ellos se vuelve más
sencilla.
19
19
Direccionamiento
de Redes
…
N4 N4’
NI NI NI’
N3 N3 N3’
N3 N3’
N2 N2 N2’
N2 N2’
N1 N1 N1’ N1’
SF SI SF
Figura 1.11. Interconexión a Nivel de Interred
El funcionamiento se detalla en la figura 1.12 y es similar al de un router de nivel 3,

pero ahora implementando un nivel superior adicional. Las cabeceras de las PDUs
de llegada de niveles inferiores (C2 y C3) se descartan y se generan nuevas cabece-
ras (C3’ y C2’), dependiendo de la información contenida en la cabecera CI de la
PDU de nivel de interred de llegada. En este caso, se genera una nueva PDU del
nivel de interred, pero el paso de CI a CI' no consiste en una conversión de protoco-
los, pues se trata de siempre del mismo protocolo de nivel de interred. Las cabece-
ras serán muy parecidas (a excepción de algunos campos que puedan variar salto a
salto, como, por ejemplo, en el caso de algunas soluciones reales, el tiempo de vida
de la PDU, entre otros).
Aunque esta solución reduce la complejidad de la interconexión de redes, se pierde
eficiencia ya que un mayor número de niveles o capas implica la utilización de un
mayor número de cabeceras en el proceso de encapsulamiento y desencapsulamien-
to y, por tanto, de más información de control adicional que se envía por la misma
subred que los datos, mermando el caudal o la capacidad efectivos de la misma.
1.6. Aspectos a tener en cuenta en la Interconexión de RedesTal y como se

puede apreciar en la figura 1.13, en el modelo de capas de interconexión de redes,
desde el punto de vista de los usuarios de una red global (interred), que en la prácti-
ca son las entidades de protocolo de nivel de transporte, la interred debería propor-
cionar un servicio de red definido en la dirección de punto de acceso al servicio de
red (NSAP) de cada usuario. A través de dicho punto, el usuario del servicio de
interred podrá comunicarse con otros sistemas finales conectados a la misma o a
otra subred remota de la interred. La posible existencia de múltiples redes (posi-
20
20
1. Principios
redes
blemente heterogéneas, es decir, de diferentes tipos) debe ser transparente al usuario

del servicio, para el que la interred ha de aparecer como un ente proveedor de un
servicio de red definido, igual que si el usuario estuviera en una red (por ejemplo,
LAN o WAN) simple.
Router con N.I. P

Procesador
d o CPU
Memoria
CI Datos CI Datos
C3 CI Datos C3’ CI Datos
C2 C3 CI D t
Datos C2’ C3’ CI D t
Datos
S b d1
Subred Subred 2
Figura 1.12. Funcionamiento del router con nivel de interred
SF X SF Y SF Z
N Aplic.
N. Aplic N Aplic.
N. Aplic N Aplic.
N. Aplic
... ... ...
N.T. N.T. N.T.

Servicios
de Red
NSAP X NSAP Y NSAP Z
INTERRED
Figura 1.13. Servicio de Red de Interred
21
21
Direccionamiento
de Redes
A la hora de tratar de interconectar varias subredes independientes para formar una

interred, hace falta tener en cuenta una serie de factores importantes como pueden
ser los siguientes (explicados a continuación):
- Servicios de capa de red.
- Direccionamiento.
- Encaminamiento.
- Calidad de servicio o QoS (Quality of Service).
- Tamaño máximo de PDU.
- Control de flujo y control de la congestión.
- Notificación de errores.
1.6.1. Servicio de Capa de Red ofrecido al Nivel de Transporte
Existen dos tipos de servicio de capa de red: el servicio No Orientado a la Conexión

(Connectionless o C.L.) y el servicio Orientado a la Conexión (Connection Oriented
o C.O.). En una interred el servicio de red debe adaptar los servicios de red de cada
una de las subredes interconectadas. Normalmente, un servicio de red CL es típico
de redes LAN, debido al corto retardo de tránsito y a la baja tasa de error (BER o
Bit Error Rate) de las transmisiones; mientras que en la mayoría de redes WAN
suele emplearse un servicio de red CO perfeccionado, por los largos retardos de
tránsito y tasas de error superiores en este tipo de redes.
Ya que los usuarios de la interred pueden estar conectados a diferentes subredes de
la misma, se deberá decidir inicialmente sobre qué tipo de servicio de red se em-
pleará en la interface de la interred con cada una de las estaciones finales o usua-
rios. Se deberá tener en cuenta la concordancia o armonía del servicio escogido con
los servicios ofrecidos por todas las subredes que constituyen la interred.
1.6.2. Direccionamiento
En una interred, la sintaxis, el formato y asignación de las direcciones de los Siste-

mas Finales y los Sistemas Intermedios difieren según la subred a la que se conec-
ten. Cada tecnología dispone de un sistema de direccionamiento propio bien defini-
do y, al poder ser diferente, en cada subred de la interred, no se podrá utilizar la
dirección del NPA (Network Point of Attachment) de cada subred. Por ejemplo, en
22
22
1. Principios
redes
una LAN Ethernet, como dirección de NPA se toman las direcciones de subcapa
MAC, y su uso es suficiente para hacer llegar la trama a su destino, teniendo dichas
direcciones sólo sentido en dicha red local. Por otro lado, en una WAN se suelen
emplear las direcciones de capa de red (por ejemplo, direcciones X.25) para enca-
minar los paquetes a su destino.
Será necesario utilizar un conjunto de direcciones de red nuevo para identificar los
NSAP en cada sistema conectado a la interred (serán denominadas direcciones de
interred), además de su dirección propia de la subred a la que esté conectado
(NPA), habitualmente llamada dirección física. La dirección de interred deberá
permitir identificar al punto de acceso a la interred del sistema final y tendrá alcan-
ce a toda la interred. La dirección física identificará al equipo dentro de la subred a
la que está conectado y le permitirá comunicarse con cualquier equipo de dicha
subred. Un dispositivo de red tendrá tantas direcciones físicas como subredes a las
que esté conectado, cada una identificando el NPA a cada subred. Además, tendrá
otras tantas direcciones de interred (tantas como subredes a las que se conecte).
1.6.3. Encaminamiento
En una interred existen diferentes subredes interconectadas entre sí a través de sis-

temas intermedios. Cada subred puede seguir un tipo de encaminamiento u otro.
Para un correcto funcionamiento extremo a extremo en la interred no es suficiente
el encaminamiento que efectuarían los nodos de las subredes si se trataran por sepa-
rado.
En el caso de interredes que comprenden varias subredes interconectadas mediante
Sistemas intermedios (SI), la dirección de red de destino (del NSAP del servicio de
interred) no necesariamente se refiere a una dirección de un sistema final pertene-
ciente a la misma subred que el sistema final de origen. Podría perfectamente refe-
rirse a un sistema final conectado a cualquiera de las subredes que conforman la
interred. Por tanto, el encaminamiento en las interredes será mucho más difícil y
complejo que en un entorno formado por una única subred.
Con el fin de identificar esta dificultad añadida respecto al encaminamiento, consi-
deramos la sencilla interred que se ilustra en la figura 1.14, formada por 4 subredes
interconectadas a través de 5 sistemas de interconexión (SI). En primer lugar, re-
cordemos que, como la dirección de interred y la dirección física de un sistema son
diferentes, no se puede encaminar directamente a su destino un paquete valiéndonos
sólo de la dirección de interred de destino. Además, las direcciones físicas de un SI
tienen el mismo formato que el de cualquier otra estación o sistema final (SF) en
cada una de las subredes interconectadas. Por tanto, un SF podrá perfectamente
enviar una PDU de la subred (paquete o trama) directamente a cualquier SI en la
23
23
Direccionamiento
de Redes
misma subred si conoce su dirección física, utilizando la tecnología de dicha su-

bred. Además, como cada SI tiene una dirección física por cada subred a la que esté
conectado, podrá enviar una PDU de subred (paquete o trama) a otro SI conectado a
cualquiera de dichas subredes, a condición de que conozca la dirección física de ese
otro SI en la subred que les conecta directamente.
Si, en el caso de la figura, consideremos el envío de una PDU (paquete o trama)
desde el SF 1 de la subred 1 hasta el SF 4 de la subred 4, se pueden apreciar, a sim-
ple vista, varias las rutas alternativas posibles. Quizás la más obvia (suponiendo que
todas las subredes tienen los mismos parámetros operativos) sea SF 1 SI 4 SF
4. Otras rutas podrían ser SF1 SI 3 SI 5 SF 4; o, también, SF 1 SI 1
SI 2 SF 4.
SF 1 SI 1
Subred 1 Subred 2
SI 2
SI 3 SI 4
Subred 4
S b d3
Subred
SI 5
SF 2
Figura 1.14. Interred formada por 4 subredes
Para que la información siga estos caminos, pasando de unos sistemas a otros, serán
necesarios mecanismos más o menos complejos que permitan realizar las siguientes
acciones previas al envío de la misma en cada sistema involucrado:
- Un SF debe poder determinar la dirección física de los SI conectados a su
subred.
- Un SI debe poder deducir la dirección de física de los SF conectados a su
subred.
- Un SF deberá poder seleccionar un SI específico como destino inmediato al
enviar una PDU (trama o paquete) de información.
24
24
1. Principios
redes
- Un SI debe poder determinar la dirección física de otros SI conectados a

sus mismas subredes.
- Un SI debe poder seleccionar el siguiente SI específico para encaminar la
información recibida hacia un SF de destino determinado.
1.6.4. Calidad de servicio o QoS (Quality of Service)
El concepto de Calidad de Servicio (QoS) de la interred se refiere al conjunto de

parámetros que especifican las prestaciones que el usuario espera del servicio de
interred extremo a extremo y a las facilidades opcionales que éste le proporciona.
En subredes con servicio C.O., los parámetros de QoS se negocian en el estableci-
miento de la llamada virtual, mientras que en subredes con servicio C.L. no se ne-
gocia nada y el sistema debe conocer la QoS que le proporciona la red. En una in-
terred formada por subredes que ofrecen QoS diferentes, las estaciones finales
deberían ser capaces de prever la QoS resultante en la interred a partir del conoci-
miento de la QoS ofrecida en cada subred que conforma la interred.
Cada primitiva de solicitud de servicio que se recibe en un NSAP o punto de acceso
al servicio del nivel de red (ver figura 1.13) tiene asociado un parámetro de QoS. En
la práctica, se trata de un conjunto de parámetros que colectivamente especifican el
rendimiento del servicio de interred que el usuario de la interred (es decir, las enti-
dades del nivel de transporte) espera del proveedor de dicho servicio (NSP o Net-
work Service Provider) en relación con esta solicitud. Además, con los parámetros
de QoS también se especifican los servicios opcionales que se emplearán con esta
solicitud.
Entre los parámetros de QoS pueden estar incluidos, entre otros, normalmente los
siguientes: el retardo de tránsito esperado de la red durante la entrega de la informa-
ción útil al destino especificado; el nivel de protección requerido contra una vigi-
lancia no autorizada o una modificación de los datos; los límites de costes asociados
a dicha solicitud; la probabilidad residual de errores esperada, y la prioridad relativa
asociada a cada paquete.
Con un servicio de red orientado a la conexión (CO), cuando se establece una cone-
xión, tiene lugar una negociación par a par entre los dos usuarios del nivel de red.
El usuario origen especifica los parámetros de QoS que espera y el destino modifi-
ca, si es necesario, algunos de ellos. Con un servicio de red sin conexión (CL), en
cambio, como no se establece ninguna conexión virtual, el usuario del nivel de red
que inicia una solicitud debe conocer la QoS que puede esperar de la interred sub-
yacente.
25
25
Direccionamiento
de Redes
Así, al interconectar tipos de redes distintos (puesto que la QoS puede variar de una
subred a otra), la entidad de red de cada SF debería ser capaz de acumular un cono-
cimiento sobre la QoS esperada a nivel de la interred al dirigirse a cualquier punto
de acceso al nivel de red (NSAP) de destino de la interred especificado.
1.6.5. Tamaño Máximo de PDU
El tamaño máximo de las PDU puede variar en cada tecnología de red, desde pocos
bytes en algunas WAN (por ejemplo, 128 bytes en X.25) a los más de 8.000 bytes
de algunas LANs (por ejemplo, 4.500 en FDDI).
El tamaño máximo de las PDUs en las diferentes subredes variará en función de los
siguientes factores:
- Tasa de error de bit (BER o Bit Error Rate). A mayor tasa de error en los
enlaces de la red, menor deberá ser el tamaño de PDU, con tal de asegurar
un mayor número de PDUs libres de errores.
- Retardo de tránsito. A mayor tamaño máximo de las PDUs, mayor tiempo
tendrán que esperar otras PDUs en cada enlace antes de ser reenviadas, con
el consecuente incremento en el retardo del tránsito de las mismas.
- Necesidades de almacenamiento temporal. A menor tamaño, menor capa-
cidad se necesitara en los buffers requeridos para su almacenamiento.
- Gastos extra de procesamiento. A menor tamaño, mayor será el número de
PDUs necesarias para enviar cada bloque de información, con el conse-
cuente incremento en gastos extra de procesamiento (de la/s cabecera/s de
cada PDU) por bloque.
En el caso de una sola red, el tamaño máximo de las PDUs normalmente es conoci-
do, así que la entidad de protocolo de la capa de transporte misma puede dividir –
segmentar o fragmentar- los mensajes más largos en unidades más pequeñas para
ser transferidos por la red. En cambio, en interredes que abarcan redes con diversos
tamaños máximos de PDUs, es necesario conocer y usar, el tamaño mínimo de
PDU, o bien la capa de red de cada SF y SI debe realizar las operaciones de seg-
mentación (fragmentación) y re-ensamblado necesarias. Mediante el uso de la pri-
mera alternativa algunas redes se vuelven ineficientes, mientras que con la segunda
alternativa la capa de red debe realizar una función adicional. Por tanto, se presen-
tan varias opciones: que el protocolo de transporte segmente al mínimo de los ta-
maños máximos de PDUs de subred o bien disponer en la capa de red de las esta-
ciones y de los SI, de mecanismos de segmentación y re-ensamblado.
26
26
1. Principios
redes
1.6.6. Control de Flujo y Control de la Congestión
Por un lado, el Control de Flujo se realiza para controlar el flujo de PDUs relacio-
nadas con una sola conexión entre dos sistemas, así como tratar de resolver la dife-
rencia entre la velocidad con que un Sistema Final de origen transmite PDUs y la
velocidad con la que el Sistema Final de destino puede aceptarlas. Si el SF de des-
tino puede aceptar PDUs con mayor rapidez de lo que el SF de origen puede enviar-
los, es obvio que no hay ningún problema, pero si la situación es la opuesta habrá
que añadir algún mecanismo adicional de control (de flujo), con tal de no saturar o
desbordar al SF de destino.
Por otro lado, el Control de Congestión se ocupa de una función similar pero to-
mando la red misma como un ente global. Si la tasa total de entrada (resultado de la
suma de todas las tasas de entrada) de PDUs en la red excede la tasa con la que
pueden procesarse y salir, la red en su conjunto se congestionará. De manera simi-
lar, a nivel más local, si las PDUs llegan a un nodo de la red – un SI, por ejemplo-
con una rapidez mayor que aquélla con que éste puede procesarlas y reenviarlas, el
nodo se congestionará, afectando, al mismo tiempo, al flujo de PDUs relacionadas
con todas las conexiones que pasan por ese nodo.
Por tanto, en una interred, el algoritmo de control de congestión debe armonizar los
algoritmos de control de las distintas subredes. En redes con servicio CO, por ejem-
plo X.25, se aplica control de flujo por Circuito Virtual a la entrada de la red, lo
cual ayuda a prevenir la congestión, pero no la evita. Se define una ventana de
transmisión, y una vez que se ha enviado el número de paquetes correspondientes a
dicha ventana, el transmisor deberá esperar hasta haber recibido una confirmación
relacionada con cualquiera de los paquetes transmitidos. Como en cada una de las
conexiones esta función se efectúa en los accesos a la red, además de regular el
flujo de paquetes hacia la red, ayuda a controlar la congestión. Sin embargo, no la
evita del todo.
En contraste, en las redes con servicio CL, no se aplica control de flujo alguno a
PDUs asociados a una conexión dentro de la interred, por lo que las entidades de
capa de transporte de los sistemas finales deben aplicarlo entre estaciones (extremo
a extremo), aunque se precise aún de control de congestión. En caso de aparición de
congestión en la red, la información de control de flujo se retrasará y las entidades
de protocolo de transporte del origen dejarán de enviar nuevos datos a la red. De
nuevo, aunque este mecanismo ayuda a aliviar la congestión de la red (como sucede
en las redes CO), no siempre la evita.
Por tanto, en ambos esquemas se deberá incorporar algún algoritmo que controle la
congestión dentro de la red, armonizando los algoritmos internos, si existen, de cada
una de las mismas.
27
27
Direccionamiento
de Redes
1.6.7. Notificación de Errores
Cada tecnología de subred puede disponer o no de mecanismos de notificación de

errores específicos. En una interred, en caso de querer implementar algún tipo de
sistema de notificación de errores extremo a extremo, se deberá establecer un me-
canismo de notificación extensible y compatible con el de las distintas subredes que
la compongan.
1.7. Diferentes Soluciones propuestas a la Interconexión de Redes
A continuación, y una vez identificados los factores más importantes a tener en

cuenta en la interconexión de redes, se presentan dos de las propuestas para solu-
cionar el problema de interconexión de redes heterogéneas, planteadas por parte de
ISO (International Standardization Organization) e IAB (Internet Activity Board).
1.7.1. Solución propuesta por ISO (International Standardization Organization)
El papel de la capa de red en cada Sistema Final o SF consiste en proporcionar a

su/s usuario/s (entidades del nivel de transporte) local/es un servicio de red extremo
a extremo que abarque toda la interred. Como hemos visto, este servicio puede ser
orientado a la conexión o sin conexión. En ambos casos, la presencia de múltiples
tipos de redes debe ser transparente a los usuarios. Por ello, las entidades de la capa
de red en cada uno de los sistemas intermedios deberán efectuar con total transpa-
rencia el encaminamiento y todas las demás funciones relacionadas con la retrans-
misión de información útil en el nivel de red.
La solución propuesta en el contexto del modelo de referencia de ISO para lograr
dicho objetivo consiste en que la capa de red en cada Sistema Final (SF) y en cada
Sistema Intermedio (SI) no contemple un protocolo único, sino más bien tres proto-
colos (de subcapa), que en la terminología de ISO toman los siguientes nombres:
- Protocolo de convergencia independiente de la subred (SNICP, Subnetwork
Independent Convergence Protocol).
- Protocolo de convergencia dependiente de la subred (SNDCP, Subnetwork
Dependent Convergence Protocol).
28
28
1. Principios
redes
- Protocolo de acceso dependiente de la subred (SNDAP, Subnetwork De-

pendent Access Protocol).
En la figura 1.15 se presenta la arquitectura, reflejando las 3 subcapas, de un SF y

en un SI, siguiendo la solución propuesta por ISO.
SF 1
S.F. SF 2
S.F.
... ...
N. T. SI
S.I. N. T.
Encaminamiento y
Retransmisión
SNICP SNICP SNICP
SNDCP SNDCP SNDCP’ SNDCP
SNDAP SNDAP SNDAP’ SNDAP

N.E.D N.E.D N.E.D’ N.E.D
N.F. N.F. N.F. N.F.
Subred 1 Subred 2
Flujo Lógico Flujo Real
Figura 1.15. Aproximación de ISO a la Interconexión de Redes
La subcapa superior SNICP, subcapa independiente de la subred, proporciona el

servicio de red a los usuarios en la interface con la interred extremo a extremo (en-
tidades de transporte residentes en sistemas finales remotos). Su función consiste en
realizar las diversas funciones de armonización (convergencia) que pueden ser ne-
cesarias para encaminar y retransmitir los datos de usuario (unidades de datos del
protocolo de transporte) a través de la interred. Su funcionamiento es transparente e
independiente de las características de las subredes específicas que existan en la
interred y espera un servicio de red estándar de ellas. Será el mismo para todos los
SFs y SIs de la interred.
29
29
Direccionamiento
de Redes
La subcapa inferior SNDAP, subcapa de acceso a la subred, se encarga del acceso

a la subred de la tecnología de subred específica a la que está conectado el equipo,
así como de la transferencia de datos a su través. Como ejemplos, se pueden citar el
protocolo de nivel 3 de X.25 (X.25 Packet Layer Protocol o PLP) de nivel 3 de una
red X.25, así como el protocolo de red CL que se usa habitualmente en una LAN.
Como las características de servicio y operación asociadas a los SNDAP difieren de
un tipo de subred a otro, se necesita una subcapa intermedia de convergencia entre
las subcapas SNICP y el SNDAP. Se trata de la subcapa SNDCP, subcapa depen-
diente de la subred, cuyas operaciones de convergencia que realice dependerán de
los distintos tipos de subred/red existentes. Aumentará el servicio de la subcapa de
acceso a la subred para ofrecer un servicio de red OSI. Existe un protocolo SNDCP
para conseguir un servicio CO y otro para conseguir un servicio CL. Como ejemplo,
el protocolo X.25 PLP implementa SNDAP+SNDCP para ofrecer un servicio CO.
1.7.2. Solución propuesta por el IAB (Internet Activity Board)
Los protocolos que se emplean en la interred por excelencia, Internet, se desarrollan

y aprueban por el IETF (Internet Engineering Task Force), cuyos miembros publi-
can sus logros en los documentos RFC (Request For Comments).
El Internet Architecture Board o IAB (Junta de Arquitectura de Internet) es el orga-
nismo encargado de aprobar si una RFC se convierte en estándar de internet (Inter-
net Standard) y, por tanto, si es de obligado cumplimiento para los sistemas que se
conecten a Internet.
La propuesta del IAB a la interconexión de redes está basada en la interconexión a
nivel de interred, explicada en el apartado 1.5. En el nivel de interred de dicha pro-
puesta opera el protocolo IP (Internet Protocol), sobre el que se ha definido una
familia de protocolos denominada familia o pila de protocolos TCP/IP, algunos de
los cuales se explican en capítulos posteriores.
Dentro de la pila de protocolos TCP/IP se destaca el protocolo IP, definido en la
RFC 791, que implementa funciones que ISO incorporó posteriormente en la Sub-
capa Independiente de la Subred (cuyo protocolo es SNICP). Ofrece un servicio sin
conexión, pero no sigue la definición OSI del servicio CL. Está diseñado para ofre-
cer un servicio no fiable a los protocolos de transporte, principalmente TCP
(Transmission Control Protocol) y UDP (User Datagram Protocol).
Además, también existen otras RFCs en las que se dan instrucciones de implemen-
tación de las funciones que ISO ha incorporado posteriormente en la Subcapa De-
pendiente de la Subred (cuyo protocolo es SNDCP), como, por ejemplo, la
30
30
1. Principios
redes
RFC948, que define el Estándar para la transmisión de datagramas IP sobre redes

IEEE 802.3.
31
31
La Familia de Protocolos TCP/IP
Capítulo 2. La familia de Protocolos TCP/IP

2.1. Introducción
El concepto de la red Internet3, por todos conocida, no es ni más ni menos que un

conjunto de redes de dispositivos interconectadas distribuidas internacionalmente,
que tienen en común un conjunto de protocolos y servicios, de manera que los usua-
rios conectados a dichas redes puedan hacer uso de servicios de información y co-
municación de alcance mundial.
2.1.1. Breve historia de Internet
Internet surgió a partir de un proyecto de la agencia estadounidense ARPA (Advan-

ced Research and Projects Agency) con el objetivo de conectar las computadoras de
sus departamentos de investigación mediante la técnica de conmutación de paque-
tes. Esa conexión dio inicio en 1969, entre 4 localidades (las Universidades de la
California de Los Ángeles y Santa Barbara, la Universidad de Utah y el Instituto de
Investigación de Stanford), y pasó a ser conocida como ARPANET.
Ese proyecto inicial fue puesto a disposición de la comunidad investigadora, lo que
resultó en una intensa actividad de investigación durante la década de los 70, cuyo
principal resultado fue la concepción del conjunto de protocolos que, hasta la fecha,
ha sido y es la base de Internet, conocida como la pila TCP/IP, llegando los proto-
colos a su definición actual alrededor de 1977-79.
En el inicio de los años 80, la agencia ARPA inició la interconexión de las redes de
computadoras de otros centros de investigación a ARPANET, que se convirtió en la
columna vertebral (backbone) de interconexión de dichas redes. En esa misma épo-
ca fue se integraron en la Universidad de la California de Berkeley los protocolos
TCP/IP en el Sistema Operativo UNIX (Berkeley Software Distribution o BSD
UNIX), lo que hizo posible la interconexión de varias universidades con la red AR-
PANET.
En 1983, la Agencia de Comunicación de Defensa (Defense Communication Agen-
cy o DCA) dividió la red ARPANET en dos redes separadas: una destinada a fines
de investigación y otra a comunicaciones militares. La parte de investigación retuvo
el nombre de ARPANET mientras que la parte militar se le denominó MILNET
(Military Network).
3
En este libro, nos referiremos con el término Internet (con la ‘I’ mayúscula) a la red de redes por todos conocida cuya
interconexión está basada en la pila de protocolos TCP/IP.
33
33
Direccionamiento
La e interconexión
Familia de Protocolos TCP/IP de redes basada en TCP/IP
En 1985, la entidad americana NSF (National Science Foundation) interconectó las

supercomputadoras de sus 5 centros de investigación, lo que resultó en la red cono-
cida como NSFNET, que, a su vez, en 1986, fue conectada a ARPANET. El con-
junto de todas las computadoras y redes conectadas a esos dos backbones (redes
principales) pasó a ser conocido ya oficialmente como la Internet Global (la Inter-
net, con la ‘I’ mayúscula).
Por el año 1987, el crecimiento del número de computadoras conectado a la Intenet
Global era del 15% al mes.
En 1988, la NSFNET pasó a ser mantenida con el respaldo de organizaciones pri-
vadas como IBM, MCI (empresa de telecomunicaciones) y MERIT (institución
responsable de una red de computadoras de instituciones educacionales de Michi-
gan), que formaron una asociación conocida como ANS (Advanced Network and
Services).
En 1990, el backbone ARPANET fue desconectado y reemplazado por el backbone
DRI (Defense Research Internet). En 1991-92, la ANS desarrolló un nuevo back-
bone, conocido como ANSNET, que pasó a ser el backbone principal de Internet.
Por esa misma época se inició el desarrollo de un backbone europeo (EBONE),
intercomunicando algunos países de Europa Internet.
A partir de 1993 Internet dejó de ser una institución de naturaleza únicamente aca-
démica y pasó a ser explotada comercialmente, tanto para la construcción de nuevos
backbones por empresas privadas (PSI, Uunet, Sprint,...) como para provisión de
servicios diversos. Esta apertura se dio a nivel mundial.
En 1994, la Internet global había alcanzado alrededor de 3 millones de computado-
ras en 61 países.
No es necesario destacar en estas páginas la evolución seguida desde entonces ya
que es suficientemente conocida por la mayoría de los posibles lectores de este
libro.
2.1.2. Administración de Internet
Tanto la Administración cuanto la operación de Internet son descentralizadas, ex-

ceptuando algunas tareas, tales como la coordinación de las investigaciones y es-
tándares para funcionamiento de la red y la distribución de direcciones y registros
de dominios para interconexión a la red.
34
34
CapítuloLa
2. La familiadedeProtocolos
Familia protocolos TCP/IP
TCP/IP
Las principales instituciones responsables por esas tareas son:
The Internet Society (ISOC). Sociedad que, a través de foros, debates y pu-
blicaciones, procura orientar la investigación y utilización de Internet.
The Internet Architecture Board (IAB o Junta de Arquitectura de Internet).
Fundado en 1983 como Internet Activities Board e integrado en la Internet
Society en 1992. Guía la evolución de Internet, coordinando toda la inves-
tigación y desarrollo involucrados en el funcionamiento de Internet. Coor-
dina los grupos de trabajo, como por ejemplo, los grupos de investigadores
voluntarios IETF e IRTF, que se presentan a continuación.
The Internet Research Task Force (IRTF). Grupo formado con el objetivo
de desarrollar investigaciones a largo plazo referentes al funcionamiento de
Internet.
The Internet Engineering Task Force (IETF).Grupos de investigadores y
técnicos responsables del desarrollo de estándares para el funcionamiento
de Internet. De dichos grupos surgen los documentos conocidos como RFC
(Request For Comments) que, aunque hayan sido creados apenas como
propuestas para estandarización, en la práctica, algunos se han convertido
en los verdaderos estándares oficiales de Internet.
The Internet Network Information Center (InterNIC). Originalmente com-
puesto por 3 instituciones (AT&T, PSI y General Atomics) y sus objetivos
consisten en centralizar la distribución de informaciones de la Internet So-
ciety (RFC,...), así como coordinar la distribución de direcciones y registros
de dominio para Proveedores de Acceso a Internet (ISP) a nivel mundial.
The Internet Assigned Numbers Authority (IANA). Organismo mantenido
por el Instituto de Ciencia e Información de la Universidad del Sur de Cali-
fornia, que controla la distribución de identificadores para servicios que se-
rán suministrados vía Internet. Las direcciones IP que se utilizan en Inter-
net son asignadas por esta autoridad central. No obstante, cuando una
organización se une a Internet, puede obtener direcciones de red del ‘Re-
gional Internet Registry’ (RIR) de su región. En la zona de Europa el regis-
tro regional europeo es el Réseaux IP Européens Network Coordination
Centre (RIPE NCC). Una vez se ha obtenido un conjunto de direcciones de
red, la organización determinará, de forma interna, cómo asignar las direc-
ciones a cada estación de su red.
Un RIR es una organización que gestiona la asignación y registro de recur-
sos de direccionamiento IP dentro de una región particular del mundo. Han
evolucionado en el tiempo y, actualmente, existen 5 RIRs que dividen al
mundo en 5 Regiones o zonas:
35
35
Direccionamiento
La e interconexión
African Network Information Centre (AfriNIC) para África.

American Registry for Internet Numbers (ARIN) para los Estados
Unidos, Canadá y ciertas zonas del Caribe y la Antártida.
Asia-Pacific Network Information Centre (APNIC) para Asia, Aus-
tralia, Nueva Zelanda y países vecinos.
Latin America and Caribbean Network Information Centre (LAC-
NIC) para Latinoamérica y otras zonas del Caribe.
Réseaux IP Européens Network Coordination Centre (RIPE NCC)
para Europa, Rusia, Oriente Medio y Asia Central.
En cuanto a la relación entre IANA y los RIRs, IANA delega los recursos
de Internet a los RIRs quienes, a su vez, siguen sus políticas regionales para
delegar recursos a sus clientes, que incluyen tanto a Proveedores de Acceso
a Internet como a organizaciones de usuarios finales.
2.2. Arquitectura TCP/IP
La pila de protocolos TCP/IP es el primer conjunto de protocolos que soporta com-

pletamente internetworking. Es un estándar ‘de hecho’ (de facto) de interconexión
de redes. La familia TCP/IP agrupa, además de los 2 protocolos que le dan su nom-
bre, TCP e IP, una gran variedad adicional de protocolos, algunos de los cuales
serán estudiados en este libro. La familia de protocolos TCP/IP no está ligada a un
sistema operativo específico ni vendedor alguno.
Aunque la arquitectura TCP/IP es distinta a la arquitectura OSI tiene algunas coin-
cidencias, tal y como se puede apreciar en la figura 2.1.
En este caso, se denomina subred a la tecnología específica (como, por ejemplo,
Ethernet) que ofrece el servicio de red, sobre el que se sustenta el nivel de interred.
El servicio que se da a niveles superiores es, por tanto, independiente de la tecnolo-
gía de la subred. El nivel de interred suele estar implementado por el protocolo IP
que ofrece, por decisión de diseño, un servicio no fiable y no orientado a la cone-
xión (CL o ConnectionLess). Su finalidad esencial es ocultar la heterogeneidad de
subredes, ofreciendo un servicio de interred independiente de ellas.
36
36
CapítuloLa
TCP/IP
Ejemplos
j de Equivalente
i en el
protocolos Arquitectura TCP/IP modelo OSI
FTP, TELNET, SMTP,

SNMP TFTP
SNMP, TFTP, Etc
Etc. Aplicación
p Niveles 5 a 7
TCP UDP
TCP, Transporte Nivel 4
IP,, ICMP,, ARP,,
RARP
Interred Funciones del Nivel 3
Niveles 1, 2 y, en algunas
Ethernet,, 802.3,, 802.5,,
FDDI, X.25, ATM, etc.
Subred subredes,, Nivel 3
Figura 2.1. Arquitectura TCP/IP frente a arquitectura OSI
En cuanto al nivel de transporte, los dos protocolos típicos de la pila TCP/IP son los
siguientes:
TCP (Transmission Control Protocol): Ofrece un servicio orientado a la co-
nexión y cumple perfectamente con los requisitos de fiabilidad. Su principal
inconveniente es su complejidad.
UDP (User Datagram Protocol): Ofrece un servicio no orientado a la cone-
xión y, por tanto, más sencillo que TCP. El servicio que ofrece no es fiable.
Por último, en el nivel de aplicación encontramos protocolos tales como FTP (File
Transfer Protocol) para la transferencia de archivos, HTTP (HyperText Transfer
Protocol) para la navegación web, SMTP (Simple Mail Transfer Protocol) para
gestión de correo electrónico, etc.
La nomenclatura seguida en la literatura de interconexión basada en la pila de pro-
tocolos TCP/IP es la siguiente:
A los sistemas finales se les denomina Hosts.
Las PDUs (Protocol Data Units o Unidades de datos del Protocolo) del ni-
vel de interred se denominan Datagramas IP.
A las PDUs de nivel de transporte se las denomina segmentos.
37
37
Direccionamiento
La e interconexión
2.3. Nivel de Interred. El protocolo IP
El protocolo IP es el protocolo de Internet que, en un principio, fue desarrollado a

principios de los 70 para la red ARPANET. Está definido en su versión 4 en la RFC
791 y es el protocolo principal o núcleo de la pila de protocolos TCP/IP que utiliza-
da en Internet. Su normalización corre a cargo del IETF. En este capítulo se presen-
ta la versión 4 del protocolo, dejando para otro capítulo posterior la presentación de
la versión 6 del mismo.
2.3.1. Servicio de Red ofrecido por IP
IP ofrece un servicio de interred extremo a extremo independiente de las subredes

por las que se pase. Dicho servicio, proporcionado a los protocolos de transporte
(niveles superiores en los SF de ambos extremos), se caracteriza por ser:
No orientado a conexión: No existe establecimiento ni liberación de cone-
xión para la transferencia de datos. IP proporciona una entrega sin cone-
xión de las unidades de datos de protocolo de transporte (T-PDUs) a través
de la red.
No fiable: Pueden producirse pérdidas, duplicaciones y desórdenes de pa-
quetes. Es decir, el servicio IP no garantiza la entrega de los datagramas.
Todos estos errores han de ser vigilados y corregidos en un nivel superior
(transporte) en los extremos de la comunicación.
De tipo ‘best-effort’4. El protocolo IP intentará ofrecer el mejor servicio en
cada momento y según las subredes subyacentes en la interred.
Cabe destacar que el protocolo IP no proporciona corrección de errores ni control

de congestión, dejando estas funciones a los niveles superiores de los sistemas fina-
les que se comunican.
Si un mensaje recibido del nivel de transporte (T-PDU) es demasiado largo para la
red subyacente, el nivel IP es, normalmente, quien se encarga de fragmentarlo en
partes más pequeñas (lo mismo si atraviesa una red que sólo permite pequeños ta-
maños de MTU o Unidad Máxima de Transferencia). Más adelante se explicará el
proceso de fragmentación y re-ensamblado seguido e IP.
4
En algunos libros de la bibliografía se traduce el término ‘best-effort’ como ‘de buenas intenciones’.
38
38
CapítuloLa
TCP/IP
2.3.2. Interredes IP
El protocolo IP es único, mientras que existen multitud de tecnologías de subredes

subyacentes. El uso de IP hace necesario implantar capas o niveles intermedios
(conocidos como capas de convergencia) entre el propio nivel IP y la capa de su-
bred sobre las que descansa. Por tanto, si sale al mercado una tecnología de subred
nueva, deberá salir, adicionalmente, un nuevo nivel intermedio de convergencia. De
esta forma, instalar una nueva tecnología no obliga al usuario a cambiar los niveles
que estén por encima de IP. Los protocolos de estos niveles intermedios que actúan
como ‘traductores’ se denominan protocolos de convergencia.
2.3.2.1. Modo de operación IP
El protocolo IP funciona en modo datagrama, encapsulando los datos en PDUs

denominadas datagramas IP. A cada T-PDU o segmento que se recibe del nivel de
transporte se le añade una cabecera IP, con la información de control y de direccio-
namiento IP completa, formando un datagrama IP. Dicho datagrama es transmitido
encapsulado en una PDU de subred (trama o paquete, dependiendo de si la tecnolo-
gía de subred es de nivel 2 o nivel 3, respectivamente) por la subred subyacente.
La subred subyacente puede funcionar de la misma forma que IP (sin conexión) o
de forma diferente (con conexión), dando lugar a dos tipos de interredes. A conti-
nuación se presenta un ejemplo de cada uno de los dos tipos.
Ejemplo 1 de IP sobre tecnología de subred que ofrezca un servicio no orientado a
la conexión (CL): IP sobre Ethernet. En este caso, ambas tecnologías ofrecen un
servicio sin conexión, con lo que las primitivas del servicio sin conexión empleadas
por ambos protocolos serán equivalentes. El proceso de encapsulamiento seguido es
el habitual:
1. Se genera el datagrama IP, con su correspondiente cabecera.
2. Se construye la trama Ethernet encapsulando el datagrama IP en el campo
de datos y añadiendo la cabecera Ethernet que corresponda según el conte-
nido de la dirección IP de destino en la cabecera del datagrama IP.
39
39
Direccionamiento
La e interconexión
Familia de Protocolos TCP/IPde redes basada en TCP/IP
Gráficamente:
HIP DatosIP Datagrama IP IP
Ethernet
HETH DatosETH Trama Ethernet
h
Capas
Figura 2.2. IP sobre Ethernet
Este caso, se simplifica mucho por el hecho de que tanto Ethernet como IP son no
orientados a conexión. Por esto, las primitivas de servicio IP de tipo Data.Request y
Data.Indication se traducen rápidamente a sus equivalentes en Ethernet, que son
exactamente del mismo tipo al tratarse en ambos casos de servicios no orientados a
la conexión.
Ejemplo 2 de IP sobre tecnología de subred que ofrece un servicio orientado a la

conexión: IP sobre X.25. En este caso, el proceso de encapsulamiento de PDUs
también es el habitual.
IP
HIP D t IP
Datos D t
Datagrama IP RFC 1356
HX.25 DatosX.25 P
Paquete X
X.25
25 X 25
X.25
Capas
Figura 2.3. IP sobre X.25
Sin embargo, al ser X.25 una tecnología que ofrece un servicio de red orientado a
conexión, las primitivas a emplear serán diferentes a las empleadas en el servicio
sin conexión de IP. Por tanto, en este caso, será necesario un nivel intermedio o
capa de convergencia entre IP y la tecnología X.25, que haga de pasarela entre las
primitivas de un protocolo y del otro. Dicha capa de convergencia está definida en
la RFC 1356.
40
40
CapítuloLa
TCP/IP
Supongamos la siguiente situación, donde se emplea IP para la comunicación entre

SF 1 y SF 2 de la figura:
SF 1 X.25
SF 2
Router
Ethernet
Figura 2.4. Escenario de uso de IP sobre X.25
Según el esquema de la figura la comunicación se puede generar en ambos extre-

mos:
a) Si la comunicación IP la inicia el terminal X.25 (Sistema Final 1 o SF 1). El

proceso para realizar una transmisión de un datagrama IP desde el equipo SF 1
hasta el SF2 conectado a la red Ethernet es el siguiente:
1. X.25, al ser CO, antes de enviar paquetes de datos (los datagrama IP van
encapsulados en su campo de datos), deberá establecer un circuito virtual
(CV) entre SF 1 y el router X.25 (esto se sabrá a partir del contenido de la
cabecera IP).
2. Una vez establecido el CV, ya se podrá encapsular el datagrama en paque-
te/s de datos X.25, que serán enviados de forma consecutiva por el CV al
router.
3. El router extraerá los datagramas encapsulados en paquetes X.25 y los en-
capsulará en tramas Ethernet dirigidas a SF2.
4. El CV quedará establecido durante un tiempo para otros envíos de informa-
ción posteriores, tanto en un sentido como en el otro.
41
41
Direccionamiento
La e interconexión
5. Transcurrido un tiempo (predefinido) sin envíos el CV se liberará.
Gráficamente, tendríamos el diagrama de tiempos de la figura 2.5.
SF1 Router SF2

IP X.25 Ethernet
Cabecera IP
Data. Req Datos

Conn Req
Conn.
C
Conn. I d
Ind
Establecimiento
del CV
Conn. Conf
Conn. Resp
Cabecera X.25
Cabecera IP
Data. ReqX.25
Datos
Cabecera Ethernet
Cabecera IP
Datos
Figura 2.5. Transmisión en IP sobre X.25. Origen en SF1 (caso a)
b) Si es SF 2 el que inicia la comunicación, el procedimiento de intercambio de

información será el siguiente:
1. SF 2 envía el datagrama IP encapsulado en una trama Ethernet sin preocu-

parse de nada más, tal y como se ha visto en el ejemplo 1 anterior.
2. El router al recibir la trama Ethernet con el datagrama IP encapsulado, lo
extraerá y analizará su cabecera IP. Decidirá que el siguiente nodo al que le
deberá enviar el datagrama es un nodo de una red X.25 (SF 1), utilizando el
servicio orientado a la conexión ofrecido por dicha red.
3. Por tanto, antes de poder enviar el datagrama IP encapsulado en paquete/s
de datos X.25, deberá establecer la conexión X. 25 (CV) con dicho nodo.
42
42
CapítuloLa
TCP/IP
4. Una vez establecido el CV, ya podrá encapsular el datagrama en paquete/s

de datos X.25 que serán enviados de forma consecutiva por el CV hasta SF
1.
5. El CV quedará establecido durante un tiempo para otros envíos de infor-
mación posteriores tanto en un sentido como en el otro.
6. Transcurrido un tiempo (predefinido) sin envíos el CV se liberará.
SF1 Router SF2

IP X 25
X.25 Ethernet
Cabecera Ethernet
Cabecera IP
Data. Req ETH
Datos
Conn. Req
Conn. Ind
Establecimiento
E t bl i i t
del CV
Conn. Resp
Conn. Conf
Cabecera X.25
Cabecera IP
Data. ReqX.25
Datos
Figura 2.6. Transmisión en IP sobre X.25. Origen en SF2 (caso b)
En ambos casos, a y b, todo el proceso se realiza de forma transparente al usuario

que envió la información (o la entidad del nivel de transporte correspondiente), bien
desde SF 1 o SF 2.
2.3.3. Direcciones IP
Las direcciones IP son como etiquetas binarias que identifican, de manera lógica y
jerárquica, a un interface de un dispositivo de comunicaciones, a través del cual
dicho dispositivo se conecta a una subred IP. Se trata de direcciones denominadas
43
43
Direccionamiento
La e interconexión
direcciones ‘lógicas’ o ‘virtuales’ y deberán ser independientes de las tecnologías

de subred posibles en la interred.
La RFC 791 define direcciones de 32 bits (4 bytes), lo que teóricamente permite la
utilización de unos 4.000 millones de direcciones diferentes (232), aproximadamen-
te. Sin embargo, como se explica más adelante, se han desperdiciado muchas, por la
forma de asignar direcciones IP que se ha seguido en el pasado.
La dirección IP se divide en dos partes: el identificativo de red (NetId), que identifi-
ca la red a la que pertenece dicha dirección; y el identificativo de host (HostId) o
equipo, que identifica al host o equipo dentro de la propia red. Como se verá más
adelante, a su vez, en caso de querer dividir la red en subredes (subnetting), se pue-
den tomar los primeros bits del HostId para identificar cada subred (SubnetId). La
decisión la toma el administrador de la red, pero, al menos, debe dejar, como míni-
mo, los dos últimos bits para el HostId.
32 bits
NetId HostId
Figura 2.7. Direcciones IP
Para dar flexibilidad a la asignación de direcciones IP se definieron cinco tipos o

formatos básicos de direcciones IP, en función de la longitud de los dos campos
anteriores:
Clase A: En esta clase, el primer bit es ‘0’, los próximos 7 bits indican el NetId
(27, 128 redes de clase A) y los últimos 24 indican el HostId (224, 16777216 po-
sibles combinaciones, algunas de ellas reservadas). Véase la figura 2.8.
32 bits
Rango:
0 NetId (128) HostId (16777216) 00.0.0.0
000 a
127 255 255 255
127.255.255.255
Figura 2.8. Direcciones IP de Clase A
Esta clase de direcciones permite tener muchos sistemas conectados en una
única subred, siendo idónea para grandes redes con muchos equipos (normal-
mente se asignan a redes de operadores o backbones). No interesa, sin embargo,
44
44
CapítuloLa
TCP/IP
para pequeñas redes locales con pocos equipos, pues se desperdiciarían multi-
tud de direcciones.
Clase B: En esta clase, los dos primeros bits son ‘10’, los siguientes 14 bits
indican el NetId (214, 16384 redes de clase B), y los próximos 16 son el HostId
(216, 65536 posibles combinaciones, de las cuales 2 están reservadas). Véase la
figura 2.9.
32 bits
Rango:
10 NetId (16384) HostId(65536) 128 0 0 0 a

128.0.0.0
191.255.255.255
191 255 255 255
Figura 2.9. Direcciones IP de Clase B
• Clase C: Los primeros tres bits son ‘110’, los siguientes 21 bits indican el
NetId (221, 2097152 redes de clase C), y los últimos 8 son el HostId (28, 256
posibles combinaciones, de las cuales 2 están reservadas). Véase la figura
2.10.
32 bits
Rango:
110 NetId (2097152) HostId (256) 192.0.0.0
192 000a
223.255.255.255
Figura 2.10. Direcciones IP de Clase C
Esta clase de direcciones está pensada para subredes pequeñas con pocos equi-
pos (hasta 254 equipos, 2 menos de los 256 posibles valores de HostId, tal y
como se explica más adelante).
• Clase D: Se trata de direcciones de grupo multicast o multidestino. Cuando se

envía un datagrama a una dirección de destino correspondiente a la clase D, se
enviará a un grupo de equipos previamente definido. De esta forma, no es ne-
cesario tener que generar un datagrama para cada destinatario con cada direc-
ción unicast individual, si el contenido del datagrama es el mismo para todos.
No se deberá confundir, sin embargo, multicast con broadcast. Con broadcast
un datagrama se enviaría a todos los hosts de una red y no a un grupo de ellos.
Las direcciones multicast han de comenzar con los bits ´1110´. Véase la figura
2.11.
45
45
Direccionamiento
La e interconexión
32 bits Rango:
g
1110 Grupo Multicast (268435456) 224.0.0.0
224 000a
239.255.255.255
Figura 2.11. Direcciones IP de Clase D
• Clase E: Esta clase está reservada para posibles usos futuros.
32 bits
Rango:
1111 Reservado 240.0.0.0 a
24 2 2 2
247.255.255.255
Figura 2.12. Direcciones IP de Clase E
Tal y como se puede apreciar en el formato de cada dirección, el rango de los núme-
ros de dirección en la primera parte de la dirección viene restringido por la clase.
Por ejemplo, en la clase A la primera parte (NetId) debe estar entre 0 y 127.
Evidentemente, trabajar directamente con direcciones de 32 bits es poco práctico

para las personas (imagínese qué pasaría si los números telefónicos fueran de 32
dígitos) Como primera solución a este problema se utiliza la denominada notación
‘decimal punteada’ o dotted decimal. Consiste en pasar, por separado, cada uno de
los 4 bytes de la dirección IP (grupos de 8 bits consecutivos) a decimal, y separar
mediante un punto los 4 números decimales obtenidos. Al tratarse de grupos de 8
bits, los 4 números decimales serán números comprendidos entre 0 y 255, conside-
rándose direcciones inválidas las que tengan números fuera de este rango.
Por ejemplo, la dirección, 10011110 00101010 01100100 00000001 en binario,
se corresponde con la dirección 158.42.100.1 en formato dotted decimal.
A continuación se muestra un ejemplo de direcciones de cada una de las clases:
Clase A: 10.1.2.3
Clase B: 138.4.3.59
Clase C: 192.16.192.1
Clase D: 224.1.1.10
46
46
CapítuloLa
TCP/IP
Las empresas u organismos que necesiten de direcciones IP válidas, deberán solici-

tar y registrar las direcciones IPs públicas en proveedores de servicio de Internet
local o directamente en organismos oficiales, como, en el caso de Europa, el Regis-
tro RIR Europeo, el Réseaux IP Européennes (RIPE).
2.3.3.1. Direcciones IP Especiales
Algunos casos de direcciones IP especiales a tener en cuenta son los siguientes:
• Dirección de test o de Loopback: 127.0.0.0. Esta dirección se utiliza para

probar la configuración IP en un host y para comunicaciones internas entre
procesos IP. Si se envía un datagrama a dicha dirección, en realidad, se está
enviando a la propia máquina.
• Dirección de Subred (todos los bits del HostId a ‘0’): Por convenio, se uti-
liza para dar nombre a toda una subred. No se trata de una dirección válida.
Un ejemplo de dirección de una subred de clase B: 158.42.0.0
• Dirección de Broadcast directo (todos los bits del HostId a ‘1’): Para enviar
un datagrama a todos los hosts de una subred se emplea la dirección de
broadcast. Un ejemplo de dirección de broadcast para una subred de clase
B: 158.42.255.255. Un mensaje enviado a esta dirección llegaría a todos los
sistemas IP conectados a la subred de clase B 158.42.0.0.
• Dirección de broadcast limitado a la red local (todo a ‘1’):
255.255.255.255. Se utiliza normalmente desde dentro de una red para ha-
cer un envío masivo, a diferencia de la anterior que puede ser utilizada des-
de fuera de la red con el peligro que ello conlleva si no se controla bien.
• Direcciones privadas o de uso privado. Son direcciones reservadas que, por
convenio, no serán enrutables a Internet. Se pueden utilizar en el interior de
redes de uso privado para conectar sus equipos mediante IP. La RFC 1918
describe los 3 bloques de direcciones IPs privadas (los routers no deben en-
caminar estas direcciones IP hacia la Internet Global):
- 1 rango completo de direcciones Clase A (10.0.0.0/8)5
5
El número después de la barra inclinada indica los bits a ‘1’ de la máscara de subred. El significado de ésta se explica más
adelante en el capítulo
47
47
Direccionamiento
La e interconexión
- 16 rangos de direcciones Clase B (172.16.0.0/12: de 172.16.0.0 a

172.31.255.255)
- 256 rangos de direcciones Clase C (192.168.0.0/16)
2.3.3.2. Nombres IP
Trabajar con la notación dotted decimal, aunque simplifica la operación con las
direcciones de 32 bits, no es tan cómodo como cabría esperar. Para resolver defini-
tivamente este problema se hace uso de los denominados nombres IP. Consiste en
asignar a los sistemas nombres con significado comprensible para el usuario (nor-
malmente, en función de su localización). La traducción se realiza de forma interna
y transparente al usuario mediante, por ejemplo, el servicio DNS (Domain Name
System). DNS es una aplicación o servicio que traduce nombres IP a direcciones IP,
utilizando un sistema de bases de datos distribuidas en servidores conectados a
Internet.
La asignación de nombres IP se realiza partiendo de un dominio o raíz y añadiendo
los subdominios necesarios, de tal manera que tienen una estructura jerárquica.
En un principio, se definieron dos tipos de dominios raíz:
a) Asignados geográficamente, como, por ejemplo:
- .es: España.
- .uk: United Kingdom
- .it: Italia
b) Asignados por el tipo de organización, como, por ejemplo:
- .edu: educación.
- .mil: militar.
- .com: company.
- .con: instituciones con fines comerciales
- .gov: Instituciones gubernamentales.
- .org: organismos internacionales o Instituciones no gubernamentales.
- .net: Instituciones proveedoras de backbones.
En la práctica se adoptó fuera de EE.UU. la asociación de un dominio geográfico a
cada país, quedando a las instituciones administrativas de cada país la creación de
48
48
CapítuloLa
TCP/IP
sus dominios. Aunque existen muchas más opciones, se ha mostrado un ejemplo de

algunos de ellos.
La utilización de nombres IP jerárquicos permiten, por ejemplo, identificar equipos
concretos en instituciones específicas pertenecientes a un determinado territorio
geográfico. Por ejemplo, si se analiza el nombre IP cpu1.gnd.upv.es, se puede dedu-
cir que se trata de la dirección de un equipo denominado cpu1, localizado en el
campus de Gandia (gnd) de la Universidad Politécnica de Valencia (upv) en España
(es).
Un ejemplo común puede ser el nombre de dominio de un equipo de nombre prin-
cipal www (normalmente indica que contiene el servicio web o, dicho de otra mane-
ra, que es un equipo con funciones de servidor web) y que incluirá más subdomi-
nios, en función de la institución en donde resida dicha máquina:
- En British Telecom: www.bt.net.es
- En una empresa denominada XYZ: www.xyz.com.es
- En la UPV: www.upv.es
Es muy importante saber que una dirección IP no identifica un sistema sino una
conexión (interface) de un sistema a una subred. Por tanto, un sistema conectado a
varias subredes, como, por ejemplo, un router, tendrá varias direcciones (tantas
como subredes IP a las que esté conectado a través de diferentes interfaces, cada
uno con su propia dirección IP).
2.3.4. Formato de un datagrama IP
El formato general de un datagrama IP se muestra en la figura 2.13. Como se puede

observar, consiste en varias palabras de 32 bits, de las cuales, como mínimo, las 5
primeras se corresponden con la cabecera (20 bytes con campos obligatorios).
A continuación se explica el significado de cada uno de sus campos por separado:
• Campo Versión: 4 bits que indican la versión del protocolo con la que se ha
generado el datagrama. En este caso se trata de la versión 4.
• Campo Longitud de la Cabecera (Header length o HLEN): Es la longitud de
la cabecera medida en palabras de 32 bits. Sirve de puntero al inicio del campo
de datos. Puesto que este campo tiene 4 bits, la longitud máxima de la cabecera
es de 60 octetos (15 palabras de 32 bits). La longitud mínima es de 20 bytes
49
49
Direccionamiento
La e interconexión
(correspondiente a la longitud de las 5 palabras de 32 bits que contienen los

campos obligatorios de la cabecera).
32 bits
Versión HLEN TS Longitud

g Total
Identificación Flags Offset
TTL P t l
Protocolo Ch k
Checksum
Cabecera Dirección de origen
g
Dirección de destino
Opciones (de 0 a 40 bytes)
Padding
Campo de Datos
Figura 2.13. Formato del Datagrama IPv4
• Campo Tipo de Servicio (Type of Service o TS): Es el campo donde se indica

la calidad de servicio requerida para la transmisión del datagrama a través de
una red determinada. Existen redes que proporcionan calidad de servicio (QoS)
basada en prioridades (precedences), considerando unos tipos de tráfico más
importantes que otros (normalmente sólo aceptando tráfico con prioridades a
partir de un determinado valor cuando hay congestión en la red). Este campo lo
rellena quien envía el datagrama. Su utilidad inicial fue muy escasa, pero ha ido
aumentando con el paso del tiempo para ofrecer QoS. Especifica cómo debe
tratarse el datagrama dentro de Internet. La mejor elección será un compromiso
a tres bandas entre bajo retardo, alta fiabilidad y alto throughput.
Su formato se muestra en la figura 2.14.
0 1 2 3 4 5 6 7
PRIORIDAD D T R Sin uso
Figura 2.14. Campo Tipo de Servicio
50
50
CapítuloLa
TCP/IP
donde tenemos los siguientes sub-campos:

- Bits 0 a 2 (de prioridad): Se utiliza en casos de congestión. Indica la impor-
tancia del datagrama. (Valor 0: datagrama normal; valor 7: datagrama de
control). Se utiliza para permitir que la información de control tenga prefe-
rencia sobre la de datos.
- Bit 3 (D o Delay): Dar prioridad al retardo. Si está activado es que se re-
quiere bajo retardo.
- Bit 4 (T o Throughput): Dar prioridad al throughput. Si está activado es que
se requiere alto throughput.
- Bit 5 (R o Reliability): Dar prioridad a la fiabilidad. Si está activado es que
se requiere alta fiabilidad.
- Bits 6 y 7: reservados para uso futuro.
Los bits 3 a 5 especifican características deseables del servicio IP. Su cum-
plimiento dependerá de las subredes. La norma indica que sólo se puede
poner a ´1´ uno de los campos D, T y R . Con esto, el usuario decide a qué
quiere dar prioridad para su mensaje (retardo, throughput o fiabilidad).
Tabla 2.1. Significado de los bits del campo Tipo de Servicio
Bits Valor
Desde
0 Prioridad normal
Bits 0 a 2 (bits de prioridad)
hasta
7 Prioridad más alta (control de red).
0 para retardo normal
Bit 3 (Delay, D)
1 para bajo retardo
0 para throughput normal
Bit 4 (Throughput, T)
1 para alto throughput
0 para fiabilidad normal
Bit 5 (Reliability, R)
1 para alta fiabilidad
Bits 6 y 7 Reservados para uso futuro
Este campo sólo da una guía de los que el usuario solicita pero, después los
routers de la interred podrán cumplir o no con esta demanda dependiendo
de los recursos de la red. Puede que las rutas que existen hacia el destino no
puedan cumplir con lo solicitado. En caso de que sí lo cumplan, los routers
intentarán seleccionar aquella ruta, de entre todas las posibles, que cumpla
con la solicitud del originador del datagrama
• Campo Longitud Total: Es la longitud total del mensaje en bytes (incluida la
cabecera). Por ser un campo de 16 bits permite una longitud de hasta 65535 by-
tes (216). Datagramas de tal longitud no son prácticos para la mayoría de hosts y
51
51
Direccionamiento
La e interconexión
subredes. Según la RFC 791, todos los hosts deben estar preparados para acep-
tar datagramas hasta 576 bytes (bien lleguen enteros o bien en fragmentos). Se
recomienda que los hosts sólo envíen datagramas de más de 576 bytes si tienen
la seguridad de que el destino está preparado para aceptar datagramas de tal
longitud. Dicho tamaño de 576 se escogió para permitir un tamaño razonable
del bloque de datos a ser transmitido adicionalmente a la información requerida
de la cabecera.
• Campos de segmentación y re-ensamblado. Constituyen la segunda palabra
de 32 bits de la cabecera IP. Antes de explicar su significado, se explicará la
necesidad y el proceso de fragmentación seguido por IP.
El nivel IP ha de acomodar cada datagrama en una trama (del nivel de enlace) o
paquete (de nivel de red) de la subred subyacente, según ésta sea de nivel 2 o
nivel 3, respectivamente. Cada tecnología de subred tiene un valor máximo de
PDU (trama o paquete) que puede aceptar, como, por ejemplo, en Ethernet tie-
ne un valor aproximado de 1500 bytes y en Token-Ring de unos 4440 bytes.
Este valor máximo es la MTU (Maximum Transfer Unit).
Si el datagrama no cabe en dicha PDU se ha de descomponer en trozos más pe-
queños (por defecto, lo hace IP). A dichos trozos se les denomina fragmentos y
a la operación de dividir el datagrama en fragmentos se llama fragmentación.
Supongamos, como ejemplo, la situación de la figura 2.15: a un router le llega
un datagrama de 2020 bytes (20 bytes de cabecera6 + 2000 bytes del campo de
datos) y tiene que reenviarlo por una red que soporta un tamaño del campo de
datos de su MTU de 820 bytes (20 + 800)
20 2000 Red IP
Datos max. MTU: 820 bytes
Router
Figura 2.15. Fragmentación IP
El router sabe que tiene que reenviar el datagrama de 2020 octetos por una red
en la que el tamaño máximo del campo de datos de la MTU es de 820 octetos.
Por tanto, antes de reenviar, procede a segmentar, generando tres datagramas
que respeten la longitud máxima. En los 820 octetos de capacidad máxima del
campo de datos de la MTU de la subred, cabe un datagrama de 20 octetos de ca-
becera y un máximo de 800 octetos en el campo de datos. Por tanto, se tomará el
campo de datos del datagrama original de 2000 octetos y se dividirá en bloques
6
Suponemos cabeceras de longitud mínima, con sólo los campos obligatorios.
52
52
CapítuloLa
TCP/IP
de 800 bytes, resultando dos bloques de 800 bytes y un tercero con 400 bytes (2
x 800 + 400 = 2000). A cada uno se le añadirá su cabecera IP, formando el data-
grama correspondiente, tal como se muestra en la figura 2.16.
Estos tres datagramas se envían por la subred y son tratados y encaminados de
forma independiente, por lo que pueden llegar desordenados al destino. Se debe-
rá de indicar de algún modo que forman parte de dicho datagrama original para
que en el destino se puedan reordenar los fragmentos y reconstruir el bloque de
2000 octetos del datagrama original. Para ello están los campos de segmentación
y re-ensamblado de la cabecera IP.
NOTA.- Si se pierde un solo fragmento, el datagrama entero es descartado.
20 2000
20 800
200 800
200 400
00
Figura 2.16. Datagrama original y los 3 datagramas generados en el proceso de fragmentación
Los campos de la cabecera que se utilizan para funciones de segmentación y re-

ensamblado son los 3 siguientes:
- Identificador: Consiste en un identificador del datagrama, asignado por el
originador del mismo. Cuando un datagrama se segmenta, el valor de este
campo se copiará en el campo identificador de todos los datagramas gene-
rados en dicho proceso. Será el mismo para todos los datagramas genera-
dos al segmentar, e igual al del datagrama original. Junto con la dirección
IP de origen identifican al datagrama original como un todo (no se identifi-
ca a cada uno de los fragmentos).
- Offset: Indica la posición relativa del bloque de datos contenido en cada
datagrama generado tras un proceso de fragmentación, con respecto al
inicio del campo de datos del datagrama original. Se mide en unidades de 8
bytes, es decir, en unidades de 64 bits, para ahorrar espacio en la cabecera.
Indica la posición del bloque de datos del fragmento dentro del campo de
datos del datagrama original, para facilitar, así, el re-ensamblado en el re-
ceptor. El primer fragmento tiene un offset de 0 bytes.
53
53
Direccionamiento
La e interconexión
El host destino utilizará el identificador y el offset para ensamblar todos los

fragmentos de la misma fuente con el mismo identificador.
- Flags: Se trata de 3 bits que tienen el siguiente significado:
0 DF MF
Figura 2.17. Flags
• Bit 0: reservado. Su valor debe ser ‘0’.

• Bit 1 (bit DF): Especifica si el datagrama puede ser fragmentado o
no Si vale ‘0’, el datagrama se podrá fragmentar en ruta (May
Fragment). Si vale ‘1’ el datagrama no se podrá fragmentar en ruta
(Do Not Fragment). Si está a ‘1’ y llega a una red con MTU más
pequeña, se descartaría y se enviaría un mensaje de error (del pro-
tocolo ICMP que se explica más adelante en este capítulo) al origi-
nador del datagrama descartado.
• Bit 2 (bit MF): si vale ‘0’, el datagrama contiene el último frag-
mento o bloque de datos de un datagrama original segmentado
(Last Fragment). Si vale ‘1’ el datagrama contiene un fragmento o
bloque de datos de un datagrama original que no es el de la última
posición (More Fragments).
Una vez ha llegado el último bloque o fragmento, el destino podrá
saber la longitud total del datagrama original que se fragmentó y
así podrá re-ensamblarlo cuando tenga todos los fragmentos (ver
ejemplo siguiente). Dicha longitud sería el offset (en bytes) del úl-
timo fragmento más la longitud del bloque de datos de dicho últi-
mo fragmento (en bytes)
En el siguiente ejemplo veremos cómo se calcularía el valor del offset de cada

datagrama generado con la fragmentación:
54
54
CapítuloLa
TCP/IP
800 800 400
Offset
O set del
de
primer fragmento: 0
Offset del 2º fragmento

800 bytes/8
b /8 = 100
Offset del 33º fragmento

b tes/8 = 200
1600 bytes/8
Figura 2.18. Segmentación y Re-ensamblado
Por tanto, si suponemos un identificador de 50 en el datagrama original, los

campos de segmentación y re-ensamblado de cada datagrama generado serían
los siguientes:
Ident = 50
Offset = 0
20 800 MF = ‘1’
1
DT = ‘0’
0
Ident = 500
Off t = 100
Offset
20 800 MF = ‘1’
DT = ‘0’
Ident = 50
Offset = 200
20 400 MF = ‘0’
DT = ‘0’
Figura 2.19. Campos de Segmentación y Re-ensamblado
Estos tres datagramas son enviados hasta el destino, donde se re-ensamblará el

datagrama original. Los fragmentos sólo se re-ensamblarán en el destino del
datagrama original ya que no se puede asegurar que pasen todos ellos por un
mismo equipos de interconexión, ya que se encaminan de forma independiente
en su ruta hacia el destino. IP es no orientado a conexión y por ello al destino
le podrían llegar los fragmentos por varias rutas diferentes y, por tanto, desor-
denados.
Por el hecho de que IP es, además, no fiable, al llegar el primer fragmento se
iniciará un temporizador. Si transcurrido un tiempo no han llegado todos los
55
55
Direccionamiento
La e interconexión
fragmentos se descartan los que sí se hayan recibido y se hará uso de un proto-

colo complementario a IP, el protocolo ICMP (que se verá más adelante), para
enviar una notificación de dicho error por descarte del datagrama.
• Campo TTL (Time To Live). Se utiliza para evitar situaciones de congestión.
Limita el tiempo que un datagrama puede permanecer en la red IP. El valor del
campo TTL se decrementa en una unidad cada vez que pasa por un router si
todo va bien, o, en una unidad por segundo, mientras siga en memoria del
router en situaciones de congestión. Al llegar a cero el datagrama es descarta-
do. El propósito de este campo es que los datagramas que no puedan ser entre-
gados a su destino sean descartados, limitando el máximo tiempo de perma-
nencia del datagrama en la red IP.
• Campo Protocolo: Especifica de qué protocolo es la PDU encapsulada en el
datagrama IP (TCP, UDP, ICMP …). Indica el protocolo al que se pasará lo
que contenga el campo de datos, después del procesado IP. Los valores corres-
pondientes a cada protocolo están definidos en la RFC 790.
• Campo Checksum: Es el resultado de aplicar un código de protección de erro-
res a la cabecera con los bits del campo checksum puestos a cero. Normalmen-
te, se suman todos los bits de la cabecera, se complementa la suma a uno y se
pone el resultado en el campo checksum. Este campo se modifica en cada
router, puesto que al decrementarse el campo TTL la cabecera varía.
• Campos de Direcciones IP de origen y destino: Son de 32 bits cada uno y
contienen la dirección IP del origen y del destinatario del datagrama, respecti-
vamente.
• Campo de Opciones: En este campo se especifican algunas opciones de las
que se puede hacer uso. Por ejemplo, una de ellas es conocida como registro
de ruta. Cuando se emplea esta opción todos los routers por los que pase el da-
tagrama copian en este campo su dirección de forma acumulativa. Ya que co-
mo máximo este campo puede tener 40 octetos, sólo se podrían registrar hasta
10 direcciones (de 4 bytes cada una).
• Campo de Relleno: En caso de que el campo de opciones no tenga una longi-
tud exacta en cuanto a palabras de 32 bits se refiere, se utilizará relleno (pad-
ding).
• Campo de Datos: Campo que contendrá los datos del datagrama. Su longitud
se puede obtener restando resta del valor del campo Longitud Total el valor del
campo Longitud de la Cabecera (ambos en bytes).
56
56
CapítuloLa
TCP/IP
2.4. ICMP (Internet Control Message Protocol)
2.4.1. Introducción
Tal y como se ha indicado anteriormente, el protocolo IP ofrece un servicio de red

de tipo datagrama, sin conexión y no fiable. Los datagramas IP se encaminan de
forma independiente nodo a nodo, por lo que pueden seguir diferentes rutas y llegar
desordenados, puede perderse alguno, etc. Además, el protocolo IP no incluye nin-
gún procedimiento de control de errores ni de diagnóstico. En un router, cuando se
pierde o descarta un datagrama (por ejemplo, por checksum incorrecto, o por no
encontrar la ruta hacia el destino), IP no envía notificación alguna al origen de di-
cho datagrama para que pueda realizar, si fuera posible, las acciones oportunas para
corregir el problema. Para ello, es necesaria la existencia de un protocolo de control
adicional que proporcione a IP características que hagan a las redes IP un poco más
fiables. Este protocolo es el protocolo de control ICMP (Internet Control Message
Protocol), que colabora con IP para ofrecer un mejor servicio a los usuarios.
Los mensajes del protocolo ICMP se envían encapsulados en datagramas IP. El
esquema general que se sigue a la hora de encapsular es el mostrado en la figura
2.20.
Cabecera
C b
Datos ICMP
ICMP
Cabecera
Datos Datagrama IP
IP
Figura 2.20. Encapsulamiento de ICMP sobre IP
Básicamente, el protocolo ICMP tiene dos funciones principales:

1. Informar de diversos errores o incidencias inesperadas que pueden produ-
cirse en el envío de un datagrama.
2. Facilitar el diagnóstico en interconexión de redes y obtener información.
A continuación se explican algunos tipos de mensajes para realizar ambas funcio-

nes.
57
57
Direccionamiento
La e interconexión
2.4.2. Tipos de mensajes ICMP
Existen dos tipos principales de mensajes ICMP: los mensajes de error y los mensa-
jes con la utilidad de facilitar el diagnóstico comentado en el apartado anterior.
2.4.2.1. Mensajes de Error
Los mensajes de error ICMP proporcionan un mecanismo de notificación de errores

(error reporting mechanism). En ningún caso ICMP proporciona información sobre
el procedimiento de corrección de errores a emplear.
El formato común para dichos mensajes de error es el siguiente:
0 8 16 31
Ti
Tipo Código Checksum
D t Opcionales
Datos O i l
Figura 2.21. Formato general para los mensajes de error ICMP
El significado de cada campo es el siguiente:

Campo TIPO (8 bits): identifica el tipo del mensaje ICMP, así como su
formato.
Campo CÓDIGO (8 bits): Proporciona más información sobre el tipo de
mensaje.
Campo CHECKSUM (16 bits): código de comprobación de errores basado
en un procedimiento de suma de verificación.
Datos opcionales: algunos mensajes ICMP incluyen información importan-
te en este campo (tal y como se explica para uno de los mensajes estudia-
dos posteriormente).
58
58
CapítuloLa
TCP/IP
Entre otros, se pueden destacar los siguientes tipos de mensajes ICMP de error:
1. Destino inalcanzable o Destination Unreachable (Tipo=3): Se envía cuando se
descarta un mensaje. El campo de código refina la causa del descarte:
• '0' (Network Unreachable): la red en la que está el destino se encuentra
inalcanzable. El datagrama ha llegado a un router que desconoce la ruta
hasta la red de destino (no la tiene configurada en su tabla de encamina-
miento).
• '1' (Host Unreachable): aunque la red sí es alcanzable, el host destino es
inalcanzable (el hardware puede estar temporalmente fuera de servicio, por
ejemplo, por tareas de mantenimiento).
• '2' (Protocol Unreachable): la red destino es alcanzable y el host destino
está bien. Sin embargo, el valor del campo de protocolo del datagrama no
coincide con ninguno de los protocolos ejecutándose en dicho host (por
tanto, el mensaje que contiene el datagrama no se puede interpretar por el
host destino).
• '3' (Port Unreachable): Error por puerto de destino inalcanzable. Puede que
el puerto esté cerrado en el equipo de destino o protegido por un cortafue-
gos (firewall).
• ‘4’ (Fragmentación needed and DF set). Error que ocurre porque el data-
grama ha llegado a un router que necesita fragmentarlo para poder reen-
viarlo pero no puede por tener el bit ‘do not fragment’ activado.
2. Source Quench (Tipo =4): En este mensaje el código es siempre 0. Avisa de
descarte de un datagrama debido a la existencia de congestión en la interred.
Lo enviará el router cada vez que descarte un datagrama.
3. Time exceeded for datagram (Tipo =11): Avisa de un descarte por exceso de
tiempo en el sistema.
Puede enviarse con dos valores posibles en el campo Código:
• '0': descarte de un datagrama porque su TTL ha llegado a 0.
• '1': ha vencido el timeout de re-ensamblado (no han llegado todos
los trozos al destino en el tiempo esperado y por tanto se han des-
cartado los fragmentos que sí habían llegado, generándose un men-
saje de error de este tipo).
En la parte opcional de un mensaje de notificación de un determinado error, se in-

cluye la cabecera IP y los primeros 64 bits (que, probablemente, contendrán la ca-
becera del nivel de transporte) del datagrama que se descartó. De esta manera, al
59
59
Direccionamiento
La e interconexión
recibir el mensaje de error se puede identificar qué datagrama de entre todos los
enviados es el que generó realmente dicho mensaje de error.
2.4.2.2. Mensajes de Diagnóstico
Los mensajes ICMP utilizados para diagnóstico son los denominados Echo Request
y Echo Reply, que responden ambos al mismo formato (con valores del campo Tipo
de 8 y 0, respectivamente):
0 8 16 31
Ti (0 u 8)
Tipo Código (0) Checksum
Identificador Núm Secuencia
Datos Opcionales
Figura 2.22. Formato de los mensajes de Echo Request y Echo Reply
Ambos mensajes se utilizan para saber si el destino es accesible (por ejemplo, en las
utilidades ping y trace route, explicadas a continuación).
La idea es que cuando se envía un mensaje ICMP de tipo Echo Request, se obliga al
destino a responder con el correspondiente Echo Reply. También se puede usar el
campo de datos para pruebas más complejas, añadir marcas de tiempo, direcciones
IP, etc.
2.4.3. Utilidades de red basadas en el uso de mensajes ICMP
En este apartado se explicará el funcionamiento de dos utilidades muy empleadas

de los mensajes ICMP de diagnóstico, como son las de ping y trace route.
60
60
CapítuloLa
TCP/IP
2.4.3.1. Utilidad de comprobación de alcanzabilidad y estado de un sistema remo-

to.
En la mayoría de sistemas los usuarios utilizan el comando ping para comprobar la

alcanzabilidad de un destino específico a través de redes IP. Se trata de una utilidad
que invoca el envío de un mensaje ICMP de tipo Echo Request a un equipo deter-
minado. Una vez que el destino devuelve el Echo Reply correspondiente, se conclu-
ye que el destino es perfectamente alcanzable, es decir que se puede tener una co-
municación IP con el mismo.
Ejemplo: Suponer que, en la red de la figura, el equipo A ejecuta la utilidad ping
pasándole la IP del equipo D como parámetro (IPD), es decir, ejecutaría el comando
ping IPD.
A B C D
IPA IPB IPC IPD
Figura 2.23. Envío del mensaje Echo Request
Realmente, al ejecutar el comando, se envían 4 paquetes ICMP de tipo Echo Re-

quest, encapsulados en un datagrama IP enviado a la dirección IP de D (IPD), y cada
uno con un identificador y un número de secuencia consecutivo.
0 8 166 331
Tipo 8 Código 0 Checksum
Id tifi d X
Identificador Nú Secuencia
Núm S i Y
Datos Opcionales
Figura 2.24. Mensaje Echo Request empleado en la utilidad Ping
El equipo D contestará al equipo A con un mensaje ICMP de tipo Echo Reply por
cada mensaje de tipo Echo Request recibido (con idénticos identificadores y número
de secuencia), es decir, enviará 4 respuestas, encapsuladas cada una en un datagra-
ma independiente enviado a la dirección IP de A (IPA).
61
61
Direccionamiento
La e interconexión
A B C D
IPA IPB IPC IPD
Figura 2.25. Envío del mensaje Echo Reply
El formato del mensaje Echo Reply es el siguiente:
0 8 16 31
Tipo 0 Código 0 Checksum
Id ifi d X
Identificador Nú Secuencia
Núm S i Y
D t Opcionales
Datos O i l
Figura 2.26. Mensaje Echo Reply
A continuación se muestra el resultado de ejecutar el comando ping en una ventana

de comandos en un PC con sistema operativo Microsoft Windows.
Figura 2.27. Ejecución del Comando Ping
62
62
CapítuloLa
TCP/IP
2.4.3.2. Utilidad de trazabilidad de rutas (Trace route)
En la mayoría de sistemas el comando que utilizan los usuarios es el comando tra-

cert. Esta utilidad permite obtener la ruta más probable que siguen los paquetes IP
desde un origen IP a un destino IP. Es decir, devuelve una lista con los routers in-
termedios existentes entre los dos equipos. Si se detecta falta de conectividad entre
equipo origen destino IP, tracert ayuda a detectar a partir de qué router se produce
el error.
Los mensajes ICMP enviados son los siguientes: el equipo origen envía un mensaje
ICMP Echo Request (tipo 8, código 0) encapsulado en un datagrama con dirección
IP origen la del equipo que ejecuta el comando y como IP destino la que se pasa
como parámetro al comando; El destino, cuando le llegue el mensaje anterior res-
ponderá con un mensaje ICMP Echo Reply (tipo 0, código 0) dirigido al equipo
origen.
El procedimiento seguido para obtener la dirección de los routers intermedios con-
siste en forzar un mensaje de error en dichos routers, que éstos enviarán al equipo
origen en un datagrama con dirección de origen la de dichos routers (de dicho data-
grama se obtendrá la dirección de cada router intermedio). Para ello, se forzará a
que el TTL de los datagramas enviados desde el origen venza (llegue a 0) en cada
uno de los routers intermedios, lo cual les forzará a enviar un mensaje ICMP de
error de destino inalcanzable por TTL vencido (tipo 11, código 0).
Para cumplir con su cometido el proceso seguido es el siguiente. Primero se envía
un Echo Request, encapsulado en un datagrama con TTL a 1. Esto ocasionará for-
zosamente que el primer router envíe un mensaje ICMP de error por descarte por
TTL=0. Dicho mensaje ICMP irá encapsulado en un datagrama enviado por el
router en cuestión y, por tanto, incluirá su dirección IP (como origen de dicho data-
grama). De esta manera, en este primer paso se ha obtenido la dirección IP del pri-
mer router. A continuación se repite el proceso: se envía otro Echo Request, encap-
sulado en un datagrama con TTL=2, 3...., y así sucesivamente hasta que se reciba el
mensaje Echo Reply enviado por el equipo destino, indicando que el mensaje Echo
Request llegó al destino. Antes de haber recibido el Echo Reply del equipo destino,
se habrán ido recibiendo progresivamente los mensajes de error de todos los routers
atravesados, a la vez que sus direcciones IP.
Nótese que la información devuelta por la utilidad tracert no es una información
totalmente fiable, pues todos los datagramas enviados, por definición del servicio
IP, no tienen por qué seguir la misma ruta hacia el destino.
63
63
Direccionamiento
La e interconexión
A continuación se muestra el resultado de ejecutar el comando tracert en una ven-

tana de comandos en un PC con sistema operativo Microsoft Windows.
Figura 2.28. Ejecución del Comando tracert
2.4.4. Observación con respecto a los mensajes ICMP
Nótese que, aunque se dice que estos mensajes de ICMP ofrecen la fiabilidad que le
falta a IP, realmente no es así. Si un mensaje ICMP se perdiera en la red, no se
vuelve a enviar otro mensaje de error. Por tanto, a pesar de que ofrece más fiabili-
dad o protección frente a errores, no se puede afirmar que se asegure fiabilidad
total.
2.5. Envío de información en IP
El encaminamiento IP (IP Routing), que se estudia con más profundidad en un capí-

tulo posterior, consiste en reenviar los datagramas IP en función de la dirección IP
de destino contenida en su cabecera, independientemente de otros datagramas gene-
rados por la misma fuente. Existen dos tipos de envío de información que se es-
quematizan en la siguiente figura: Transmisión Directa e Indirecta.
64
64
CapítuloLa
TCP/IP
IPA IPB
TRANSMISIÓN
MACA MACB DIRECTA
Oi
Origen y destino
d i en una misma
i red
d
IPA
MACA Red IP 1
MAC1R TRANSMISIÓN
IP1R
INDIRECTA
IPB
Router
MAC2R IP2R
MACB
Red IP 2
Oi
Origen y ddestino
ti en redes
d didistintas
ti t
Figura 2.29. Transmisión Directa e Indirecta
2.5.1. Entrega o Transmisión Directa
Se produce entre dos hosts o equipos que están en la misma subred IP, es decir,
cuando el host origen y el host destino están conectados a la misma subred física.
En este caso, el protocolo de acceso a la subred encapsula al datagrama en una PDU
de subred (por ejemplo, un paquete en una subred X.25, o una trama en una subred
Ethernet).
Supongamos el caso de la figura, con una subred Ethernet.
IPA IPB
MACA MACB
Figura 2.30. Transmisión Directa
65
65
Direccionamiento
La e interconexión
El equipo A conoce las direcciones IP origen (IPA) y destino (IPB) y las incluye en
la cabecera IP del datagrama que envía. Además, también conoce su propia direc-
ción física o MAC (MACA). Al ser una transmisión directa, la transmisión entre los
dos equipos es a nivel de subred (Ethernet, en este caso). Para encapsular el data-
grama y enviarlo en una trama de nivel 2 necesita conocer la dirección física MACB
(destino al que enviar la trama). Para ello se necesitará un mecanismo de resolución
de direcciones que le proporcione la MACB a partir de la IPB conocida (por ejem-
plo, mediante el protocolo ARP que se explica más adelante).
El procedimiento es el mostrado en la figura siguiente:
IPA IPB
MACA MACB
D t
Dest Oi
Orig Tipo
Ti Destt
D Orig
O i
… Datos Cola
MACB MACA 800 IPB IPA
Capa IP: Datagrama IP
Capa 2: Trama Ethernet

7
Figura 2.31. Encapsulamiento en una Transmisión Directa
2.5.2. Entrega o Transmisión indirecta
Es el caso más general y se realiza entre dos equipos o hosts que están en diferentes
subredes IP, es decir, cuando el host origen y el host destino están en diferentes
subredes físicas. Las diferentes subredes estarán conectadas mediante routers IP.
Por tanto, el datagrama irá pasando de una red a otra, a través de los diferentes
routers, hasta que llegue a la subred a la que esté conectado el equipo destino.
En este caso, tenemos que tener en cuenta varios aspectos. Mientras un paquete se
transmite de un dispositivo IP a otro, las direcciones IP de origen y destino del da-
tagrama enviado no cambian en todo su trayecto entre el host origen y el host des-
tino. Por otro lado, las direcciones físicas de origen y destino de las PDU de subred
7
El campo Tipo, con valor 800, en la cabecera de la trama Ethernet indica que en su campo de datos se está encapsulando un
datagrama IP.
66
66
CapítuloLa
TCP/IP
sí que cambian a medida que la información (el datagrama) se reenvía de un dispo-

sitivo a otro (salto a salto). En cada salto, es decir, en cada router, el campo TTL del
datagrama se irá decrementando en 1 unidad (por salto o por segundo transcurrido
en el interior del router) hasta llegar a cero, para acotar el tiempo de vida del data-
grama.
Supongamos el caso de la figura 2.32, con dos subredes Ethernet unidas por un
único router, en el que el host A de la red IP 1 desea enviar un paquete al host B que
está en la red IP 2.
IPA
Red IP 1
MACA
MAC1R IP1R
IPB
Router
MAC2R IP2R
MACB
Red IP 2
Figura 2.32. Transmisión Indirecta
La transmisión indirecta, en este caso, se realiza en varios pasos:

1. El host A descubre que host B no está en su red (comparando el prefijo de
subred (NetId+SubnetId) de la dirección IP de B con el de la suya propia).
Analizará su tabla de encaminamiento y encontrará en ella la dirección IP
del siguiente nodo al que le tiene que enviar la información. Se obtendrá
IP1R del Router intermedio (fíjese que es la IP de la interface del router
perteneciente a la misma red IP del Host A).
2. El host A encapsulará el datagrama en una trama Ethernet con dirección
MAC origen la suya propia (MACA) y como dirección MAC de destino la
asociada a la IP obtenida mediante el proceso explicado anteriormente
(MAC1R), que puede obtenerse utilizando ARP).
3. El router recibe la trama enviada por el host A dirigida a él, desencapsulará
el datagrama, eliminando cabecera y cola Ethernet de la trama. Examinará
la IP de destino IPB y, tal como se explica más adelante, buscará en su tabla
de encaminamiento la ruta a la subred a la que pertenece dicha dirección
(Red IP 2). El router comprobará que se trata de una red conectada direc-
tamente, es decir, que el destino está en una red a la que pertenece el router
(tendremos, por tanto, una transmisión directa entre el router y el host B).
Si no la tiene almacenada, el router obtendría la dirección MAC asociada a
la dirección IP de destino IPB (por ejemplo, utilizando ARP).
67
67
Direccionamiento
La e interconexión
4. El router encapsula el datagrama IP en una nueva trama Ethernet con direc-

ción origen la MAC2R del interface de salida del router en la red 2 y direc-
ción destino la MAC del equipo Host B (MACB), y la envía a través de la
interface de la red IP 2.
IPA
Red IP 1
MACA
MAC1R IP1R
IPB
Router
MAC2R IP2R
Capa 2: Trama Ethernet MACB
Red IP 2
C
Capa IP
IP: D
Datagrama
t IP
Dest Orig Tipo Dest Orig

… Datos Cola
MAC1R MACA 800 IPB IPA
a) Pasos 1 y 2
IPA
R d IP 1
Red
MACA
MAC1R IP1R
IPB
Router
MAC2R IP2R
MACB
Capa 2: Trama Ethernet Red IP 2
C
Capa IP
IP: D
Datagrama
t IP
Dest Orig Tipo Dest Orig

… Datos Cola
MACB MAC2R 800 IPB IPA
b) Pasos 3 y 4
Figura 2.33. Pasos de la Transmisión Indirecta del ejemplo
Con 3 redes IP o más el procedimiento sería el mismo, pasando el datagrama (sin

cambiar sus direcciones IP de origen y destino) de router a router, encapsulado en
tramas Ethernet, con las direcciones MAC origen y destino cambiando en cada
paso, tal como se muestra en la figura 2.34.
68
68
CapítuloLa
TCP/IP
IPA
Red IP 1
MACA
MAC1R1 IP1R1
Router 1
MAC2R1 IP2R1 Red IP 2
MAC2R2 IP2R2
IPB
Router 2
MAC3R2 IP3R2
MACB
Red IP 3
Figura 2.34. Transmisión indirecta con 3 subredes Ethernet
Se puede decir que una entrega indirecta consta de varias entregas directas. En la
figura anterior se aprecia que existen 3 entregas directas representadas por las fle-
chas curvadas.
2.5.3. Tablas de encaminamiento
Todo equipo IP almacena información sobre los posibles destinos y cómo acceder a
ellos. Esta información es almacenada en las tablas de encaminamiento. Estas tablas
pueden ser configuradas bien de forma manual o bien de forma dinámica mediante
la ejecución de algoritmos de encaminamiento. Se almacena en la memoria RAM
de los equipos. Si se apaga el equipo, las rutas obtenidas dinámicamente se pierden
y se deben volver a calcular/obtener. Son el elemento más importante en la interco-
nexión de redes y son un punto muy atractivo para posibles ataques a la red.
El encaminamiento IP está basado en estas tablas de encaminamiento (table-driven
IP Routing). Cuando un host o un router tiene que enviar un datagrama a un destino
de la interred, éste consultará su tabla de encaminamiento para decidir a quién en-
viárselo para que llegue, finalmente, al destino (tras una o varias entregas directas,
tal y como se ha visto en el apartado anterior).
Tablas mal configuradas pueden producir varios problemas, como, por ejemplo,
bucles de encaminamiento, pérdidas de datagramas y retardos indeseados.
Básicamente, las tablas de encaminamiento constan de 2 columnas principales (más
adelante se irán introduciendo otras columnas, como la de máscara de subred y
69
69
Direccionamiento
La e interconexión
coste de la ruta): una para los destinos y otra para la dirección IP del siguiente nodo
al que se le debe enviar el datagrama IP para que, bien directamente o indirectamen-
te (en varios saltos), acabe llegando al destino. Esta idea de almacenar en la tabla de
encaminamiento el siguiente salto para alcanzar a cada posible destino se denomina
next-hop Routing.
La columna de destinos, puede contener información de varios tipos
- Direcciones específicas de sistemas concretos. Se identifica por su direc-
ción IP completa (netid + HostId). Suelen ser de equipos conectados a las
mismas redes físicas que el propietario de la tabla. En algunos casos no es
necesario su uso (por ejemplo, en entornos de red local Ethernet). No obs-
tante, este tipo de entradas en la tabla las suelen especificar los administra-
dores de redes para decidir la ruta hacia equipos específicos (por ejemplo,
servidores o para realizar test de conexiones), técnica denominada per-host
Routing.
- Direcciones de Subred. Para no tener que identificar a todos los posibles
destinos dentro de una red IP, se puede emplear la dirección de la subred
(HostId a cero). De esta manera, el tamaño de la tabla se reduce. Esta es
una de las ventajas del direccionamiento jerárquico ya que los routers, a la
hora de encaminar, deben examinar en la mayoría de casos sólo el NetId de
la dirección para tomar las decisiones de encaminamiento, lo que agiliza
significativamente el proceso.
- Ruta por defecto. Ayuda a reducir al máximo la tabla de encaminamiento y
se asocia a la dirección de destino 0.0.0.0. Se suele colocar como la última
entrada de la tabla de encaminamiento e indicará la ruta que seguirán aque-
llos datagramas cuya dirección de destino no coincida o no se encuentre
dentro de las direcciones anteriores. Se usa, normalmente, en aquellas su-
bredes que, por ejemplo, acceden a través de un único router al resto de la
interred. Se debe tener especial cuidado a la hora de configurar rutas por
defecto en los equipos y hacerlo sólo en caso de que sean beneficiosas y
comprobando que no afecten negativamente al rendimiento de la interred.
En la figura 2.35 se muestra un ejemplo de una tabla de encaminamiento.

El orden de consulta es de lo más específico a lo menos específico (en caso contra-
rio, en caso de existir, la decisión de encaminamiento siempre se decantaría por la
ruta por defecto, etc.).
70
70
CapítuloLa
TCP/IP
Direcciones
Di i Direcciones IP
IP Destino Siguiente Nodo
158.20.100.2 158.20.100.2
Direcciones
Di i
158.20.100.3 158.20.100.3
d Si
de Sistema
… …
158 20 200 0
158.20.200.0 158 20 100 1
158.20.100.1
Direcciones 158 20 300 0
158.20.300.0 158 20 100 1
158.20.100.1
de Subred 158.20.400.0 158.20.100.1
… …
Ruta por defecto 0000
0.0.0.0 158 20 100 254
158.20.100.254
Figura 2.35. Tablas de Encaminamiento IP
Cabe destacar que en la columna de la derecha sólo podrá haber direcciones IP de

equipos (normalmente pertenecerán a routers) que pertenecen a las mismas subre-
des IP (conectados a alguna red física en común) que el nodo propietario de la tabla,
es decir, que con dichos equipos existirá una transmisión o entrega directa (al si-
guiente nodo).
RED
192.168.2.0
192 168 2 0
.2.1 .2.2
Router
INTERNET .1.2
Router .1.1
11 RED
192.168.3.0
RED
192.168.1.0 .3.4
34
.1.4 .1.3 Router

.3.1
.4.3
.4.1
41
Router
.4.4 .4.2
42 .5.2
52
RED
192.168.4.0 Router
Router .5.1
51
.6.1
RED
192.168.5.0
RED
192,168.6.0 .5.3
.6.2
62
Figura 2.36. Escenario IP
71
71
Direccionamiento
La e interconexión
En el ejemplo de la figura 2.36, la tabla de encaminamiento del router central (den-

tro de un círculo con línea de puntos) sería:
Direcciones Di
Direcciones
i IP
IP D
Destino
ti Siguiente
g Nodo
192 168 1 1
192.168.1.1 192 168 1 1
192.168.1.1
192.168.1.2 192.168.1.2
Direcciones
192.168.1.3 192.168.1.3
d Si
de Sistema
192 168 5 1
192.168.5.1 192 168 5 1
192.168.5.1
192 168 5 3
192.168.5.3 192 168 5 3
192.168.5.3
192.168.2.0
192 168 2 0 192.168.1.2
192 168 1 2
Direcciones 192 168 3 0
192.168.3.0 192 168 1 3
192.168.1.3
d S
de Subred
b d 192.168.4.0 192.168.5.1
192.168.6.0 192.168.5.1
Ruta ppor defecto 0000
0.0.0.0 192 168 1 1
192.168.1.1
Figura 2.37. Tabla de Encaminamiento del router central
Nótese que, si se quiere simplificar al máximo la tabla, todas las filas de la tabla
cuya dirección del siguiente nodo (segunda columna) coincide con el de la fila de la
ruta por defecto (192.168.1.1) se podrían eliminar de la tabla ya que, por defecto,
los datagramas se reenviarán a dicho siguiente nodo.
Las subredes a las que un nodo está conectado, en general, no suelen estar en la
tabla de encaminamiento, pero para hacer más completo el ejemplo hemos supuesto
que no están configuradas.
2.5.4. Resolución de Direcciones
Aunque en las interredes IP se trabaje con direcciones IP para facilitar el encami-

namiento de la información, la comunicación real, máquina a máquina se realiza
utilizando la tecnología de la subred a la que pertenecen ambas máquinas y, por
tanto, utilizando las direcciones de subred (físicas) de ambas.
Los mecanismos de encaminamiento IP trabajan con direcciones IP. De las tablas
de encaminamiento se obtiene la dirección IP del siguiente nodo al que enviarle la
información, pero no su dirección física. El problema se reducirá a obtener, a partir
de una dirección IP, la dirección física de la subred correspondiente. Cada estación
deberá activar un mecanismo de resolución de direcciones del tipo: dirsub= f (dirIP).
72
72
CapítuloLa
TCP/IP
Este problema es comúnmente conocido como el problema de resolución de direc-

ciones (address resolution problem) y existen varias soluciones al mismo que se
explican a continuación.
2.5.4.1. Utilización de tablas estáticas
En este caso, cada equipo tendría una tabla con asignaciones estáticas con direccio-
nes IP y sus correspondientes direcciones de subred asociadas, tal y como se mues-
tra en la figura para una red Ethernet.
IPA IPB IPC
MACA MACB MACC
Di IP
Dir Di Sub
Dir S b Di IP
Dir Di Sub
Dir S b Di IP
Dir Di Sub
Dir S b
IPB MACB IPA MACA IPA MACA
IPC MACC IPC MACC IPB MACB
Figura 2.38. Tablas Estáticas
Este mecanismo puede ser válido en redes muy pequeñas, con pocos equipos pero si
la red tiene muchos sistemas, la operación se hace muy tediosa. Además, al cambiar
un equipo, añadir uno nuevo, si se estropea alguno, etc., se deben actualizar todas
las tablas de forma manual.
2.5.4.2. Asociación directa o Direct Mapping
En este caso, la dirección IP y la dirección de subred se eligen de tal manera que

una esté incluida en la otra. En caso de que la dirección IP contuviera a la dirección
de subred, sólo tendríamos que extraer la dirección física a partir de la dirección IP,
sin ninguna información externa a la estación o router.
Aunque de esta manera, la resolución de direcciones es sencilla y se pueden añadir
nuevas máquinas de forma que no se tengan que cambiar tabla alguna en cada má-
quina, existen varios problemas. Por ejemplo, con respecto al tamaño de las direc-
ciones, la dirección IP es de 32 bits mientras que la de subred puede ser mayor (co-
mo, por ejemplo, la dirección MAC que es de 48 bits). Además, no es
recomendable mezclar direcciones de varios niveles, pues si, por ejemplo, se cam-
73
73
Direccionamiento
La e interconexión
biara la dirección IP, habría que variar la dirección de subred y comunicarlo a todos
los equipos de la red.
Sin embargo, hay ciertos protocolos que sí la pueden usan. Además, en la nueva
versión de IP (la versión 6) ya es posible la utilización de la técnica de Direct Map-
ping, puesto que es más eficiente que la de técnica de Dynamic Binding que se ex-
plica a continuación.
2.5.4.3. Asociación dinámica o Dinamic Binding
En este caso, para evitar el mantenimiento de tablas de asignaciones, existen varios

algoritmos o protocolos de bajo nivel de resolución de direcciones que permiten
relacionar direcciones IP y de subred de forma dinámica.
a) Protocolo ARP (Address Resolution Protocol)

Está definido en la RFC 826 y sólo es de aplicación en redes que permiten envíos
broadcast. Fue diseñado para soportar todo tipo de protocolos y direcciones de red,
no solo IP, permitiendo obtener la dirección de subred (por ejemplo, la dirección
MAC) a partir de la dirección IP asociada. El método empleado está basado en un
modo solicitud/respuesta (con 2 tipos de mensajes).
Los mensajes ARP se encapsulan directamente en PDUs de la subred (por ejemplo,
en tramas, en redes Ethernet como en la figura siguiente). No se encapsulan en da-
tagramas IP.
Cabecera
Mensaje ARP
ARP
Cabecera Cola
D t Trama
Datos T
Trama
Figura 2.39. Encapsulamiento ARP sobre tramas Ethernet
74
74
CapítuloLa
TCP/IP
El funcionamiento de ARP se explicará mediante el ejemplo de la siguiente figura:
A B C D
IPA IPB IPC IPD
MACA MACB MACC MACD
Figura 2.40. Red Ethernet de ejemplo
Supongamos que el equipo A quiere comunicarse mediante IP con el equipo C. Al

estar ambos conectados a una misma red Ethernet, la comunicación será encapsu-
lando los datagramas en tramas Ethernet, enviadas desde la dirección origen MACA
a la dirección destino MACC. Sin embargo, el equipo A, aunque conoce la IP de C
(IPC), en un principio desconoce su dirección MAC (MACC).
El proceso seguido es el siguiente, de forma resumida:
1. El equipo A envía en modo broadcast una solicitud ARP (ARP Request) en
la que incluye los siguientes datos: MACA, IPA e IPC.
A B C D
IPA IPB IPC IPD
MACA MACB MACC MACD
Busco la MAC del

equipo con la IP
IPC
Figura 2.41. Solicitud ARP (broadcast)
2. El equipo C, al recibir la solicitud, contestará al equipo A con un mensaje
unicast (ARP Reply), dirigido exclusivamente al equipo A.
A B C D
IPA IPB IPC IPD
MACA MACB MACC MACD
Soy yo y mi MAC
es la dir
dir. MACC
Figura 2.42. Respuesta ARP (unicast)
75
75
Direccionamiento
La e interconexión
El formato de los dos mensajes ARP se muestra en la figura 2.43.

32 bits
Tipo de hardware (1=Ethernet)

(1 Ethernet) Tipo de protocolo (800
(800=IP)
IP)
Lon. Dir. Hard. (6) Lon. Dir. Red (4) Operación (1-Request o 2-Replay)
Dir MAC Emisor (octetos 00-3)

Dir. 3)
Dir. MAC Emisor ((oct 4-5)) Dir. IP emisor ((octetos 0-1))
Dir.
i IP emisor
i ((octetos 2-3)
2 3) Dir.
i MAC
AC ddestino
i ((oct. 00-1)
1)
Dir MAC destino (octetos 2-5)

Dir. 2 5)
Dir. IP destino
Figura 2.43. Formato de los mensajes ARP

Veamos el proceso seguido en el ejemplo anterior, de forma más detallada:
1. El equipo A conoce las direcciones IPA, IPC y la dirección MACA, y necesi-

ta MACC para poder enviarle los datagramas encapsulados en tramas Et-
hernet dirigidas a dicha dirección MACC.
2. Para obtener la dirección MACC, envía un mensaje ARP Request encapsu-
lado en una trama Ethernet enviada de forma broadcast (dirección MAC de
destino todo unos: FF:FF:FF:FF:FF:FF).
A B C D
IPA IPB IPC IPD
MACA MACB MACC MACD

Busco la MAC del
equipo con la IP
IPC
Dest Orig Tipo TIPO MAC Fte MAC Dest IP Fte IP Dest
1111 1
1111…1 … 1 IPA IPC
Cola
MACA 806 (REQUEST) MACA 00000…0
(FFFF…..F)
Mensaje ARP
Figura 2.44. Solicitud ARP Request encapsulada en trama Ethernet broadcast
3. La solicitud llega a todos los equipos de la red. Sin embargo sólo responde
el que reconoce su dirección IP en el campo IP destino de la solicitud ARP.
El resto de equipos de la red registrarán la correspondencia IPA-MACA en
su tabla ARP.
76
76
CapítuloLa
TCP/IP
4. El equipo C genera el mensaje ARP Reply que enviará directamente al

equipo A, encapsulado en una trama unicast dirigida al equipo A (Figura 2.45).
Soy yo y mi MAC
es la dir. MACC
A B C D
IPA IPB IPC IPD
MAC
ACA MACB MACC MACD
Dest Origg Tipo TIPO MAC Fte MAC Dest IP Fte IP Dest
… 2 IPC IPA
C l
Cola
MACA MACC 806 (REPLAY) MACC MACA
Mensaje
j ARP
Figura 2.45. Respuesta ARP Reply encapsulada en trama Ethernet unicast
Por último, el equipo A guarda la dirección MACC en su tabla ARP y ya estará en

disposición de enviar datagramas IP al equipo C, encapsulados en tramas dirigidas a
la dirección de C (MACC), tal como se muestra en la figura 2.46.
A B C D
IPA IPB IPC IPD
MACA MACB MACC MACD
Dest g
Orig p
Tipo Dest Origg
… D t
Datos C l
Cola
MACC MACA 800 IPC IPA
Capa IP: Datagrama IP
Figura 2.46. Envío de datagramas al equipo C encapsulados en tramas Ethernet unicast
Cabe destacar que las tablas ARP no se mantienen en la memoria de los equipos de
forma indefinida ya que si, por ejemplo, el equipo C se estropease, el equipo A
seguiría enviándole datagramas sin saber que C ya no funciona. Lo que se hace es
borrar la entrada de forma periódica.
77
77
Direccionamiento
La e interconexión
Ejecutando el comando 'arp -a' desde la consola de comandos de un equipo con

sistema operativo Microsoft Windows se pueden obtener las tablas de un equipo IP,
tal y como se aprecia en la figura 2.47. Si una vez obtenida la tabla se ejecuta un
ping a una dirección IP de un equipo de la propia red que no esté en la tabla, apare-
cerá inmediatamente la nueva entrada correspondiente a dicha dirección IP.
Figura 2.47. Tabla ARP

Como se puede apreciar, este método mantiene independientes las direcciones IP
(lógicas) de las direcciones de subred (físicas) y se utiliza en multitud de redes que
admiten broadcast, como la mayoría de tecnologías de red local. De esta forma, se
pueden asignar direcciones arbitrarias a cada equipo de la red sin preocuparse de las
asignaciones con las direcciones físicas de los mismos.
Como el tráfico broadcast es indeseado en una red, para evitarlo se podría imple-
mentar que cuando un equipo IP arrancara la sesión de red, enviara un mensaje a los
demás con su correspondencia dirección física-dirección IP.
b) Protocolo RARP (Reverse Address Resolution Protocol)
El protocolo RARP está definido en la RFC 903 y es una adaptación del anterior. Se
usa para esquemas como el de la figura, con PCs sin disco cuyos ficheros de trabajo
y la propia configuración de los equipos reside en un servidor disponible en la red.
Estos equipos necesitan de algún mecanismo inicial que ejecutarán al arrancar para
obtener la configuración IP para así poderse conectar al servidor y bajarse la imagen
78
78
CapítuloLa
TCP/IP
de arranque (boot image) y así poder comunicarse a partir de ese momento utilizan-
do TCP/IP.
PC sin Disco
A B C SERVIDOR
IPD
MACA MACB MACC MACD
Figura 2.48. Escenario RARP
El formato de los mensajes es el mismo que en ARP.

Supongamos que arranca en este momento el PC A. Deberá poder obtener el soft-
ware o imagen de trabajo desde el servidor. Para ello necesita una configuración IP
que obtendrá del servidor mediante RARP. El PC A conoce su dirección Ethernet
que tendrá almacenado en ROM, pero no su dirección IP, que nunca se almacena en
ROM. Lo primero que hará será construir un mensaje RARP Request y lo enviará
encapsulado en una trama broadcast a todos los equipos de la red. A este mensaje
contestarán sólo los servidores RARP que exista en la subred (que puede haber
varios pero sólo uno de ellos configurado como servidor primario RARP) mediante
respuestas RARP unicast dirigidas al PC A.
RARP sólo se utiliza en redes de área local, donde la probabilidad de fallo en la red
es baja.
En cuanto a ventajas de RARP podemos citar las siguientes:
- Es posible variar la configuración de una manera muy versátil.
- Se puede evitar, o controlar mejor, problemas de virus.
- Los equipos pueden autoconfigurarse.
- Permite una mejor y más controlada administración del sistema.
c) Otros protocolos
Otros protocolos de asignación de direcciones IP utilizados en redes locales son

BOOTP (Bootstrap Protocol) y DHCP (Dynamic Host Configuration Protocol).
79
79
Direccionamiento
La e interconexión
Ambos se explican en el siguiente capítulo. Para conexiones remotas a redes WAN

existen otros protocolos como PPP (Point to Point Protocol) o SLIP (Serial Line
IP) que permiten tratar el caso de un enlace punto a punto mediante una línea serie.
Ambos son muy utilizados por usuarios de PCs domésticos con acceso remoto a una
red de datos mediante módem y con un acceso a una Red Telefónica Conmutada
(RTC), como la RTB o la RDSI-BE.
2.6. Subdivisión de redes IP en Subredes o Subnetting
Cuando una organización solicita un rango de direcciones IP, normalmente se le

asignaba un grupo de direcciones de una determinada clase dependiendo del tamaño
de la organización (número de máquinas a conectar a Internet). Por tanto, de las
direcciones IP, los bits correspondientes al NetId son fijos e intocables. Sin embar-
go los administradores de la red pueden ‘jugar’ con los bits del HostId para subdi-
vidir la red en subredes. A este proceso se le denomina subnetting.
A continuación se explica en qué consiste el subnetting con un ejemplo. Supóngase
la red de la figura 2.49, de una empresa formada por varios segmentos Ethernet
unidos por routers. A dicha empresa se le ha asignado una clase B (158.42.0.0) que
da para 65536 direcciones, pues una clase C sólo da para 254 máquinas que no son
muchas.
RED 158
158.42.0.0
42 0 0 SUBRED 2
Router
INTERNET
Router SUBRED 3
SUBRED 1
Router
Router
SUBRED 4
Router
Router
SUBRED 5
SUBRED 6
Figura 2.49. Red IP de ejemplo
80
80
CapítuloLa
TCP/IP
El administrador desea dividir, a nivel interno, la red de la empresa en varias subre-

des como, por ejemplo, una por departamento, edificio…, separadas por routers IP,
tal como se aprecia en la figura. A nivel externo la red será vista como un todo, es
decir, como la red de clase B. Para conseguir la subdivisión interna, ya que el NetId
de las direcciones no se puede tocar (16 bits equivalentes a ‘158.42’, en notación
dotted decimal), podrá tomar los primeros bits del HostId como identificativo de
subred.
NetId SubNetId HostId

Figura 2.50. Dirección IP utilizando subnetting
En cada subred hay siempre dos direcciones reservadas: la primera y la última. Si la

parte HostId es todo ceros (primera dirección), la dirección es la de la propia su-
bred; mientras que la dirección con el HostId todo unos (última dirección) está re-
servada para broadcast en cada subred.
La forma más sencilla de entender el proceso de subdividir una red de clase B con-
siste en asignar un conjunto de direcciones similar a una clase C a cada subred (es
decir dividir una clase B en muchas, hasta 256, subredes cada una equivalente a una
clase C dentro de la clase B original), tal y como se muestra en la figura:
SUBRED 2
Tráfico hacia la red
158.42.2.0
clase B: 158
158.42.0.0
42 0 0
.2.1 .2.2
Router
INTERNET .1.2
12
Router .1.1 SUBRED 3
158 42 3 0
158.42.3.0
SUBRED 1
158.42.1.0 .3.4
.1.4 .1.3 Router

.3.1
.4.3
43
.4.1
Router
.4.4 .4.2 .5.2

SUBRED 4
158 42 4 0
158.42.4.0 Router
Router .5.1
.6.1
61
SUBRED 5
158 42 5 0
158.42.5.0
SUBRED 6
158 42 6 0
158.42.6.0 .5.3
.6.2
Figura 2.51. Subnetting utilizando subredes de clase C dentro de una clase B
81
81
Direccionamiento
La e interconexión
En los 16 bits del HostId, la frontera entre lo que es subred y sistema la fija el ad-
ministrador de la red. En este caso lo ha dividido en 8 bits (SubnetId) y 8 bits (Hos-
tId), pudiendo conseguir tener 256 subredes equivalentes a una clase C cada una,
con hasta 254 sistemas cada una (se eliminan las direcciones todo ‘0’ y todo ‘1’ del
HostId, que están reservadas).
A nivel interno la red está subdividida en subredes. Sin embargo, desde Internet
siguen viendo a la red de la empresa como la red de clase B 158.42.0.0 y, por tanto,
cualquier datagrama enviado desde el exterior a una dirección de dicha red de clase
B será encaminado hacia el router de entrada a la red (el de conexión a Internet).
Ahora falta establecer algún mecanismo para indicar a los equipos de la propia red
que se está utilizando subnetting y que, a nivel interno, ya no se tienen en cuenta las
clases. Para ello se utilizan las denominadas mascaras de subred (subnet masks).
La máscara de subred es una palabra binaria de 32 bits formada por unos a la iz-
quierda y ceros a la derecha (sin unos y ceros intercalados). Los bits a ‘1’ indican
los bits de la dirección que se incluyen en el NetId más el SubnetId. Indica cuántos
bits de las direcciones IP procesadas en el proceso de encaminamiento son signifi-
cativos o no (1: significativo; 0: no significativo) a la hora de encaminar.
En el caso del ejemplo, el NetId es de 16 bits, mientras que el SubnetId elegido es
de 8 bits, por tanto, la máscara de subred tendrá los primeros 24 bits (16+8) todos a
‘1’, mientras que el resto estarán todo a ‘0’, quedando una máscara, en notación
dotted decimal, de 255.255.255.0.
Cuando se utiliza subnetting la tabla de encaminamiento también deberá indicar
para cada ruta la máscara de red. Además de las columnas ya vistas, la tabla de
encaminamiento también incluye una columna indicando el coste de cada ruta. Por
tanto, para cada subred de destino, debe contener la máscara de subred, la dirección
IP del siguiente nodo al que reenviarle el datagrama y el coste, tal y como se detalla
a continuación.
Tabla 2.2. Tabla de encaminamiento con máscara de subred y coste de cada ruta
Dir IP Destino Máscara de Subred Dir IP del Siguiente Nodo Coste
Para la ruta por defecto tanto la dirección IP de destino como la máscara son 0.0.0.0
Cuando un router recibe un datagrama, mirará la dirección IP de destino y buscará,
en las filas de la tabla, la subred a la que pertenece dicha dirección, utilizando para
ello la máscara de subred. Imaginemos una tabla de encaminamiento como la si-
guiente.
82
82
CapítuloLa
TCP/IP
Tabla 2.3. Tabla de encaminamiento de ejemplo

Dir IP Destino Máscara de Subred Dir IP del Siguiente Nodo Coste
172.30.1.0 255.255.255.0 172.30.10.1 1
172.30.2.0 255.255.255.0 172.30.10.2 1
172.30.3.0 255.255.255.0 172.30.10.3 1
0.0.0.0 0.0.0.0 172.30.10.4 1
Imagínese que el router propietario de la tabla recibe un datagrama dirigido a la

dirección destino 172.30.3.5. El router obtendrá el prefijo de red (NetId+SubnetId)
de dicha dirección de destino, mediante una operación AND (bit a bit) con la másca-
ra de subred de cada fila y comparará con la dirección de la subred de destino de
dicha fila. Si coincide en una fila, se enviará al siguiente nodo indicado en la fila de
la tabla. En el ejemplo, al realizar la operación se obtiene el prefijo 172.30.3.0 (fi-
gura 2.52), por lo que, al coincidir con la entrada de la dirección de destino de la
tercera fila de la tabla, el siguiente nodo al que se le reenviará el datagrama será el
que tiene la dirección 172.30.10.3.
Figura 2.52. Operación AND para la dirección de destino 172.30.3.5
Supongamos ahora que el mismo router recibe un datagrama dirigido a la dirección

172.30.4.23. Al realizar la operación con la máscara 255.255.255.0 el resultado
devuelto es 172.30.4.0 (figura 2.53), que no coincide con ninguna de las tres prime-
ras entradas de la tabla. Por tanto, a continuación se realizará la operación AND (bit
a bit) con la máscara de la ruta por defecto (0.0.0.0) cuyo resultado seguro que
coincide con 0.0.0.0, que, curiosamente, es la dirección de destino de la ruta por
defecto. Se escogerá, por tanto, la ruta por defecto y se enviará al nodo 172.30.10.4.
Figura 2.53. Operación AND para la dirección de destino 172.30.4.11
83
83
Direccionamiento
La e interconexión
Veamos, a continuación, un ejemplo un poco más complejo de subnetting. Supon-

gamos que el administrador de la red del ejemplo anterior (red 158.42.0.0), para no
desperdiciar direcciones (ya que en la red de la empresa hay pocas subredes) quiere
optimizar al máximo los bits asignados al SubnetId, para maximizar el número po-
sible de equipos a conectar a cada subred.
En el caso de la red de la empresa, existen 6 subredes, por lo que son necesarios
sólo 3 bits para direccionarlas (en realidad se desperdiciarían dos subredes ya que
con 3 bits se pueden conseguir 8 combinaciones de SubnetId). Por tanto, la máscara
de subred ahora tendría 19 bits a ‘1’ (16 + 3) y el resto a ‘0’, quedando la siguiente
máscara: 255.255.224.0 (figura 2.54).
255 255 224 0

11111111 11111111 11100000 00000000
Subred Equipo (13 bits)

(hasta 8190 equipos, 213-2)
(19 bits)
S b Id (3 bi
SubnetId bits))
(hasta 8 subredes,
subredes 23)
Figura 2.54. Máscara de Subred
En la tabla 2.4 se muestran las direcciones de las subredes que se conseguirían al

realizar el subnetting con dicha máscara.
Tabla 2.4. Tabla con las subredes obtenidas mediante subnetting
Dirección de Dirección de
Número Dirección del Dirección del
subred broadcast
de subred primer equipo8 último equipo9
(HostId todo ‘0’) (HostId todo ‘1’)
0 158.42.0.0 158.42.0.1 158.42.31.254 158.42.31.255
1 158.42.32.0 158.42.32.0 158.42.63.254 158.42.63.255
2 158.42.64.0 158.42.64.0 158.42.95.254 158.42.95.255
3 158.42.96.0 158.42.96.0 158.42.127.254 158.42.127.255
4 158.42.128.0 158.42.128.0 158.42.159.254 158.42.159.255
5 158.42.160.0 158.42.160.0 158.42.223.254 158.42.223.255
6 158.42.192.0 158.42.192.0 158.42.192.254 158.42.192.255
7 158.42.224.0 158.42.224.0 158.42.224.0 158.42.224.0
8
Sería la primera dirección válida que se podría asignar a un equipo de la subred
9
Sería la última dirección válida que se podría asignar a un equipo de la subred
84
84
CapítuloLa
TCP/IP
2.6.1. Subnetting de máscara variable (VLSM)
Al subnetting realizado en el ejemplo anterior, con la misma máscara de subred en

todas las subredes y, por tanto, en el que todas las subredes en que se dividía la
subred eran del mismo tamaño (mismo número máximo de equipos posibles a con-
figurar en cada red) se denomina subnetting de máscara fija.
Sin embargo, en una red de una organización no todas las redes son del mismo ta-
maño ni requieren del mismo número de posibles equipos a conectar a las mismas.
Es por ello que se permite el subnetting en base a las necesidades de cada subred
(per-network basis). Para ello se suele utilizar diferentes máscaras de subred para
conseguir subredes de diferentes tamaños. A esta técnica se la denomina subnetting
de máscara variable (Variable Length Subnetwork Mask o VLSM) y las estudiare-
mos con un ejemplo. Todos los routers conectados a diferentes subredes deben tener
conocimiento de las máscaras de red correspondientes a cada subred para tener
conocimiento de dicha subdivisión heterogénea.
Imaginemos una conexión punto a punto entre dos routers IP. Dicha conexión debe
realizarse mediante una subred IP en la que son necesarias, como mínimo, dos di-
recciones IP válidas para asignar a cada uno de los dos routers interconectados.
Como toda subred dispone de 2 direcciones reservadas (la primera, de subred; y la
última, de broadcast), se necesitará una subred de, al menos 4 direcciones (es decir
con los 2 últimos bits, de los 32 bits de la dirección IP, asignados al HostId). Ello se
consigue con una máscara de subred con 30 unos y 2 ceros, es decir,
255.255.255.252. El empleo de este tipo de subredes con máscaras de 30 bits a uno
es muy utilizado en conexiones punto a punto, que interconectan solamente dos
equipos IP.
Veamos un caso de subdivisión de una red en subredes de diferente tamaño, es
decir, con máscara variable. Para ello supongamos la subred de clase B 158.42.0.0 y
a modo de ejemplo, en la tabla 2.5, se muestra una posible división en subredes de
diferentes tamaños. Obsérvese que el total de direcciones se corresponde con 65536
direcciones de una clase B, pero que, al dividirla en subredes, se pierden muchas (2
por subred).
En la figura 2.55 se muestra una interconexión de oficinas mediante subredes, utili-
zándose máscara variable, así como las tablas de encaminamiento de cada uno de
los tres routers que aparecen en la misma. Nótese las subredes de 4 direcciones
utilizadas para las conexiones punto a punto entre los routers, con máscaras de 30
bits a ‘1’ (255.255.255.252).
85
85
Direccionamiento
La e interconexión
Tabla 2.5. Subnetting de máscara variable
Número de subredes
Dirección de Subred Máscara a emplear Subred/bits máscara
y direcciones
158.42.0.0 255.255.255.0 158.42.0.0/24
16 subredes de 256 158.42.1.0 255.255.255.0 158.42.1.0/24

direcciones cada una … … …
158.42.15.0 255.255.255.0 158.42.15.0/24
158.42.16.0 255.255.252.0 158.42.16.0/22
16 subredes de 1024 158.42.20.0 255.255.252.0 158.42.20.0/22

direcciones cada una … …
158.42.76.0 255.255.252.0 158.42.76.0/22
158.42.80.0 255.255.240.0 158.42.80/20

3 subredes de 4096
158.42.96.0 255.255.240.0 158.42.96/20
direcciones cada una
158.42.112.0 255.255.240.0 158.42.112/20
1 subred de 32768
158.42.128.0 255.255.128.0 158.42.128/17
direcciones
2.7. Conceptos de Superredes. Supernetting y CIDR
La técnica de subnetting fue inventada a principios de los años 80 para conservar al

máximo el espacio de direccionamiento disponible. Por 1993, con la apertura de
Internet a las empresas, pronto se vio que el ritmo de crecimiento del número de
equipos conectados a Internet era demasiado alto para ser soportado con el sistema
de direccionamiento elegido, incluso utilizando subnetting. Por aquellas fechas ya
se estaba trabajando en una nueva versión de IP con direcciones de más bits, pero
mientras dicha versión no fuese operativa se tenía que buscar una solución alterna-
tiva temporal para poder continuar. Dicha técnica se denominó supernetting, que
sería la interpretación opuesta del concepto de subnetting, pero al resto de Internet.
Por un lado, subnetting permite el uso de una dirección de red IP para múltiples
redes físicas dentro de una misma organización. Por otro lado, supernetting permite
el uso de muchos grupos de direcciones IP para una organización individual.
86
86
CapítuloLa
TCP/IP
Oficina Principal
Subred
158.42.128.0/17
158 42 128 5/17

158.42.128.5/17 158.42.128.12/17
158 42 128 12/17 158.42.128.17/17
158 42 128 17/17
Rtr 158.42.128.1 Rtr 158.42.128.1 Rtr 158.42.128.1
Destino Máscara Dir Sig.
158.42.1.0 255.255.255.0 192.168.0.1
0.0.0.0 0.0.0.0 192.168.1.1
158.42.128.1/17
Destino
i Máscara
á Dir Sig. 192.168.0.2/30 192.168.1.2/30
Internet
0.0.0.0 0.0.0.0 Router 192.168.1.1/30
192.168.0.2 Router
192.168.0.1/30
Router Destino Máscara Dir Sig.
Sig
158.42.1.1/24
255 255 0 0 192.168.1.2
158 42 0 0 255.255.0.0
158.42.0.0 192 168 1 2
… … …
158.42.1.7/24 158.42.1.5/24 158.42.1.12/24

Rtr 158.42.1.1 Rtr 158.42.1.1 Rtr: 158.42.1.1
Oficina Sucursal
remota
Subred 158.42.1.0/24
Figura 2.55. Interred con máscara de subred variable
Para realizar subnetting se toman bits del HostId para identificar la subred. Para
realizar supernetting se toman bits del NetId para identificar el grupo de redes que
forman el bloque de direcciones que forma la superred, tal y como se puede apreciar
en la figura 2.56.
N Id
NetId H Id
HostId
Superredes
d Subredes
b d
Figura 2.56 Subnetting vs Supernetting
Para entender el funcionamiento de supernetting, considérese una organización de

un tamaño medio requiere conexión a Internet. Por su tamaño, según el modelo
tradicional de clases, la empresa solicitaría una clase B ya que una clase C sólo
permite direccionar a 254 equipos y la empresa tiene o espera tener más de esa
87
87
Direccionamiento
La e interconexión
cantidad de equipos, aunque muchos menos de los 65534 equipos que permitiría
direccionar una clase B. Para ahorrar direcciones de clase B, y siguiendo el esque-
ma de supernetting, se le asignaría a la empresa varios bloques de direcciones de
clase C, de tal manera que disponga de suficientes direcciones para todas las redes
que la empresa quiera conectar a Internet. Por ejemplo, supongamos que la empresa
en cuestión solicita una clase B que quiere subdividir (con subnetting) utilizando el
tercer byte para el SubnetId (máscara 255.255.255.0). En vez de esto, se le podrían
asignarían tantas direcciones de clase C válidas como subredes desee conectar a
Internet.
Por ejemplo, a una empresa que solicite 1000 direcciones IP se le podría asignar los
4 bloques de direcciones de clase C, como, por ejemplo, los siguientes:
225.100.32.0, 225.100.33.0, 225.100.34.0 y 225.100.35.0. A otra empresa que soli-
cite otras 1000 direcciones se le podría signar otros 4 bloques 225.100.36.0,
225.100.37.0, 225.100.38.0 y 225.100.39.0. En ambos casos, las subredes serían
referenciadas con la 225.100.32.0 con la máscara 255.255.252.0 y la 225.100.36.0
con la máscara 255.255.252.0, respectivamente.
Aunque supernetting es fácil de entender cuando se mira desde el punto de vista de
una única organización, el propósito del supernetting es mucho más amplio. La idea
final es la de una visión jerárquica de Internet en la cual los Proveedores del Servi-
cio de Red (NSP o Network Service Providers) proporcionen la conectividad a In-
ternet. Una organización que desee conectar sus redes a Internet debería contratar la
conexión a un NSP. El NSP sería el responsable de coordinar el direccionamiento
IP así como el conexionado físico. Los diseñadores de supernetting propusieron que
se permitiera a los NSP obtener una gran parte del espacio de direccionamiento (es
decir, un conjunto de direcciones que englobaba varias clases C). De esta manera
cada NSP podía asignar una o varias clases C a sus clientes.
Sin embargo, asignar varias clases a un mismo cliente complicaría mucho el tema
del encaminamiento, ya que aumentaría el tamaño de las tablas de encaminamiento
y la cantidad de información que se intercambiarían los routers.
La técnica de supernetting no suele estar disponible en el software de los hosts y,
por tanto, debe ser utilizada con precaución. Sin embargo, dicha técnica sienta las
bases de la técnica denominada CIDR (Classless Inter-Domain Routing) que re-
suelve el problema planteado en el párrafo anterior. Supóngase que unos pocos NSP
forman el núcleo de Internet y que cada uno es propietario de un gran bloque de
direcciones IP contiguas. En este caso el beneficio del supernetting es muy claro.
Fijémonos en un NSP A y observemos las entradas en la tabla de encaminamiento
de sus routers. Es lógico pensar que la tabla tendrá una entrada para cada una de las
redes de sus clientes pero no necesita entradas para las redes de los clientes de otros
NSPs. Con sólo una entrada para direccionar a los destinos de cada uno de los otros
88
88
CapítuloLa
TCP/IP
NSPs, es decir, una entrada por NSP que identifique el bloque de direcciones pro-
piedad de dicho NSP, sería suficiente.
La técnica CIDR también utiliza una máscara de bits denominada Máscara CIDR,
de tal manera que indica los bits comunes de las todas las direcciones IP propiedad
de un mismo NSP.
Los routers y equipos que utilicen CIDR necesitan tener instalada una versión de
software que soporte CIDR y entienda los rangos de direcciones que se manejan de
esta manera.
Por ejemplo, considérese una organización a la que se le asignaron 409610 direccio-
nes consecutivas, empezando en la dirección 245.85.80.0. La siguiente tabla mues-
tra los valores binarios del rango de direcciones.
Tabla 2.6. Bloque de 4096 direcciones IP

Dotted Decimal Binario
Dirección Más baja 245.85.80.0 11110101 01010101 01010000 00000000
Dirección más alta 245.85.95.255 11110101 01010101 01011111 11111111
CIDR requiere dos valores para especificar un rango de direcciones: la dirección

más baja y la máscara de 32 bits. La máscara delimita el final del prefijo común. En
este caso serían los primeros 20 bits: 11111111 11111111 11110000 00000000 (es
decir, 255.255.240.0). En este caso tendríamos el par <245.85.80.0 255.255.240.0>,
o también la superred 245.85.80.0/20, y englobaría todas las direcciones IP cuyos
20 primeros bits serían ‘11110101 01010101 0101’. En total el conjunto de 4096 di-
recciones delimitadas por las dos que aparecen en la tabla.
Lo mismo se puede realizar para bloques mayores. Por ejemplo, el par <194.0.0.0
254.0.0.0>, o también la superred 194.0.0.0/7 hace referencia al rango de direccio-
nes IP cuyo prefijo es ‘1100001’, que estaría formado por 225 direcciones, es decir
por 33.554.432 direcciones
A nivel mundial, se ha utilizado el supernetting de esta forma para hacer un reparto
por continentes y países, tal como se muestra a continuación:
10
4096=16 x 256
89
89
Direccionamiento
La e interconexión
- Multi regional: 192.0.0.0 - 193.255.255.255 (192.0.0.0/7)

- Europa: 194.0.0.0 - 195.255.255.255 (194.0.0.0/7)
- Otros: 196.0.0.0 - 197.255.255.255 (196.0.0.0/7)
- Norteamérica: 198.0.0.0 - 199.255.255.255 (198.0.0.0/7)
- Centro y Sudamérica: 200.0.0.0 - 201.255.255.255 (200.0.0.0 /7)
- Anillo Pacífico: 202.0.0.0 - 203.255.255.255 (202.0.0.0 /7)
- Otros: 204.0.0.0 - 205.255.255.255 (204.0.0.0 /7)
- Otros: 206.0.0.0 - 207.255.255.255 (206.0.0.0 /7)
De esta forma, se ha podido ir agrupando entradas en las tablas de encaminamiento

de los routers principales en las rutas intercontinentales, minimizando al máximo su
tamaño.
90
90
Asignación de Direcciones IP
Capítulo 3. Asignación de Direcciones IP

3.1. Introducción
Tal y como se ha visto en el capítulo anterior, cada dispositivo conectado a una

subred IP necesitará tener una configuración IP para dicha subred, asociada al inter-
face de conexión a la misma (por ejemplo, a la tarjeta Ethernet, en el caso de estar
conectado a una LAN basada en la tecnología Ethernet), antes de poder enviar y
recibir datagramas IP. Dicha configuración IP deberá incluir, al menos, la siguiente
información:
- Dirección IP.
- Máscara de subred.
- Dirección IP de un router por defecto o Default Gateway (si se trata de un
ordenador conectado a una LAN con router de salida de la subred).
- Dirección IP de un servidor DNS.
Existen dos posibilidades a la hora de asignar direcciones a los equipos conectados

a una subred:
a) Configuración manual. Cuando la red no es muy dinámica o cambiante, es

decir, no se le conectan y desconectan equipos de forma habitual, se pueden
asignar direcciones IP de forma manual o estática bien a todos los equipos o, al
menos, a determinados equipos de la red. Normalmente ,se asigna direcciones
de esta forma a aquellos equipos que permanecen en un mismo lugar (lógica y
físicamente) o bien a determinados equipos perfectamente identificados dentro
de la red (como, por ejemplo, determinados servidores o equipos de intercone-
xión). Esta información se almacenará en un fichero de configuración accesible
en el momento de iniciar el dispositivo IP.
b) Configuración dinámica. Se suele utilizar este tipo de configuración en disposi-

tivos sin disco (disk-less) o en dispositivos en redes cambiantes, donde se aña-
den, mueven o cambian (física y lógicamente) los equipos de la red. En este ca-
so una configuración manual no es viable y se utilizan mecanismos de
asignación dinámica. Este tipo de configuración no es adecuado para configurar
routers, conmutadores o switches, servidores… importantes en la red, ya que,
como ya se ha indicado, lo habitual es que dichos dispositivos tengan configu-
91
91
Direccionamiento
Asignación e interconexión
de Direcciones IP de redes basada en TCP/IP
raciones IP estáticas facilitando, de esta forma, su uso, gestión y mantenimien-

to.
A medida que crecen las redes y se convierten en entes dinámicos, es importante

poder liberar a los administradores de red, en la medida de lo posible, del esfuerzo
en tiempo y dedicación que suponen las arduas labores de configuración de equipos.
Las demandas de conectividad, los cambios, movimientos temporales y reconfigu-
raciones de red frecuentes no pueden consumir altos porcentajes del tiempo de los
administradores cuyo coste económico es bastante alto. Estas situaciones han pro-
vocado la necesidad de servicios o protocolos que permitan automatizar dichas
tareas de configuración de los equipos e incluso de cierto software de configuración
automática a través de la red. Una forma muy sencilla de conseguir dicho cometido
es mediante el almacenamiento de los parámetros de configuración en bases de
datos, así como imágenes del software en un servidor. De esta forma, al iniciarse los
dispositivos conectados a la red pueden interactuar con dicho servidor, que les pro-
porcionará la configuración y/o el software adecuado.
En este capítulo se presentan los protocolos BOOTP (Bootstrap Protocol) y el pro-
tocolo DHCP (Dynamic Host Configuration Protocol), que funcionan en modo
cliente/servidor, y ofrecen mecanismos de asignación de direcciones y configura-
ción IP. Estos protocolos han venido a sustituir al protocolo RARP estudiado en el
capítulo anterior. Es por ello que RARP ya no está incluido en la versión 6 de IP
(IPv6).
Un servidor de asignación de configuración IP responderá a peticiones de clientes
de su propia red o, incluso, de otras redes IP, y permitirá controlar la asignación y
evitar la duplicación de direcciones IP. Habrá dispositivos que necesiten unos pocos
parámetros de configuración, mientras que otros dispositivos pueden necesitar una
lista más larga de parámetros a configurar. Existen equipos que necesitan un soft-
ware adicional (por ejemplo, la imagen del sistema operativo del propio equipo) y
que se les indique de dónde descargarlo (por ejemplo, de un servidor de transferen-
cia de ficheros o FTP) en el momento de inicialización del propio dispositivo.
3.2. El Protocolo BOOTP (Bootstrap Protocol)
El protocolo BOOTP, definido en la RFC 951, constituyó el primer estándar para el

arranque automático de dispositivos en un entorno TCP/IP, proporcionándoles los
parámetros básicos para su configuración. En los años 80 era habitual el uso de
máquinas sin disco duro (disk-less), y BOOTP era el protocolo utilizado para admi-
nistrarles la configuración IP básica, mediante UDP y utilizando los puertos 67 y
92
92
Capítulo 3. AsignacióndedeDirecciones
Asignación direcciones IP
68. También era utilizado para configurar máquinas que arrancaban por primera
vez.
El protocolo BOOTP sólo asignaba los 4 parámetros básicos comentados en la in-
troducción del capítulo:
- Dirección IP.
- Mascara de subred.
- Dirección IP de un router por defecto o Default Gateway.
- Dirección IP de servidor DNS.
Dichos parámetros se almacenaban para cada equipo de la red en una tabla que el
administrador debía configurar de forma manual en el propio servidor BOOTP.
Se trata de un protocolo que funciona en modo cliente/servidor. El cliente puede
iniciar el proceso sin ninguna información, o bien es posible que ya tenga algún
parámetro configurado anteriormente. Por ejemplo, podría tener ya una dirección IP
configurada y necesitar un archivo de arranque (o la imagen del sistema operativo).
Si suponemos que parte sin información alguna, el proceso seguido involucra los
siguientes pasos:
- El servidor BOOTP está a la escucha del puerto UDP 67, esperando a que
le llegue alguna solicitud de un cliente.
- El cliente, que puede determinar su propia dirección física (normalmente
almacenada en una memoria ROM en su propio hardware de red), envía di-
cha dirección física en un mensaje BOOTP Request, encapsulado en un
mensaje UDP, a su vez encapsulado en un datagrama IP dirigido al servi-
dor, utilizando el puerto UDP 68 de origen y el puerto UDP 67 de destino.
Si no conoce ni su dirección ni la del servidor (el cliente podría estar par-
cialmente configurado), en la cabecera del datagrama utiliza como direc-
ción origen todo ceros (0.0.0.0) y como dirección destino todo unos (la di-
rección broadcast 255.255.255.255). En caso de que el cliente conociera el
nombre o la dirección IP del servidor, podría incluirlo en la solicitud para
que sólo le respondiera dicho servidor.
- El servidor recibe el mensaje de solicitud y busca la dirección física del
cliente en su fichero de configuración, que contendrá la información sobre
la configuración IP a asignar al cliente con dicha dirección física (asigna-
ción estática). El servidor rellena los datos en una respuesta (BOOTP Re-
ply), encapsulada en un mensaje UDP, a su vez encapsulado en un data-
grama IP enviado por broadcast, usando el puerto UDP 67 de origen y
93
93
Direccionamiento
enviado al puerto UDP 68 de destino. Dicha respuesta puede, opcionalmen-

te, contener, además de la configuración IP, información adicional sobre la
ubicación de descarga de información o software de configuración, como,
por ejemplo, la dirección de un servidor TFTP (Trivial File Transfer Pro-
tocol) de descarga de ficheros y la ubicación dentro del servidor y el nom-
bre del fichero o software de configuración que el cliente debe descargarse
vía TFTP del mismo.
- Cuando recibe la respuesta, en caso de que proceda, el cliente BOOTP po-
drá utilizar un cliente TFTP adicional para descargarse (del servidor TFTP
indicado en la respuesta recibida) un fichero o el software de configuración
IP asignado, que almacenará en su memoria local y posteriormente ejecuta-
rá.
Por tanto, las peticiones de los clientes van desde el puerto UDP 68 de los
clientes al puerto UDP 67 del servidor, mientras que las respuestas del servidor van
del puerto UDP 67 del servidor al puerto UDP 68 de los clientes.
Ya que BOTTP ha sido sustituido por DHCP, no se va a profundizar más en es-

te protocolo, sino en DHCP.
3.3. El Protocolo DHCP (Dynamic Host Configuration Protocol)
El protocolo DHCP, descrito en la RFC 2131 (la versión 6 en la RFC 3315), susti-
tuye al protocolo BOOTP descrito en el apartado anterior, presentando una alterna-
tiva mucho más completa y avanzada, facilitando mucho más el crecimiento y la
administración de las redes IP. DHCP está basado en BOOTP, pero añade la capa-
cidad de asignación automática de direcciones de red reutilizables y opciones adi-
cionales de configuración. Los participantes DHCP pueden interoperar con partici-
pantes BOOTP. Un cliente BOOTP puede utilizar los servidores DHCP así como un
cliente DHCP puede utilizar el servicio de envío BOOTP. Es por ello que se dice
que DHCP es compatible hacia atrás (backward compatible) con respecto a
BOOTP.
También funciona en modo Cliente/Servidor. El servidor DHCP permite que clien-
tes DHCP de una red IP obtengan sus configuraciones IP. Hoy en día prácticamente
la totalidad de sistemas operativos incluyen un cliente DHCP de forma nativa.
94
94
3.3.1. Diferencias DHCP y BOOTP
DHCP presenta varias mejoras respecto a BOOTP:

- Administración más sencilla.
- Configuración automatizada.
- Admite cambios y traslados de equipos.
- El cliente puede solicitar valores específicos de ciertos parámetros.
- Define nuevos mensajes que permiten una interacción entre el cliente y el
servidor mucho más robusta que BOOTP.
El protocolo BOOTP verificaba la existencia de la dirección física (dirección MAC

en redes Ethernet) que solicita la información IP y, si existía en una tabla predefini-
da, se suministraba esta información IP. La correspondencia entre direcciones físi-
cas (como, por ejemplo, direcciones MAC) e IP se tenía que haber configurado
previamente en el servidor BOOTP. En DHCP no se realiza dicha verificación.
La asignación que realiza BOOTP es estática, realiza un mapeo estático del direc-
cionamiento. BOOTP fue diseñado para ambientes relativamente estáticos en el que
cada dispositivo IP tuviera una conexión de red permanente y el administrador tu-
viera suficientes direcciones IP para todos los dispositivos.
Con la aparición de redes inalámbricas y dispositivos móviles, el paradigma de
conexionado permanente ha cambiado drásticamente y, en la mayoría de casos, el
número de direcciones IP disponibles no es suficiente para todos los dispositivos en
caso de que todos se conectaran simultáneamente a la red. En este caso se necesita
otro mecanismo más flexible que BOOTP y que, además, permita la reutilización de
direcciones.
A diferencia de BOOTP, DHCP realiza un mapeo dinámico. Además, DHCP per-
mite el alquiler de información IP, mientras que BOOTP la asigna de forma perma-
nente. DHCP provee mecanismos adicionales para que el cliente obtenga otros
parámetros de configuración IP (más de 30) como, por ejemplo, la configuración de
servidores WINS (Windows Internet Naming Service) y DNS, mientras que BOTTP
sólo envía información de los 4 parámetros básicos de configuración explicados en
el apartado anterior.
95
95
Direccionamiento
3.3.2. Descripción de DHCP
El servicio DHCP proporciona un proceso para que el servidor pueda asignar la

configuración IP a los clientes. Al igual que BOOTP, también utiliza UDP, en el
puerto 68, respondiendo a las peticiones del puerto 67. Los mensajes DHCP envia-
dos por un cliente a un servidor son enviados al ‘puerto DHCP de servidor’ (67),
mientras que los mensajes DHCP enviados de un servidor a un cliente son enviados
al ‘puerto DHCP de cliente’ (68).
El servidor DHCP puede proveer más de 30 opciones de configuración IP al dispo-
sitivo cliente. Dichas opciones están definidas en RFC 2132, algunas de las cuales
se presentan a continuación:
• Dirección IP.
• Máscara de Subred.
• Dirección del servidor DNS.
• Nombre DNS.
• Puerta de enlace de la dirección IP.
• Dirección de Publicación Masiva (broadcast address).
• Tiempo máximo de espera del ARP.
• MTU (Unidad de Transferencia Máxima) para la interface.
• Servidores NIS (Servicio de Información de Red).
• Dominios NIS.
• Servidores NTP (Protocolo de Tiempo de Red).
• Servidor SMTP.
• Servidor TFTP.
• Nombre del servidor WINS.
Para ello, el servidor deberá tener una base de datos (o varias) con la información
de configuraciones IP disponibles (libres) para poder asignarlas a los clientes según
las vayan solicitando. Cuando una configuración haya sido asignada a un cliente,
esta deberá marcarse de alguna forma para no asignarla a ningún otro cliente.
96
96
DHCP permite a los administradores de red la flexibilidad de asignar direcciones a

los dispositivos IP mediante los siguientes 3 mecanismos de asignación de configu-
ración IP:
- Asignación manual o estática: Es el mecanismo más rígido y poco flexible.

El administrador de la red puede establecer explícitamente en el servidor
DHCP una configuración IP específica a máquinas específicas (o a todas).
El servidor DHCP se la comunicará al cliente cada vez que éste se lo soli-
cite y siempre será la misma (asignación estática), es decir, la que esté con-
figurada manualmente para dicho cliente. Está técnica es útil para controlar
la asignación de dirección IP a cada cliente y para evitar, también, que se
conecten clientes no identificados, aunque es poco viable si la red es cam-
biante y dinámica.
- Asignación automática: El servidor DHCP asigna de manera automática
una configuración IP a una máquina cliente la primera vez que hace la soli-
citud al servidor DHCP, quedando asignada al cliente de forma permanente
hasta que el propio cliente la libera. Este tipo de asignaciones se suele utili-
zar cuando el número de clientes en la red no varía demasiado.
- Asignación dinámica: El servidor DHCP asigna, presta o alquila, una con-
figuración IP a los clientes por un período de tiempo limitado, que es con-
figurable. Este tipo de asignación es el único método que permite la reutili-
zación dinámica de las direcciones IP, facilitando la incorporación de
nuevos dispositivos clientes a la red. De esta forma, el servicio DHCP
permite administrar las configuraciones IP de los dispositivos conectados a
la red por medio del alquiler de dicha información IP por un período defi-
nido administrativamente. Cuando el período de alquiler se termina, el
cliente debe solicitar otra dirección, aunque, en general, se le reasigna la
misma dirección.
3.3.3. Funcionamiento de DHCP
Veamos en primer lugar el funcionamiento básico con un cliente DHCP instalado

en un equipo conectado a una red en la que hay un único servidor DHCP disponi-
ble. Los pasos seguidos serían los siguientes, tal y como se muestra en la figura 3.1:
97
97
Direccionamiento
1. El cliente envía en modo broadcast un mensaje DHCP Discover, que con-

siste en una solicitud DHCP para que un servidor DHCP que la reciba le
envíe una posible configuración IP (mediante una oferta).
2. El servidor enviará de forma unicast (a la dirección física del cliente) un
mensaje DHCP Offer, que consiste en un mensaje de respuesta del Servi-
dor ante la petición anterior de asignación de configuración IP. Cuando un
servidor recibe el mensaje anterior, determina si puede servir esa petición
de su propia base de datos. Si no puede, es posible que el servidor envíe la
petición a otro servidor DHCP. En caso de enviar la oferta, el servidor debe
bloquear la configuración enviada al cliente para no asignarla a otro cliente
y, así, evitar duplicados.
3. El cliente selecciona la configuración del paquete DHCP Offer recibido y,
una vez más, solicita, mediante un mensaje DHCP Request, enviado en
modo broadcast, la configuración IP específica que le ofreció el servidor.
4. Cuando el servidor DHCP recibe el mensaje DHCP Request del cliente, se
inicia la fase final del proceso de configuración. Esta fase implica el reco-
nocimiento mediante el envío (unicast) de un mensaje DHCP ACK (o Ack-
nowledge) al cliente, incluyendo la duración del alquiler y cualquier otra
información de configuración que el cliente pueda haber solicitado. De esta
manera, mediante este acuse de recibo se completa el proceso de configu-
ración IP del cliente.
CLIENTE SERVIDOR
DHCP DHCP
Determina la
Configuración
a asignar
i
Envío Broadcast
Envío Unicast
Figura 3.1. Diagrama de tiempos del intercambio de mensajes entre un cliente y un servidor
DHCP
98
98
Es posible que en la red haya varios servidores DHCP activos. En ese caso, tras el
envío del mensaje Discovery en modo broadcast del paso 1, el cliente recibirá una
oferta (Offer) de cada servidor de las que tendrá que aceptar una, tal y como se
muestra en la siguiente figura. Cuando envíe el mensaje de solicitud (Request) de la
oferta escogida, al enviarlo a todos los servidores, se darán todos por enterados de
la configuración aceptada por el cliente (implícitamente rechaza las ofertas recibi-
das de otros servidores) y sólo le confirmará mediante un mensaje ACK el servidor
que le envió dicha oferta (en el caso de la figura, el servidor DHCP B).
SERVIDOR CLIENTE SERVIDOR

DHCP - A DHCP DHCP - B
Determina la
Configuración
Determina la
a asignar
C fi
Configuración
ió
a asignar
Proceso de respuestas
y selección de
configuración
Envío Broadcast
Envío Unicast
Figura 3.2. Diagrama de tiempos del intercambio de mensajes entre un cliente y varios servidores
3.3.4. Estados DHCP
En la figura 3.3 se muestran los diferentes estados por los que pasa un cliente
DHCP.
Cuando un cliente se inicia se encuentra en el estado de inicialización. En primer
lugar, envía un mensaje DHCP Discover por el puerto UDP número 67. A conti-
nuación, pasa a estar en el estado de selección, en el que recibirá una o varias ofer-
tas (mensaje DHCP Offer) de uno o varios servidores. En dichas ofertas, los servi-
dores ofrecen en la configuración una duración de alquiler que suele ser de una
hora, por defecto. Si el cliente no recibe ofertas, repite el proceso 4 veces en inter-
valos de 2 segundos. Si sigue sin recibir respuesta, el cliente descansa durante 5
99
99
Direccionamiento
minutos tras los cuales lo intentará de nuevo. En caso de que sí reciba respuestas,
elegirá una de las ofertas y enviará el correspondiente mensaje DHCP Request pa-
sando al estado de solicitud del que no saldrá hasta recibir del servidor un mensaje
DHCP ACK. La recepción del mensaje ACK le permitirá ya configurarse con la
información IP asignada y pasará al estado de asignación por un período igual al
tiempo de alquiler asignado. Cuando pasa un 50 % del tiempo de alquiler, el cliente
enviará un mensaje DHCP Request (incluyendo la dirección IP que tiene asignada)
para renovar la asignación. Nótese que estando en el estado de asignación, el clien-
te puede cancelar el alquiler o asignación, enviando al servidor un mensaje DHCP
Release11 (por ejemplo, porque ya no la necesita más) y volvería al estado de inicia-
lización e intentará obtener una configuración IP cuando la necesite de nuevo.
Inicio
(boot)
I i i li ió
Inicialización
DISCOVER
Selección OFFER
REQUEST
Solicitud
ACK
50% tiempo
ti alquiler
l il vencido
id C
Cancelación
l ió alquiler
l il
REQUEST RELEASE
Asignación
g
Tiempo alquiler vencido
NACK
ACK ACK
Renovación Reasignación
87,5% tiempo
p alquiler
q vencido
REQUEST
Figura 3.3. Diagrama de estados de un cliente DHCP
11
Un cliente envía al servidor DHCP un mensaje Release para liberar la configuración IP que tenía asignada. El servidor
marcará la dirección IP como ‘no asignada’. El servidor debería mantener un registro de los parámetros de inicialización del
cliente para un posible uso futuro como respuesta a las siguientes solicitudes del cliente.
100
100
Cuando el cliente envía una solicitud de renovación entra en un estado de renova-

ción del que no saldrá hasta que no suceda uno de los dos eventos siguientes: bien
recibe un mensaje ACK del servidor renovando el alquiler; o bien, en caso de no
haber recibido el ACK, si se llega al 87,5% del tiempo del alquiler, el cliente pasará
a un estado de reasignación.
El cliente cuando entra en el estado de reasignación no sale si no sucede cualquiera
de los siguientes 3 eventos: bien se recibe un mensaje DHCP NACK12 del servidor;
bien el tiempo de alquiler vence; o bien si recibe un mensaje ACK, el cliente vuelve
al estado de asignación y resetea el temporizador del alquiler. En los dos primeros
casos el cliente volvería al estado de inicialización e intentaría obtener de nuevo
una configuración IP.
Es posible que el cliente se haya desconectado de una red y se haya desplazado a
otra. En ese caso, estando en el estado de reasignación, el servidor le enviará un
NACK y el cliente deberá iniciar de nuevo el proceso de solicitud de su configura-
ción IP válida para la nueva red.
3.3.5. Formato de los mensajes DHCP
El formato de los mensajes DHCP está basado en el formato de los mensajes

BOOTP para garantizar la interoperabilidad de clientes BOOTP existentes con ser-
vidores DHCP13. El formato es prácticamente el mismo pero añadiendo ciertos bits
significativos en el campo de señaladores o flags, así como opciones adicionales en
el campo de opciones.
En la figura 3.4 se muestra dicho formato.
12
Un servidor DHCP envía un mensaje NACK a un cliente para rechazar su solicitud (Request) indicando que es incorrecta o
bien para indicar al cliente que el alquiler de la configuración ha vencido.
13
La RFC 1542 detalla las interacciones entre clientes y servidores BOOTP y DHCP.
101
101
Direccionamiento
32 bits
Código Operación Tipo de HW Long. Dir HW Num. Saltos

Identificador de Transacción
Numero de segundos Señaladores (Flags)
(Fl )
Dirección IP del Cliente ((ciaddr))
Tu Dirección IP (yiaddr)
Dirección IP del Servidor
Ser idor (siaddr)
( i dd )
Dirección IP del Gateway (giaddr)
Di
Dirección
ió Hardware
H d (16 bytes)
b ) (chaddr)
( h dd )
Nombre del Servidor (64 bytes) (sname)
N b dde archivo
Nombre hi bootfile
b fil (128 bbytes))
Opciones DHCP
(longitud
(l i d variable
i bl hhasta 312 bytes)
b )
Figura 3.4. Formato de un mensaje DHCP
El significado de cada campo es el siguiente:
- Código de operación (1 byte): Indica el tipo de mensaje, pudiendo tomar los

valores 1 y 2, por compatibilidad con BOOTP. El valor 1 es para los mensajes
de solicitud (Bootp Request) enviados por los clientes al servidor DHCP,
mientras que el valor 2 se incluirá en los mensajes de respuesta (Bootp Reply)
enviados por el servidor al cliente. Valdrá 1 para los mensajes DHCP Disco-
ver, Request, Inform14, Decline15 y Release. Valdrá 2 para los mensajes Offer,
ACK y NACK.
- Tipo de Hardware (1 byte): Indica el tipo de red física. Por ejemplo, para 10
Megabit Ethernet el tipo es 1.
- Longitud Dirección Hardware (1 byte): Indica la longitud en bytes de la direc-
ción física. Por ejemplo, la longitud para las direcciones físicas en Ethernet
(direcciones MAC) son de 6 bytes (48 bits) y por tanto en dichas redes este
campo contendría el valor 6.
14
Lo envía el Cliente al servidor para preguntarle sólo por parámetros de configuración local, cuando el cliente ya tiene
configurada externamente su dirección IP.
15
Si un servidor DHCP recibe un mensaje Decline de un cliente, éste le está indicando que rechaza los parámetros de asigna-
ción. Por ejemplo, el cliente, de la manera que sea, puede detectar que la dirección IP asignada ya está en uso.
102
102
- Número de Saltos (1 byte): Los clientes ponen el campo normalmente a cero.

Es utilizado opcionalmente por los relay agents (se explican más adelante)
cuando se obtiene la configuración vía uno de estos agentes, que incrementa-
rán este valor en una unidad tras su paso por ellos.
- Identificador de Transacción (4 bytes): Se trata de un número entero aleatorio
utilizado como identificador que el cliente incluye en sus mensajes y que sirve
para ser copiado en las respuestas y así poder asociar las respuestas con las so-
licitudes entre el cliente y el servidor. El servidor, por tanto, copiará el valor
que le llega en la solicitud a la respuesta asociada.
- Número de Segundos (2 bytes): Rellenado por el cliente, indica el número de
segundos transcurridos desde que éste inició el proceso de solicitud o renova-
ción de la configuración IP. Cuando el cliente inicia un proceso de solicitud lo
pone a cero. Si no se recibe respuesta, lo vuelve a intentar varias veces ponien-
do en este campo el tiempo transcurrido desde el inicio. Este campo no tiene
uso definido, aunque se podría utilizar para varios propósitos, como, por ejem-
plo, el servidor DHCP podría utilizar esta información para dar prioridad a de-
terminados clientes en función del tiempo que lleven solicitando configuración
IP.
- Señaladores o Flags (2 bytes): De estos 16 bits sólo se usa el primer bit deno-
minado Broadcast flag, el resto no se usan. Los clientes los ponen a cero y los
servidores los ignoran. El bit Broadcast flag lo puede activar un cliente para
forzar al servidor una respuesta broadcast en vez de unicast.
- Dirección IP del cliente (ciaddr, 4 bytes): Contiene la dirección IP del cliente.
Si el cliente no dispone de esta información incluirá todo ceros (0.0.0.0).
- Tu Dirección IP (yiaddr, 4 bytes): Será la dirección IP del cliente que rellenará
el servidor en su mensaje de respuesta a la solicitud asociada.
- Dirección IP del Servidor (siaddr, 4 bytes): Contiene la dirección IP del servi-
dor. La rellena el servidor en el mensaje de respuesta.
- Dirección IP del Gateway (giaddr, 4 bytes): Dirección IP del router de salida a
la red. La rellena el servidor en el mensaje de respuesta.
- Dirección Hardware del Cliente (chaddr, 16 bytes): Dirección física del clien-
te.
- Nombre del Servidor (sname, 64 bytes): Campo opcional rellenado por el ser-
vidor en una respuesta. Contiene una cadena de texto terminada en un carácter
nulo (NULL) conteniendo el nombre de dominio del servidor.
- Nombre de Fichero de configuración de arranque (bootfile): Campo opcional
de 128 bytes que puede ser rellenado por el servidor. Estará vacío (NULL) en
103
103
Direccionamiento
un mensaje DHCP Discover y contendrá una cadena de texto terminada en un

carácter nulo (NULL), con la ruta (path) y el nombre de un fichero de configu-
ración en un mensaje DHCP Offer.
- Campo de Opciones (hasta 312 bytes). Campo opcional que varía según el tipo
de mensaje DHCP (Discover, Offer, Request, Decline, ACK, NACK o Relea-
se). Los clientes DHCP deben ser capaces de recibir mensajes DHCP con un
campo de opciones de hasta 312 bytes. Esto implica que un cliente DHCP de-
be estar preparado para recibir un mensaje de hasta 576 bytes16, que se corres-
ponde con el tamaño mínimo de un datagrama que un host IP debe estar prepa-
rado para aceptar, según la RFC 1123 (Requirements for Internet Hosts
Communication Layers).
En este campo se pueden incluir diferentes opciones, como, por ejemplo, el
tiempo de alquiler de la configuración. Se puede obtener más información so-
bre las opciones en la RFC 2131.
El campo opciones contiene información adicional estructurada en opciones
siguiendo el formato definido originalmente para BOOTP. Para cada opción se
incluye un byte indicando el código de la opción, además de un byte indicando
la longitud de los datos de dicha opción que seguirán a estos dos bytes.
Existe una opción que indica el tipo de mensaje DHCP. Dicha opción está
formada por 3 bytes: un byte con el valor fijo ‘53’ (el código definido para di-
cha opción), un byte de longitud de los datos de la opción (en este caso la lon-
gitud es de 1 byte) mensaje y otro byte de datos conteniendo el tipo o código
de mensaje DHCP (ver tabla 3.1).
Códi (=53)
Código ( 53) L
Long (=1)
( 1) Ti (=
Tipo ( 1…7)
1 7)
Figura 3.5. Opción de tipo de mensaje DHCP (3 bytes)
16
548 bytes del mensaje DHCP + 8 bytes de cabecera UDP + 20 de cabecera IP.
104
104
Tabla 3.1. Campo de opción de tipo de mensaje DHCP
Tipo de mensaje Mensaje DHCP

1 Discover
2 Offer
3 Request
4 Decline
5 ACK
6 NACK
7 Release
3.3.5.1. Intercambio de Mensajes en el proceso de solicitud-respuesta
El funcionamiento básico de solicitud-respuesta DHCP es el mostrado en las dos

figuras siguientes:
Servidor DHCP
Cliente DHCP
MACA 158.42.100.200/16
MACServidor
DHCP Discover
MAC
CO g: MAC
Orig: CA IP O
Orig:
g: 0.0.0.0 U
UDP C dd : ??
Ciaddr: G dd : ?
Giaddr:
MAC Dest: FF:FF:FF:FF:FF:FF IP Dest: 255.255.255.255 67 Mascara: ? Chaddr: MACA …
Mensaje UDP
Datagrama IP
Trama Ethernet
17
Figura 3.6. Solicitud (Discover) enviada al servidor DHCP por un cliente
17
El puerto UDP que aparece en las figuras es el puerto de destino.
105
105
Direccionamiento
Servidor DHCP
Cliente DHCP
MACA 158.42.100.200/16
MAC
ACServidor
DHCP Offer
MAC
CO g: MAC
Orig: CServidor IP O g: 158.42.100.200
Orig: . . . U
UDP C dd : 158.42.100.10
Ciaddr: . . . dd : 158.42.100.1
Giaddr:
G . . .
MAC Dest: MACA IP Dest: 158.42.100.10 68 Máscara: 255.255.0.0 Chaddr: MACA …
Mensaje UDP
Datagrama IP
Trama Ethernet
Figura 3.7. Respuesta (Offer) enviada al cliente por un servidor DHCP
3.3.6. Conmutación (relay) DHCP. El Relay Agent
Los clientes DHCP utilizan broadcast en su mensaje de solicitud DHCP Discover

para encontrar un servidor DHCP que les responda con una oferta de configuración
IP. Sin embargo, es posible que el administrador de la red haya decidido incluir el
servidor DHCP en otra red IP a la que no pertenece el equipo cliente DHCP y sepa-
rada de ésta por uno o varios routers. Lógicamente, si la solicitud se envía mediante
broadcast, no llegará a la otra red y, por tanto, no le llegará al servidor DHCP ubi-
cado en ella.
Existen dos alternativas claras: colocar servidores DHCP en todas las subredes, lo
cual es claramente ineficiente, o bien utilizar lo que se denomina conmutación
DHCP (DHCP Relay).
Esta segunda opción se implementa mediante el uso de un agente de reenvío o Re-
lay Agent que es un router que reenvía solicitudes locales a servidores remotos (a
uno o a varios, según se configure). Al agente se le configuran las direcciones IP de
los servidores DHCP a los que tiene que reenviar las solicitudes de clientes que le
lleguen por sus interfaces de red que tenga configuradas para ello. El agente, cuan-
do recibe una solicitud broadcast de un cliente por una de estas interfaces, se encar-
106
106
ga de reenviarla, de forma unicast, al servidor (o servidores) DHCP que se le ha-

ya(n) configurado previamente. El servidor, cuando reciba la solicitud, le enviará la
respuesta de forma unicast (normalmente vía el router que implementa el Relay
Agent, aunque no necesariamente) al equipo cliente que realizó dicha solicitud.
El procedimiento se muestra en las siguientes figuras. El cliente envía el mensaje
Discover en modo broadcast. Al llegar al router con el Relay Agent activado, este
reenviará, pero ya de forma unicast, el mensaje directamente al servidor DHCP que
se le haya configurado. El agente incluirá, en el campo de Dirección IP del Gateway
(giaddr) del mensaje DHCP, la dirección IP del router que pertenezca a la misma
red a la que pertenece el cliente que realiza la solicitud (que será muy probablemen-
te la dirección del Gateway que se le configurará posteriormente al cliente). Real-
mente escoge la dirección IP del interface del router por el que éste ha recibido la
solicitud del cliente. De esa manera el servidor DHCP reconoce la red en la que está
el cliente y sabrá de qué conjunto de direcciones (el correspondiente a dicha red)
puede asignarle una libre al cliente. El servidor envía la oferta de configuración IP
de forma unicast al cliente mediante una entrega indirecta, tal y como se muestra en
la segunda figura (primero al router y éste la reenviará al cliente).
DHCP Discover
Broadcast
Cliente DHCP
MAC Orig: MACA IP Orig: 0.0.0.0 UDP Ciaddr: ?? Giaddr: ?
1 MAC Dest:
D FF FF FF FF FF FF
FF:FF:FF:FF:FF:FF IP Dest:
D 255 255 255 255
255.255.255.255 67 M
Mascara: ? Ch dd MACA …
Chaddr:
¿IP
IPA? 1
MACA
MAC R-A
Red A IPRR-AA
S id DHCP
Servidor
Router
(Relay Agent)
MACR-B
IPR-B IPServidor
MACServidor
2 Red B DHCP Discover
MAC Orig: MACR-B IP Orig: IPR-B UDP Ciaddr: ?? Giaddr: IPR-A

2 MAC Dest: MACServidor IP Dest: IPServidor 67 Mascara: ? Chaddr: MACA …
Unicast
Figura 3.8. Reenvío del mensaje Discover por el Relay Agent
107
107
Direccionamiento
DHCP Offer
Unicast
Cliente DHCP
MAC Orig: MACR-A IP Orig: IPServidor UDP Ciaddr: IPA Giaddr: IPR-A
2 MAC Dest:
D MACA IP Dest:
D IPA 68 M
Mascara: M
Masc. R d A Chaddr:
Red Ch dd MACA …
¿IP
IPA? 2
MACA
MAC R-A
Red A IPRR-AA
Router
Servidor DHCP
(Relay Agent)
MACR-B
IPR-B IPServidor
MACServidor
Red B DHCP Offer

ff
1
MAC Orig: MACServidor IP Orig: IPServidor UDP Ciaddr: IPA Giaddr: IPR-A
1 MAC Dest: MACR-B IP Dest: IPA 68 Mascara: Masc. Red A Chaddr: MACA …
Unicast
Figura 3.9. Respuesta del servidor DHCP remoto
108
108
NAT (Network Address Translation)
Capítulo 4. NAT (Network Address Translation)

4.1. Introducción
En este capítulo, antes de explicar en qué consiste la traducción de direcciones de

red o NAT (Network Address Translation), se presentarán una serie de conceptos o
ideas relacionados con la privacidad de las redes, aspecto a tener en cuenta a medi-
da que Internet crece, y la seguridad en la red resulta cada vez más crucial.
Se presentan los diferentes tipos de redes IP, enfatizando los conceptos principales
de red privada (red corporativa aislada de redes públicas que puede utilizar la pila
TCP/IP para las comunicaciones internas) y red privada virtual (red que utiliza in-
fraestructura de redes públicas, como Internet, y que, al mismo tiempo, requiere de
la privacidad como si de una red privada se tratase).
Finalmente, se presenta el mecanismo de traducción de direcciones de red (NAT)
que permite a una red privada utilizar dos conjuntos de direcciones, uno privado y
otro público global.
4.1.1. Tipos de redes
Una Red Privada se diseña para ser utilizada dentro de una organización privada,
permitiendo a los miembros de dicha organización el acceso a recursos compartidos
y, al mismo tiempo, proporcionándoles privacidad.
Una Intranet es una red privada (normalmente una LAN) que utiliza la pila TCP/IP
y que proporciona acceso limitado sólo a usuarios dentro de la organización. La red
privada normalmente ofrece servicios que fueron pensados para Internet (como
web, e-mail…), así como otros, como servidores de impresión, de ficheros, etc.
Una Extranet es igual que una intranet pero con la diferencia principal de que algu-
nos recursos pueden ser accedidos desde el exterior, por grupos de usuarios exter-
nos, pero bajo el control del administrador de la red.
Una Red Privada Virtual (Virtual Private Network o VPN) consiste en una red pri-
vada que utiliza infraestructura de red pública. Representa una solución más eco-
nómica bastante extendida en las organizaciones que utilizan Internet para sus co-
municaciones tanto internas como externas, pero con requisitos de privacidad en sus
comunicaciones internas.
109
109
Direccionamiento e interconexión
NAT (Network Address de redes basada en TCP/IP
Translation)
Las tres estrategias típicas para adquirir privacidad en una red son las siguientes:
Redes Privadas.
Redes Híbridas.
Redes Privadas Virtuales.
4.1.1.1. Redes Privadas
Las redes privadas consisten en redes corporativas aisladas de Internet, que pueden
utilizar o no los protocolos TCP/IP para sus comunicaciones internas, aunque hoy
en día es típica su utilización en todo tipo de redes. La infraestructura de la red
dependerá del tamaño. Por ejemplo, para una pequeña empresa con una única sede
una LAN podría ser suficiente.
Cuando las organizaciones disponen de varias sedes, lo típico es interconectar las
LANs de cada sede mediante routers y líneas alquiladas o Circuitos Virtuales Per-
manentes (CVP) equivalentes, garantizando la privacidad de las comunicaciones y
proporcionando seguridad frente a intrusiones.
En la siguiente figura se muestra un ejemplo de una red privada de una organiza-
ción con 2 sedes:
Sede A Sede B
… …
Línea alquilada Router

Router
R1 o CVP R2
Figura 4.1. Red Privada de una empresa con dos sedes
En caso de que la red privada no tenga conexión con Internet, la empresa no es

necesario que solicite rango de direccionamiento IP alguno a ningún organismo
oficial ya que el uso de las direcciones va a ser interno. Por tanto, podrá utilizarse
cualquier rango de direcciones sin preocuparse de que dichas direcciones estén
asignadas oficialmente a otra organización que sí esté conectada a Internet.
110
110
Capítulo NAT
4. NAT (NetworkAddress
(Network AddressTranslation)
Translation)
4.1.1.2. Redes Híbridas
Actualmente, la mayoría de las organizaciones necesitan privacidad en sus comuni-

caciones de datos internas, pero, al mismo tiempo, también necesitan disponer de
conexión a Internet para intercambiar datos con otras organizaciones. La solución
típica es la de utilizar una red híbrida, que permite a la organización tener su propia
interred IP interna y, al mismo tiempo, tener acceso a Internet. Los datos de las
comunicaciones internas serán encaminados dentro de la propia interred, mientras
que los datos dirigidos a las otras organizaciones serán encaminados a través de
Internet. La siguiente figura muestra un ejemplo para una organización con 2 sedes.
Otras Organizaciones
Red Pública
R3 (P.ej.,
(P ej Internet) R4
Sede A Router Router

Sede B
… …
Línea alquilada
q Ro ter
Router
Router
R1 o CVP R2
Figura 4.2. Red Híbrida de una empresa con dos sedes
Los datos de las comunicaciones internas se enviarán por la línea dedicada alquila-
da a un operador (o un CVP), ente los routers 1 y 2, mientras que los datos destina-
dos a comunicaciones externas con otras organizaciones a través de Internet se en-
caminarán a través de los routers 3 y 4. Como se verá más adelante, se pueden
utilizar direcciones IP privadas para las comunicaciones internas y utilizar direccio-
nes públicas para las comunicaciones a través de Internet.
4.1.1.3. Redes Privadas Virtuales (VPN)
El principal inconveniente de los dos tipos de redes anteriores es el coste económi-

co. Crear y mantener redes de área amplia privadas mediante líneas dedicadas o
circuitos (virtuales o físicos) permanentes es muy caro. El coste mensual crece en
111
111
Translation)
función del número de puntos a interconectar y del ancho de banda de las conexio-
nes. Además, es poco flexible en el caso de que las sedes de la empresa cambien de
ubicación a menudo.
Una solución mucho más económica consiste en utilizar una red pública, como, por
ejemplo, Internet, tanto para comunicaciones internas como para comunicaciones
externas a la organización. La tecnología VPN permite a las organizaciones la utili-
zación de Internet para ambos propósitos.
Otras Organizaciones
Red Pública
R1 (P. ej., Internet) R2

Sede B
… …
Figura 4.3. Red Privada Virtual (VPN) de una empresa con dos sedes
Se le denomina red privada porque garantiza privacidad en comunicaciones inter-

nas y virtual porque no utiliza redes (WAN) privadas. Se trata de una red físicamen-
te pública pero virtualmente privada.
Para garantizar la privacidad cuando se utiliza una red pública subyacente, se utili-
zan dos técnicas:
- IPSec (Internet Protocol Security), que consiste en un conjunto de protoco-
los para ofrecer seguridad a las comunicaciones IP mediante la autentica-
ción y el cifrado de cada paquete IP. Incluye protocolos para el estableci-
miento de autenticación mutua entre los agentes involucrados al inicio de
una sesión, así como la negociación de las claves de cifrado a utilizar en la
misma.
- Tunneling, que proporciona una especie de camino seguro a través de una
red no segura, como es Internet. Se basa en el encapsulamiento de las
PDUs de un protocolo en el campo de datos de las PDUs de otro protocolo
(o del mismo) utilizado en el transporte de la información, incluyendo me-
canismos adicionales que doten de seguridad (por ejemplo, el cifrado de la
información transportada).
112
112
Capítulo NAT
Translation)
En las siguientes figuras se puede apreciar cómo un datagrama IP original (incluida

su cabecera) es primero cifrado y, a continuación, encapsulado en otro nuevo data-
grama con una cabecera nueva. De esta forma, el datagrama original permanece
‘invisible’ hasta que llega al router remoto del otro extremo del túnel IP. Este router
extraerá el campo de datos del datagrama recibido, lo descifrará y, de esta manera,
obtendrá el datagrama original y se lo entregará al destino, según la dirección IP de
destino contenida en la cabecera.
HIP DatosIP
Datagrama IP original
Bloque cifrado
H’IP
H Datos’IP
Datos
Datagrama IP enviado
Figura 4.4. Encapsulamiento utilizado en las técnicas de tunneling
Comunicación cifrada
Red Pública
R1 (P. ej., Internet) R2

Sede B
… …
Figura 4.5. Comunicación cifrada en un servicio de VPN
4.2. Direccionamiento IP público y privado
Sin el desarrollo de nuevas tecnologías de asignación de direcciones IP, el rápido

crecimiento de Internet habría agotado aún más rápidamente la cantidad de direc-
113
113
Translation)
ciones IP debido, principalmente, al sistema inicial de asignación de bloques com-

pletos de direcciones de una determinada clase.
Uno de los mecanismos más extendido, que permitió poder compensar esta falta de
direcciones IP, es el mecanismo de traducción de direcciones de red conocido como
NAT (Network Address Translation).
En la RFC 1918 se describen los 3 bloques de direcciones IP siguientes para uso
privado, es decir que pueden ser utilizadas en cualquier red privada para su direc-
cionamiento interno, con independencia que en otra red privada se estén utilizando
las mismas direcciones.
1 dirección Clase A (10.0.0.0/8)
16 direcciones Clase B (172.16.0.0/12: 172.16.0.0 a 172.31.255.255)
256 direcciones Clase C (192.168.0.0/16)
Los routers fronterizos, que conectan las redes privadas (que hacen uso de estas
direcciones privadas) con Internet, deben estar configurados para no encaminar
hacia el exterior aquellos datagramas que vayan dirigidos a direcciones pertenecien-
tes a estos bloques.
Para poder conectar la red privada a Internet será necesario solicitar y registrar las
direcciones IP públicas a utilizar por la misma en proveedores de servicio de Inter-
net local (ISP o Internet Service Providers) o directamente en organismos oficiales,
como, en el caso de Europa, el Registro RIR Europeo o Réseaux IP Européennes
(RIPE).
Por tanto, a nivel interno se pueden utilizar direcciones privadas pero, de cara al
exterior (Internet), se deberá establecer algún mecanismo para traducir el direccio-
namiento privado a direccionamiento público, sin el cual sería imposible establecer
comunicaciones a través de Internet. Sin dicho mecanismo, un equipo con dirección
privada no podría acceder a Internet ya que dichas direcciones no son enrutables
(cuando un datagrama de una red privada llega a un router de un ISP conteniendo
direcciones IP de uso privado, este los descartará inmediatamente). Uno de dichos
mecanismos es NAT cuyo funcionamiento se explica en el siguiente apartado.
4.3. Funcionamiento de NAT
El funcionamiento básico se resume en la figura 4.6. Básicamente consiste en que

cuando se encamina un datagrama desde un equipo de la red interna hacia Internet,
a través de un router fronterizo, en el que se ha habilitado NAT, la dirección IP
fuente privada (192.168.5.2, en la figura) se traduce a una dirección IP pública
114
114
Capítulo NAT
Translation)
asignada a la empresa (en el ejemplo, la dirección 200.1.1.1, perteneciente a un

bloque público de direcciones de clase C), que sí pueda ser encaminada (enrutable)
hacia el exterior (en Internet). De esta manera, se permite que se transporte el data-
grama a través de Internet. En la respuesta que emita el destino (en caso de que
haya una respuesta), éste utilizará la dirección IP pública de tal manera que, cuando
el datagrama de respuesta llegue al router fronterizo desde Internet, se deberá reali-
zar el proceso inverso, es decir, se traducirá de nuevo la dirección IP pública a la
dirección IP interna privada para su entrega dentro de la red interna al equipo IP de
origen.
192.168.5.2/24 192.168.5.3/24 192.168.5.20/24
192.168.5.1/24 200.1.1.1/30
HIP DatosIP 200.1.1.2/30
Internet
Dir IP origen: 192.168.5.2
Router
R t
Router H’IP D t IP
Datos
NAT
Di IP origen:
Dir i 200
200.1.1.1
111
Traducción de direcciones en
el router
a)) Traducción en el envío a Internet
192.168.5.2/24 192.168.5.3/24 192.168.5.20/24
192.168.5.1/24 200.1.1.1/30
HIP DatosIP 200 1 1 2/30
200.1.1.2/30
I
Internet
Dir IP Destino: 192
192.168.5.2
168 5 2
Router
Router H’IP DatosIP
NAT
Dir IP Destino: 200.1.1.1
Traducción de direcciones en
el router
b) Traducción en la recepción desde Internet
Figura 4.6. Proceso de traducción de direcciones
Utilizando esta estrategia, la comunicación siempre debe iniciarse desde dentro de

la red privada (aunque existen mecanismos, como el de redireccionamiento de puer-
115
115
Translation)
tos en los routers fronterizos, para comunicarse con una máquina interna desde el
exterior).
Las empresas individuales pueden direccionar algunos o todos sus hosts con direc-
ciones privadas y utilizar NAT para brindar acceso a la Internet a sus equipos.
4.3.1. Terminología NAT
La terminología que se utiliza en NAT es la siguiente:
- Dirección Local Interna: Se trata de la dirección IP utilizada en la red in-

terna. Normalmente pertenecerá a una dirección del rango de las de uso
privado, aunque, si la empresa tiene direcciones IP públicas asignadas a sus
equipos, coincidirá con dichas direcciones.
- Dirección Global Interna: Dirección IP externa asignada por el ISP. Es la
dirección IP pública de origen con la que salen los paquetes de la red Inter-
na a través del router fronterizo. Si la empresa tiene direcciones IP públicas
asignadas a sus equipos, esta coincidirá con la local interna.
- Dirección Global Externa: Dirección IP pública de destino con la que el
origen ve al host externo con el que se desea comunicar.
- Dirección Local Externa: Dirección IP propia del equipo destino en la red
privada a la que pertenece (puede ser una dirección IP válida, en cuyo caso
coincidirá con la anterior, o una dirección IP de uso privado).
A continuación, en la figura 4.7, se muestra un ejemplo para una comunicación

entre un equipo de la sede A (origen) y otro de la sede B (destino), visto desde el
punto de vista del equipo en la sede A. Desde el punto de vista del equipo de la sede
B se intercambiarían los términos ‘interna’ por ‘externa’.
116
116
Capítulo NAT
Translation)
R1 INTERNET R2
200.1.1.1 158.42.100.1
158 42 100 1
Sede A Router
Dirección Router
Sede B
Dirección
Di ió
Global Interna Global Externa
172.16.10.2
192.168.1.2
Dirección
Dirección Local
Local Externa
I
Interna
Figura 4.7. Terminología NAT
4.3.2. Tablas NAT
El funcionamiento de traducción de direcciones es muy básico y se soporta gracias

a la existencia de las denominadas tablas de traducciones NAT, que rellenan los
routers para registrar las traducciones realizadas en cada momento. El registro de
cada traducción muestra el mapeo entre una dirección local y una dirección global.
La estructura de dicha tabla se muestra en la Tabla 4.1, donde se ha rellenado la
traducción realizada en la figura anterior:
Tabla 4.1. Tabla de traducciones NAT

Dirección Local Interna Dirección Global Interna Dirección Global Externa
192.168.1.2 200.1.1.1 158.42.100.1
Estas tablas se pueden rellanar manualmente, de forma estática (NAT estática), es

decir, asignando de forma fija direcciones locales a direcciones globales de forma
permanente; o bien las puede rellenar el propio router, de forma dinámica (NAT
dinámica), normalmente en una asignación de la forma ‘primero en solicitar, prime-
ro en ser asignado’. Ambos métodos requieren de suficientes direcciones IP para
poder dar servicio simultáneo de acceso a Internet a aquellos hosts de la empresa
que así lo requieran, con el consentimiento del administrador de la red.
117
117
Translation)
4.3.3. NAT con una o varias direcciones públicas
En muchos casos, las organizaciones conectan sus redes privadas a Internet a través
de un único acceso a Internet en cada una de ellas, para el que han negociado una
única dirección IP global válida con el ISP con el que lo tengan contratado. Si el
router tiene el servicio NAT básico habilitado, sólo podría acceder un único equipo
simultáneamente a Internet, puesto que sólo se dispone de una dirección IP pública
válida para asignar mediante NAT. Sería el caso de las figuras anteriores, donde la
tabla de traducción NAT sólo tendría un registro.
Si se requiere más direcciones IP públicas, se pueden solicitar al ISP, de tal manera
que el router donde se haya habilitado NAT pueda disponer de un conjunto (o va-
rios) de direcciones (pool) IP públicas para poder asignar a cuantos equipos se ne-
cesite que accedan a Internet de forma simultánea.
En el caso del ejemplo de la figura 4.8, la empresa dispone de 9 hosts a los que
quiere dar acceso a Internet y, por tanto, ha solicitado 10 direcciones IP, una de las
cuales asigna al router y las otras 9 las utiliza para asignar a los equipos de la red
mediante NAT. Por tanto, al router se la ha configurado un pool de 9 direcciones
para que las asigne a los equipos internos en función de sus necesidades de acceso a
Internet, por orden de solicitud.
R1 INTERNET
192.168.1.1 Router 200.1.1.1

Sede A
P l
Pool:
200 1 1 2
200.1.1.2
a Servidor Web
… 200.1.1.10 158 42 10 10
158.42.10.10
192.168.1.3
192.168.1.2 192 168 1 10
192.168.1.10
Figura 4.8. NAT con pool de direcciones
Supongamos que los dos equipos de la red con direcciones 192.168.1.3 y

192.168.1.5 han enviado datagramas al servidor web, quedando la tabla de traduc-
ción NAT de la siguiente manera:
118
118
Capítulo NAT
Translation)
Tabla 4.2. Tabla de traducciones NAT

Dirección Local Interna Dirección Global Interna Dirección Global Externa
192.168.1.3 200.1.1.2 158.42.10.10
192.168.1.5 200.1.1.3 158.42.10.10
Nótese que con NAT utilizado de esta forma, se traducen direcciones privadas a
públicas en base a una correspondencia 1:1. Por tanto, si un router fronterizo dispo-
ne de un pool de N direcciones para NAT, sólo N equipos de la red interna podrían
acceder a Internet al mismo tiempo.
4.3.4. Sobrecarga NAT
Existe un mecanismo para poder permitir el acceso a Internet a un número de equi-

pos mayor al número de direcciones IP públicas disponibles en la empresa, denomi-
nado Sobrecarga NAT. Esta técnica también se conoce como Traducción de direc-
ciones de puerto o PAT (Port Address Translation). Esta técnica permite asignar
varias direcciones locales internas (privadas) a una única o unas pocas direcciones
IP públicas. Para ello la tabla de traducción se amplía utilizando una combinación
de direcciones IP y puertos, de tal manera que cada dirección IP local interna es
relacionada con un número de puerto origen temporal asignado por el host que en-
vía el datagrama, aunque puede ser cambiado por el router con PAT habilitado, en
caso de que éste detecte coincidencias.
Supongamos el caso de la figura 4.9, en el que la red privada tiene 2 equipos que
desean conectarse al servidor web, pero sólo se dispone de una dirección IP pública
válida contratada al ISP correspondiente. En este caso la tabla de traducción NAT
quedaría de la siguiente manera:
Tabla 4.3. Tabla de traducciones NAT con sobrecarga

Dirección Local Puerto Dirección Global Dirección Global Puerto
Interna Origen Interna Externa Destino
192.168.1.2 1500 200.1.1.1 158.42.10.10 80
192.168.1.3 1501 200.1.1.1 158.42.10.10 80
En la respuesta del servidor web, el puerto origen de la solicitud (1500 o 1501) se

copiará en el campo destino de dicha respuesta. De esta manera, cuando llegue al
router fronterizo la respuesta, la pareja dirección IP destino-puerto destino identifi-
cará a cuál de los hosts de la red privada va dirigida dicha respuesta.
119
119
Translation)
R1 INTERNET
192 168 1 1 Router

192.168.1.1 200.1.1.1
S d A
Sede R t
Servidor Web
… 158.42.10.10
192 168 1 2
192.168.1.2 192 168 1 3
192.168.1.3
Figura 4.9. Sobrecarga NAT
Como es lógico, para que esta técnica funcione, los números de puertos temporales
(1500 y 1501) deben ser únicos. En caso de que dos solicitudes internas lleguen al
router con el mismo número de puerto (por ejemplo, 1400), la primera en llegar se
reenvía utilizando dicho número (1400) y la otra con un número de puerto consecu-
tivo (1401).
En caso de que el router fronterizo disponga de un pool de N direcciones, con esta
técnica se permite que el número de equipos de la red privada que se pueden conec-
tar de forma simultánea a Internet sea significativamente superior a N.
4.3.5. Ejemplo de ISP con NAT
Supongamos un ISP que proporciona acceso a Internet a 20.000 usuarios, pero que
sólo dispone de 200 direcciones IP válidas. Tendrá que utilizar NAT obligatoria-
mente. Para ello, por ejemplo, podrá dividir a los usuarios en 200 grupos, cada uno
conteniendo a 100 usuarios. A cada uno de los usuarios de un mismo grupo se le
puede asignar una dirección de red privada, de tal manera que los usuarios de cada
grupo formarán una red privada imaginaria.
El ISP traducirá cada una de las direcciones origen de los datagramas que reciba de
los usuarios y que serán salientes hacia Internet a una dirección IP global válida.
Del mismo modo, en los datagramas de respuesta que le lleguen desde Internet y
que tenga que enviar hacia los usuarios traducirá la dirección IP global de destino
por la dirección privada correspondiente. Para ello deberá existir una tabla con la
correspondiente traducción de direcciones para cada grupo.
120
120
Capítulo NAT
Translation)
172.16.1.1
ISP
172.16.1.2 R t
Router
172.16.1.100
172 16 1 101
172.16.1.101
INTERNET
172 16 1 102
172.16.1.102 Router
…
...
172.16.1.200
...
Figura 4.10. Ejemplo de ISP con NAT
4.4. Ventajas y desventajas del uso de NAT
Aunque el uso de la técnica NAT ofrece muchas ventajas también presenta ciertos
inconvenientes a tener en cuenta. En este apartado se explican tanto las ventajas
como los inconvenientes que supone su uso.
4.4.1. Ventajas del uso de NAT
Las ventajas que se pueden apreciar son las siguientes:
a) Permite conservar el direccionamiento IP público, permitiendo un mayor núme-

ro de equipos conectados a Internet de manera simultánea, ya que los equipos
de las redes privadas pueden configurarse con direcciones de uso privado y ac-
ceder a Internet compartiendo direcciones públicas, mediante NAT y/o PAT.
121
121
Translation)
b) Permite el acceso a Internet sin necesidad de disponer de una dirección IP pú-

blica para cada equipo interno de forma individual.
c) Permite una mayor flexibilidad de las conexiones a Internet.
d) Proporciona seguridad limitada (no reemplaza a un cortafuegos) ya que no se
puede acceder a dispositivos de la red privada por desconocer su dirección IP y,
además, no se permite el rastreo de las comunicaciones extremo a extremo.
e) Proporciona una mayor facilidad de administración y coherencia en los esque-
mas de direccionamiento privados. El esquema de direccionamiento privado es
transparente e independiente del sistema de direccionamiento público visto
desde el exterior. Una organización podría cambiar de ISP sin necesidad de
cambiar las direcciones de todos los equipos internos.
4.4.2. Desventajas del uso de NAT
Entre las desventajas que se pueden apreciar del uso de NAT se destacan las si-
guientes:
a) Degradación del rendimiento de las comunicaciones debido a los retardos por el

procesado de las traducciones.
b) Degradación de la funcionalidad extremo a extremo en aquellas aplicaciones
que requieren que los paquetes se envíen entre sistemas finales sin modifica-
ción alguna (por ejemplo, por seguridad).
c) No se pueden trazar las comunicaciones extremo a extremo, ya que las direc-
ciones cambian debido al uso de NAT en uno o varios puntos a lo largo del ca-
mino entre los dos sistemas finales que se comunican.
d) La utilización de técnicas de tunneling es más compleja. Por ejemplo, en IPSec
se utilizan mecanismos de comprobación de integridad que se ven afectados al
cambiar las cabeceras por el router NAT.
e) Introduce problemas en servicios que requieren inicialización de conexiones
TCP desde el exterior de la red privada, e incluso algunas comunicaciones me-
diante protocolos sin conexión, como UDP, pueden verse interrumpidas.
122
122
IPv6
Capítulo 5. IP versión 6
5.1. Introducción
Debido al gran crecimiento de dispositivos conectados a Internet y de la aparición

de las redes móviles, se vio que, tal y como se estaban asignando las direcciones IP,
rápidamente se produciría el agotamiento del espacio de direccionamiento IP ver-
sión 4 (IPv4).
En el año 2009, la tasa de penetración mundial de Internet era aproximadamente del
21%. Es decir, apenas un 21% de la población mundial estaba conectada a Internet.
En las principales zonas a nivel mundial la tasa de penetración era, aproximadamen-
te, la siguiente: 74% en Norte América, 24% en Latinoamérica, 48% en Europa,
15% en Asia, 5,3% en África, 21,3% en Oriente Medio y de 59% en Australia y
Oceanía.
Por un lado, se esperaba un crecimiento del número de usuarios conectados a Inter-
net espectacular, especialmente en el mundo asiático. Por otro lado, el crecimiento
que se vislumbraba de dispositivos conectados a Internet era muy elevado, espe-
cialmente de teléfonos móviles, PDAs, automóviles, dispositivos de control domó-
tico o industrial, etc. Todo ello hacía pensar que en breve espacio de tiempo se ago-
taría el espacio de direccionamiento que aún quedaba disponible de IPv4.
El protocolo que intentaba paliar el problema anterior se denominó IPv6 y fue desa-
rrollado, fundamentalmente, para resolver este problema de escasez de direcciones
de IPv4 y, además, incorpora otras muchas mejoras en otros aspectos bastante limi-
tados en IPv4, como en seguridad, eficiencia, calidad de servicio, tráfico multicast,
etc.
La versión 5 del protocolo IP (IPv5) se utilizó para desarrollar una solución de
streaming en tiempo real experimental, por lo que el nuevo protocolo que introducía
las anteriores mejoras a IPv4 se denominó IPv6.
IPv6 está especificado originalmente en la RFC 1883 (12/1995) y fue modificado
posteriormente en la RFC 2460 (12/1998).
123
123
Direccionamiento
IPv6 e interconexión de redes basada en TCP/IP
5.2. El Protocolo IPv6
5.2.1. Principales diferencias con IPv4
Los requisitos principales a la hora del diseño de IPv6 fueron tres: que fuera compa-
tible con IPv4; que se consiguiera un espacio de direccionamiento, prácticamente
inagotable a medio plazo, que diera cabida a un mayor número de dispositivos con
vistas a medio y largo plazo; así como que se permitiera una mayor movilidad de
los equipos conectados a Internet de la que se puede conseguir mediante DHCP y
NAT.
Para conseguir un espacio de direccionamiento suficiente, las direcciones pasaron
de 32 bits (4 bytes) en IPv4 a ser de 128 bits (16 bytes) en IPv6, consiguiendo hasta 2128
posibles direcciones, es decir, 340.282.366.920.938.463.463.374.607.431.768.211.456
direcciones disponibles. Hay suficientes direcciones para que el uso de NAT ya
no sea necesario, evitando sus desventajas descritas en el capítulo anterior.
En cuanto a la movilidad, IPv6 permite la autoconfiguración de los equipos
(plug&play), que no necesitan de la intervención de los usuarios a la hora de cam-
biar de ubicación. Como se verá más adelante, existe la posibilidad de que un dis-
positivo conectado a una red IPv6 puede autoconfigurarse su propia dirección IPv6
asignando los 8 últimos bytes de su dirección obtenidos a partir de su dirección
MAC y tomando los 8 primeros bytes del prefijo de la red a la que se conecte cada
vez, obtenido de uno de los routers de la misma.
Otras características de diseño de IPv6 son las siguientes:
Eficiencia: Las cabeceras de los datagramas IPv6 son más simples (menos
campos que en IPv4). No tienen campo de checksum y, por tanto, se elimi-
na la comprobación y procesado de dicho campo en cada salto, mejorando
la eficiencia de la transmisión.
Se definen extensiones opcionales de la cabecera denominadas cabeceras
de extensión, que permiten añadir nuevas funcionalidades cuando se nece-
siten. También se conocen como opciones encadenadas, ya que el campo
de opciones se reemplaza por el de Siguiente Cabecera, simplificando el
procesamiento en cada router y proporcionando un mecanismo adicional de
extensión de opciones.
124
124
Capítulo 5. IP versión
IPv66
Direccionamiento jerárquico. Las direcciones siguen una estructura jerár-

quica, lo cual permite reducir el tamaño de las tablas de encaminamiento,
permitiendo satisfacer los requerimientos cada vez más complejos del di-
reccionamiento jerárquico que IPv4 no proporcionaba.
No se admite broadcast y, por tanto, se evitan las tan temidas tormentas de
broadcast.
Posibilidad de envíos unicast, multicast y anycast, con mejor soporte para
multicast. La escalabilidad del encaminamiento multicast se mejora inclu-
yendo un campo ámbito a las direcciones multicast.
Seguridad: IPv6 incorpora mecanismos de autenticación, integridad de da-
tos y confidencialidad a nivel IP. Se incluyen técnicas de validación me-
diante técnicas de cifrado (seguridad mejorada mediante el uso de IPsec),
así como extensiones para utilizar autenticación, integridad de datos y, op-
cionalmente, confidencialidad de los datos.
Calidad de Servicio (QoS): IPv6 incluye mejoras en el tratamiento de la
QoS y permite el uso de etiquetas de flujo en el encabezado de los data-
gramas. Estas características mejoran el soporte de IPv6, respecto de IPv4,
para tráfico en tiempo real. Se pueden etiquetar paquetes que pertenecen a
determinados flujos de tráfico para el que el origen solicita tratamiento es-
pecial, como la QoS no estándar o un servicio en tiempo real.
Sencillez: Incluye la posibilidad de autoconfiguración de equipos y un ma-
nejo más simple del direccionamiento. Proporciona nuevos métodos de au-
toconfiguración automática de direcciones, así como de comprobación de
direcciones únicas.
Movilidad: Permite movilidad manteniendo la misma dirección (Mobile IP
nativo).
Evolución: Contempla mecanismos para futuras opciones. Los cambios en
la manera en que se codifican las opciones de la cabecera IPv6 permiten un
reenvío más eficiente, límites menos rigurosos en la longitud de opciones,
y mayor flexibilidad para introducir nuevas opciones en el futuro.
No se permite la segmentación en ruta. Todos los nodos han de soportar
una MTU mínima de 576 bytes.
Permite que un host pueda tener varias direcciones IP sobre un mismo en-
lace (host multihomed). Por ejemplo, un dispositivo podría conectarse a va-
rios ISPs a través de un único enlace.
125
125
Direccionamiento
5.2.1.1. Tipos de direcciones IPv6
Una interface de un router IPv6 puede tener asignadas múltiples direcciones de

cualquiera de estos tipos:
a) Unicast. Dirección que se asigna a una única interface. En IPv6 hay varios
tipos: global, reservada y de enlace local (link-local), que se explican pos-
teriormente.
b) Multicast. Dirección de grupo que permite el envío a grupos de hosts, per-
mitiendo un uso más eficiente de la red. IPv6 permite un rango mayor de
direcciones multicast disponibles.
c) Anycast. Este tipo de dirección también se denomina "dirección de envío a
uno (de)" y se utilizan para para enviar un paquete a cualquiera de un grupo
de nodos. Un paquete dirigido a una dirección Anycast se envía al nodo
más cercano dentro de un grupo referenciado con dicha dirección. Identifi-
ca una lista de nodos, por lo que la dirección es compartida entre varios
dispositivos. No tienen un direccionamiento especial distinguible. Este tipo
de dirección no puede ser utilizada como dirección de origen, ni tampoco
para direccionar a un host. Solamente puede asignarse a las interfaces de
los dispositivos que forman un grupo (dichas interfaces, además, tendrán su
dirección IPv6 real normal correspondiente). Por ejemplo, sirve para identi-
ficar a todos los routers de un ISP concreto, a todos los routers frontera de
un sistema autónomo18 dado, o a todos los routers conectados a una LAN
determinada. Se puede utilizar, por ejemplo, para balanceo de carga o ser-
vicios de distribución de contenido. En el caso de que la dirección identifi-
que a los routers de un ISP, puede indicar que se acceda a dicho ISP usan-
do el router por el camino más corto.
5.3. Cabecera de un datagrama IPv6
En la nueva versión, algunos campos de la cabecera IPv4 se han eliminado o se han

dejado opcionales, para reducir el coste asociado al procesado de cada datagrama en
los nodos, así como para limitar la pérdida de eficiencia de transmisión. En la figura
5.1 se compara el formato de las cabeceras de IPv4 e IPv6. En la cabecera de IPv6
18
Se define Sistema Autónomo (SA) como un grupo de routers controlados por una autoridad única. Por ejemplo, un SA
podría ser la red de una organización como la Universidad, una red corporativa o la red de un proveedor de acceso a Internet
(ISP), etc.
126
126
IPv66
se han sombreado los campos que cambian, mientras que en la cabecera IPv4 se han
resaltado los campos que desaparecen.
Los campos de la cabecera IPv6 son los siguientes:

Versión (4-bits). Indica la versión del protocolo IP. En este caso contendrá
un 6.
Clase de Tráfico (8 bits). Permite diferenciar clases de tráfico como, por
ejemplo, entre tráfico interactivo y tráfico normal. Permite la posibilidad,
incluso, de descartar ciertos datagramas en caso de congestión.
32 bits
Versión Clase de Tráfico Etiqueta de flujo
L
Longitud
i d de
d carga ú
útil
il Si Cabecera
Sig. C b Lí i saltos
Límite l
Dirección de origen
(16 bytes)
40 bytes
b
((16 bytes)
y )
Cabecera IPv6
Version Lon.Cab. DS Longitud total

Id tifi ió
Identificación XDM D l
Desplazamiento
i t
F F fragmento
Tiempo de vida Protocolo Checksum >=20 bytes
y
Dirección de origen <= 60 bytes
<
Opciones
p
Cabecera IPv4
Figura 5.1. Cabeceras IPv4 e IPv6
Entre las clases de tráfico están las siguientes:

- 0: Tráfico sin clasificar.
- 1: Tráfico de ‘relleno’, por ejemplo, noticias en red.
- 2: Transferencia de datos normal (por ejemplo, tráfico de co-
rreo electrónico).
127
127
Direccionamiento
- 3: Reservado.
- 4: Transferencias de datos atendidas (por ejemplo, transferen-
cia de ficheros).
- 5: Reservado.
- 6: Tráfico interactivo.
- 7: Tráfico de control de Internet (por ejemplo, mensajes de
protocolos de encaminamiento).
- Valores de 8 a 15: se pueden utilizar por los mecanismos de
control de congestión, si los protocolos de transporte utiliza-
dos no realizan dicho control, como es el caso de UDP.
Se descartarán antes datagramas con valores 8 o 9 que los datagramas con
valores más altos.
Etiqueta de Flujo. Se trata de una etiqueta que permite diferenciar clases de
flujos, permitiendo diferentes tratamientos en función de la etiqueta. De es-
ta manera, se puede señalar el tráfico que necesite tratamiento especial,
como es el caso, por ejemplo, del tráfico en tiempo real, que es posible que
necesite reserva de ancho de banda.
Longitud de Carga Útil (16 bits). Incluye un entero sin signo que indica la
longitud, en bytes, de la carga útil (campo de datos) del datagrama, es de-
cir, del resto del datagrama a partir del último byte de la cabecera. Nótese
que las extensiones de cabecera (extension headers) presentes en el data-
grama, si existen, se consideran parte de la carga útil, es decir, que estarían
incluidas en la longitud indicada en este campo.
Siguiente Cabecera (Next Header, 8 bits). Identifica el tipo de la cabecera
que sigue inmediatamente después de la cabecera IPv6 (es decir, en los
primeros bytes del campo de datos del datagrama IPv6). Utiliza los mismos
valores que el campo de Protocolo de la cabecera IPv4.
Límite de Saltos (8 bits). Entero sin signo que contendrá un valor que se
decrementará en 1 unidad en cada nodo que reenvíe el datagrama. El data-
grama se descartará cuando se llegue a cero. Similar al campo TTL de los
datagramas IPv4.
Dirección IP de Fuente (128 bits)
Dirección IP de Destino (128 bits). Puede ser que no coincida con el des-
tino final de la información, como pasa, por ejemplo, en el caso de que se
incluya una cabecera de encaminamiento.
128
128
IPv66
En IPv6 se define como flujo a una secuencia de datagramas desde un origen a un

destino IP que puede necesitar de un tratamiento específico. Todos los datagramas
que pertenecen a un mismo flujo tendrán los siguientes campos comunes: dirección
origen, dirección destino, clase de tráfico y etiqueta de flujo.
5.3.1. Cabeceras de Extensión IPv6
Las opciones en IPv6 se expresan como cabeceras adicionales encadenadas. Un

datagrama IPv6 conteniendo un mensaje del nivel de transporte puede contener
cabeceras intermedias entre la cabecera IPv6 y la cabecera del protocolo de trans-
porte utilizado (TCP o UDP). Estas cabeceras se denominan cabeceras de exten-
sión.
Existen unas pocas cabeceras de extensión definidas en RFCs, cada una identificada
por un valor que se codificará en el campo Siguiente Cabecera de la cabecera IPv6.
Un datagrama IPv6 puede contener ninguna, una, o varias cabeceras de extensión,
cada una identificada por el campo Siguiente Cabecera de la cabecera precedente.
Una implementación completa de IPv6 incluiría la implementación de las siguientes
cabeceras de extensión:
Opciones de Salto a Salto. Se utiliza para llevar información opcional que

debe ser examinada por cada uno de los nodos a lo largo de la ruta seguida
por el datagrama. Puede llevar un número variable de opciones.
Encaminamiento. Se utilizada por el origen IPv6 para indicar uno o más
nodos intermedios por los que necesariamente deberá pasar el datagrama.
Se puede combinar con direccionamiento anycast con tal de controlar las
rutas según las preferencias del ISP, o bien para indicar la necesidad de uti-
lizar un ISP concreto, por ejemplo, para llegar a un dispositivo móvil.
Cuando se utiliza esta cabecera, la respuesta del destino, si la hay, deberá
devolverse por la misma ruta hasta el origen.
Fragmento. Se utilizada por el origen IPv6 para enviar un datagrama de
mayor tamaño del que cabría en la MTU de la ruta hacia el destino19. La
fragmentación en IPv6 la realiza el origen y se indica con esta extensión de
19
A diferencia de IPv4, en IPv6 la fragmentación sólo se lleva a cabo por los nodos origen, no por los nodos intermedios
(Sección 5 de la RFC 2460)
129
129
Direccionamiento
cabecera. Incluye información muy parecida a la de los campos de segmen-

tación y re-ensamblado de la cabecera de los datagramas IPv4.
Opciones de Destino. Se utiliza para llevar información opcional que nece-
sita ser examinada solamente por el/los nodo/s de destino del datagrama.
Autenticación. Se utiliza para proporcionar integridad sin conexión y au-
tenticación del origen de datos para datagramas IPv6, así como para pro-
porcionar protección contra reenvíos.
Seguridad del Encapsulado de la Carga Útil. Se utiliza para para proporcio-
nar servicios de seguridad en IPv6
Las primeras cuatro cabeceras de extensión están especificadas en la RFC 2460,

mientras que las dos últimas están especificadas en las RFCs 2402 y 2406, respecti-
vamente.
Cada una ocupa una longitud correspondiente a un entero múltiplo de 8 bytes, con
tal de conservar la alineación de 8 bytes para las cabeceras subsiguientes. Los cam-
pos ‘Multiocteto’ dentro de cada cabecera de extensión se alinean en sus límites
naturales, es decir, los campos de ancho de n octetos son colocados en un entero
múltiplo de n octetos desde el inicio de la cabecera, para n = 1, 2, 4, u 8.
Veamos a continuación unos ejemplos de datagramas IPv6 conteniendo un (o parte
de un) mensaje TCP:
Cabecera IPv6
Campo Sig
Sig. Cab.
Cab = TCP Cabecera TCP Datos
Cabecera IPv6 Cabecera encaminam.

Campo Sig. Cab. = Siguiente Cab. = TCP C b
Cabecera TCP D t
Datos
= Encaminamiento
E i i t
Cabecera IPv6 Cabecera encaminam.

Cabecera Fragmento Fragmento de
C
Campo Si
Sig. Cab.
C = Siguiente Cab. = Datos
Siguiente
g Cab.=TCP Cabecera TCP
= Encaminamiento
E i i t = Fragmento
F t
Figura 5.2. Cabeceras de extensión
Excepto en el caso de la cabecera Opciones de Salto a Salto, que se explica a conti-

nuación, las cabeceras de extensión no serán procesadas por ningún nodo de la ruta
hasta que el datagrama llegue al nodo (o conjunto de nodos en el caso de un envío
multicast) identificado en el campo Dirección IP de Destino de la cabecera IPv6.
130
130
IPv66
Será en el destino donde se interpretarán las cabeceras de extensión. El contenido y

la semántica de cada cabecera de extensión determinan si se procede o no a proce-
sar la cabecera siguiente. Por tanto, de forma estricta, las cabeceras de extensión se
deben procesar en el orden en que aparecen en el datagrama IPv6.
La cabecera Opciones de Salto a Salto contiene información que debe ser procesada
por cada nodo a lo largo de la ruta entre el origen y el destino del datagrama IPv6,
incluyendo los nodos de origen y de destino. Cuando esté presente, dicha cabecera
seguirá inmediatamente a la cabecera IPv6 y se indicará por el valor ‘0’ en el campo
Siguiente Cabecera de la cabecera IPv6.
Cuando se incluya más de una cabecera de extensión en un mismo paquete, la RFC

2460 recomienda que aparezcan en el siguiente orden:
- Cabecera IPv6.
- Cabecera Opciones de Salto a Salto.
- Cabecera Opciones de Destino20.
- Cabecera Encaminamiento.
- Cabecera Fragmento.
- Cabecera Autenticación.
- Cabecera Seguridad del Encapsulado de la Carga Útil.
- Cabecera Opciones de Destino21.
- Cabecera de Capa Superior.
En la RFC 2406 se incluyen recomendaciones adicionales con respecto al orden
relativo de las cabeceras de Autenticación y Seguridad del Encapsulado de la Carga
Útil.
En un datagrama IPv6 cada cabecera de extensión puede aparecer sólo una vez, a
excepción de la cabecera Opciones de Destino la cual puede ocurrir, como máximo,
dos veces (una vez antes de una cabecera de encaminamiento y la otra antes de una
cabecera de capa superior).
20
Para las opciones a ser procesadas por el primer destino que aparece en el campo Dirección Destino IPv6, más los destinos
subsiguientes listados en la Cabecera Encaminamiento.
21
Para las opciones a ser procesadas sólo por el destino final del paquete.
131
131
Direccionamiento
Si la cabecera de capa superior fuera otra cabecera IPv6 (caso de tunneling IPv6 o
encapsulamiento de datagrama IPv6 en la carga útil de otros datagramas IPv6), ésta
puede ser seguida por sus propias cabeceras de extensión, siguiendo las mismas
normas indicadas anteriormente.
La RFC permite que los nodos IPv6 deban poder aceptar e intentar procesar las
cabeceras de extensión en cualquier orden y todas las veces que aparezcan en un
mismo paquete, a excepción de la cabecera Opciones de Salto a Salto que está res-
tringida a aparecer sólo inmediatamente después de una cabecera IPv6. Sin embar-
go, es recomendable que los datagramas IPv6 se creen respetando el orden reco-
mendado anteriormente, a menos que posteriores especificaciones (RFCs)
propongan otras normas.
Es posible que en el futuro se permita enviar datagramas IP sin carga útil, es decir,
sólo con cabecera (incluyendo las extensiones necesarias). En la última cabecera de
extensión, en el campo Siguiente Cabecera se indicará que ya no le sigue ninguna
otra cabecera.
5.4. Direcciones en IPv6
Inicialmente se barajaron varias propuestas de 8, 16 y 20 bytes para la longitud de

las direcciones IPv6. Las direcciones de 8 bytes (64 bits) hubieran sido suficientes
en cuanto a espacio de direccionamiento, pero no habrían permitido autoconfigura-
ción con dirección MAC de 48 bits. Las direcciones de 20 bytes (160 bits) seguían
el formato OSI (protocolo CLNP), pero resultaron impopulares por venir del mundo
OSI. Finalmente se decidió por direcciones de 16 bytes (128 bits) que aseguraban
un espacio de direccionamiento suficiente a medio y largo plazo.
Si, como en IPv4, se representara una dirección IPv6 en formato dotted decimal,
serían 16 números decimales (de 0 a 255) separados por puntos, lo cual hace invia-
ble su manejo de esta forma. Por ejemplo:
158.0.0.0.0.0.0.0.100.235.169.123.148.124.215.134
En IPv6 las direcciones se representan en hexadecimal, agrupando los bits en gru-

pos de 16 bits, pasados a hexadecimal y separados por ‘:’. La dirección anterior
expresada en hexadecimal quedaría de la siguiente manera:
9E00:0000:0000:0000:64EB:A97B:9454:D786
132
132
IPv66
Se siguen una serie de simplificaciones para no trabajar con direcciones muy largas
cuando hay cadenas de ceros. Los ceros a la izquierda pueden omitirse; y si uno o
más grupos son todo cero se puede abreviar con dobles dos puntos de tal forma que
no se creen ambigüedades, es decir, sólo se podrá utilizar dicha abreviación una vez
en cada dirección:
9E00::64EB:A97B:9454:D786
En caso de que haya varias cadenas de ceros, sólo una de ellas se podrá simplificar.
Por ejemplo, la dirección 90AB:345F:0000:2212:32FF:0000:0000:AB43, podrá
abreviarse con 90AB:345F::2212:32FF:0000:0000:AB43, o con
90AB:345F:0000:2212:32FF::AB43, siendo esta última la notación más abreviada.
Nunca podría ser representada por 90AB:345F::2212:32FF::AB43, ya que no se
sabría cuántos ceros hay en cada sitio abreviado.
Cuando se quiere que nodos IPv6 se conecten con otros nodos IPv6 a través de una
red IPv4 mediante técnicas de tunneling, que se explican más adelante, se puede
hacer corresponder direcciones IPv6 con un formato compatible con IPv4. Para
referenciar direcciones IPv4 se puede usar la notación decimal con puntos simples
(pero sólo a nivel de usuario y administrativo). Por ejemplo, la dirección IPv4
158.42.20.20 pasada a IPv6 podría referenciarse como:
0:0:0:0:0:0: 158.42.20.20, que es equivalente a ::158.42.20.20
Otras veces las direcciones IPv4 se insertan en los últimos 32 bits de las direcciones
IPv6. Éstas pueden utilizar el formato mixto, incluyendo los primeros 96 bits repre-
sentados en notación hexadecimal utilizando los ‘:’, y dejando en notación dotted
decimal los últimos 32 bits. Un ejemplo sería la siguiente dirección:
2001:720:101C:0:200:5EFE:158.42.23.125.
Como en IPv4, en IPv6 también se definen una serie de direcciones reservadas y de

uso privado. Por ejemplo:
- Dirección todo ceros o no especificada (unspecified address):

0:0:0:0:0:0:0:0:0, o bien, su equivalente ‘::’.
133
133
Direccionamiento
- Dirección de loopback o bucle interno: 0:0:0:0:0:0:0:0:1, o bien, su equi-

valente ‘::1’.
- Direcciones de sistemas IPv4 que no admiten la versión 6 se traducen en
direcciones de la forma 0:0:0:0:FFFF:a.b.c.d, donde la dirección a.b.c.d
es la dirección IPv4 del sistema
5.4.1. Prefijo de Formato de las direcciones IPv6
Los primeros bits de una dirección se llaman Prefijo de Formato (Format Prefix) e
identifican el tipo de dirección. En la tabla 5.1 se muestran algunos de estos prefi-
jos. Por ejemplo, el prefijo binario ‘001’ indica las direcciones unicast asignadas a
ISPs.
Tabla 5.1. Tabla de Prefijos de Formato
Prefijo (binario) Uso

0000 0000 Reservado (incluye IPv4)
0000 0001 No asignado
0000 001 Direcciones OSI NSAP
0000 010 Direcciones IPX de Novell Netware
0000 011, 0000 1, 0001 No asignado
001… (2000::/3) Direcciones globales unicast agregables
010, 011, 100, 101 No asignado
110, 1110, 1111 0, 1111 10 No asignado
1111 110, 1111 1110 0 No asignado
1111 1110 10… (FE80::/10) Direcciones privadas para enlaces locales
1111 1110 11… (FEC0::/10) Direcciones privadas
1111 1111… (FF00::/8) Direcciones multicast
5.4.2. Direcciones Multicast
En IPv6 las direcciones multicast se definen de forma más clara y eficaz que en
IPv4. Existen varios tipos de dirección multicast, según sean permanentes o tempo-
rales, locales o globales, pero en todas ellos el formato es el siguiente:
11111111(8 bits)22 000T(4 bits) Ámbito (4 bits) ID de grupo multicast (112 bits)
134
134
IPv66
El bit T valdrá ‘0’ para una dirección multicast permanentemente asignada por la
IANA23 (es decir, una dirección multicast pública conocida), que empezará, por
tanto, con la cadena hexadecimal ‘0xFF0’. El bit T valdrá ‘1’ en direcciones multi-
cast asignadas de forma temporal o transitoria, que empezarán, por tanto, con la
cadena hexadecimal ‘0xFF1’.
Ámbito (4 bits): indican el ámbito del envío multicast. De las 16 combinaciones
posibles de los 4 bits, se han definido las siguientes:
- ‘0000’ está reservada.
- ‘0001’ indica que el ámbito es local al nodo. Incluye el caso en el que se
envía un mensaje multicast a servidores o aplicaciones instaladas en el pro-
pio nodo.
- ‘0010’ indica que el ámbito es local al enlace.
- ‘0101’ indica que el ámbito es el lugar o sitio.
- ‘1000’ indica que el ámbito es la organización.
- ‘1110’ indica que el ámbito es global.
Por ejemplo, todo el tráfico dirigido a la dirección multicast FF02::2 tiene un alcan-
ce local al enlace. En IPv6 los routers nunca reenviarán este tráfico más allá del
enlace local.
Para identificar a todos los nodos del ámbito local al nodo y al enlace, se definieron
las siguientes direcciones multicast:
FF01::1 (node-local scope all-nodes address)

FF02::1 (link-local scope all-nodes address)
Para identificar a todos los routers del ámbito local al nodo y al enlace, se definie-
ron las siguientes direcciones multicast:
22
El prefijo 0xff indica que la dirección es de multicast
23
http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml
135
135
Direccionamiento
FF01::2 (node-local scope all-routers address)

FF02::2 (link-local scope all-routers address)
El resto de combinaciones de los cuatro bits correspondientes al Ámbito no fueron

asignadas al principio, aunque es posible que posteriormente se haya definido o
especificado alguna más.
5.4.3. Direcciones Locales
En IPv4 se dispone de bloques de direccionamiento para uso privado o local, como,

por ejemplo, los bloques 10.0.0.0/8 y 172.16.0.0/16. Tal y como se ha explicado en
capítulos anteriores, las organizaciones pueden utilizarlas en sus redes privadas,
pero si, posteriormente, se van a conectar a Internet, necesitarán mecanismos adi-
cionales, como NAT, o bien reconfigurar toda la red. En IPv6 se ha tenido en cuen-
ta este problema y se ha intentado solucionar, tal como se explica a continuación.
5.4.3.1. Direcciones de Enlace Local (Link-local)
Un enlace, según la terminología de IPv6 es un elemento de comunicaciones, como,

por ejemplo, una conexión a una red Ethernet, Token-Ring, FDDI, Frame-Relay,
ATM o una conexión mediante una línea punto a punto.
Las direcciones de enlaces aislados, es decir, sin conexión con un router se pueden
configurar de la siguiente manera:
1111111010 + 00…00 + Dirección única para la tecnología del enlace
es decir la secuencia binaria fija ‘1111111010’ al principio y al final la dirección

física propia de la tecnología utilizada. En medio se rellena con ceros. En el caso de
que el enlace fuera una conexión a una red local Ethernet, la dirección única sería la
dirección MAC, de 48 bits.
Un sistema puede conectarse con otro sistema del enlace utilizando su dirección
local del enlace directamente.
136
136
IPv66
5.4.3.2. Direcciones Locales
Si los equipos están conectados a una red en la que existen routers, pero sin cone-
xión a un ISP, se pueden generar direcciones internas de la siguiente forma:
1111111011 + 00…00 + ID de subred + Dirección única para la tecnología
, de tal manera que sean los routers los que proporcionen a los equipos de la red el
prefijo de red (incluyendo el ID de subred).
De esta manera la adaptación cuando la red se conecta a un ISP (conexión a la red
pública) resulta muy sencilla. Tan sólo habría que configurar en los routers el nuevo
prefijo que le proporcionará a la empresa el ISP escogido. Dicho prefijo de red
incluirá los bits del Registro RIR, del ISP, del cliente, de la subred, etc., tal y como
se explica a continuación.
5.4.4. Direcciones Públicas Jerárquicas (RFC 3587)
Tal y como se indicó en capítulos anteriores, la IANA es la entidad responsable de

la asignación de bloques de direcciones a los Registros Regionales (RIRs). Estos
registros, a su vez, se encargan de asignar bloques de direcciones a regiones meno-
res, a registros nacionales o a proveedores de acceso a Internet o ISP. Actualmente,
la IANA está asignando espacio de direcciones IPv6 en los rangos de 2001::/16 a
los cinco registros RIR mundiales (ARIN, RIPE, APNIC, LACNIC y AfriNIC)24.
Las direcciones en IPv6 siguen una estructura jerárquica. Tal y como se puede
apreciar en la figura 5.3, se utiliza un prefijo de red de encaminamiento global, que
facilita la agregación de rutas, de 64 bits, y un identificativo de interface, también
de 64 bits. En el prefijo de red se incluirá información también siguiendo una es-
tructura jerárquica (Registro RIR organización o ISP Lugar o Sitio Su-
bred), tal y como se aprecia en la figura. El identificativo de interface identifica al
dispositivo dentro de la subred IPv6 a la que pertenece, y se asignará a cada disposi-
tivo según diferentes métodos que se explican posteriormente. Se puede observar
que el encaminamiento hacia un proveedor es muy sencillo ya que basta con com-
parar el principio de la dirección de destino con las entradas de la tabla de encami-
24
http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml
137
137
Direccionamiento
namiento. El proveedor, a su vez, encaminará el tráfico interno a sus clientes com-

parando una porción algo mayor de la dirección y así sucesivamente.
Prefijo Subred
Prefijo Sitio
Prefijo ISP
Registro
2001 0720
/23 /32 /48 /64
Prefijo de red Id. de Interface

(64 bits) (64 bits)
Figura 5.3. Direcciones IPv6 jerárquicas
A continuación, en las siguientes dos figuras, se presenta de forma gráfica un ejem-

plo de la política y jerarquía de asignación de prefijos IPv6.
IANA
2001::/16
Af iNIC
AfriNIC APNIC ARIN LACNIC RIPE NCC
::/16
/16 to::/23
/23 ::/16
/16 to::/23
/23 ::/16
/16 to::/23
/23 ::/16
/16 to::/23
/23 ::/16
/16 to::/23
/23
ISP ISP ISP ISP ISP

ISP
/32 ISP
/32 ISP
/32 ISP
/32 ISP
/32
ISP
/32 ISP
/32 ISP
/32 ISP
/32 ISP
/32
/32 /32 /32 /32 /32
Site Site Site Site Site

Site
/48 Site
/48 Site
/48 Site
/48 Site
/48
Site
/48 Site
/48 Site
/48 Site
/48 Site
/48
/48 /48 /48 /48 /48
Figura 5.4. Ejemplo de asignación jerárquica
138
138
IPv66
El proceso de asignación de direcciones IPv6 seguido por la IANA se ve reflejado

en la siguiente figura:
Proceso de asignación
g de direcciones IPv6
E
Espacio
i de
d Espacio para los
direcciones
di i Registros asignado Espacio
E i asignado
i d Espacio
E i asignado
i d Espacio
E i asignado
i d a U Subred
Una S b d
completo
l por la IANA a un Registro
i a un ISP
S una organización
i ió
0000 0000
0000::0000 2001 /16
2001::/16 2001 0700 /23
2001:0700::/23 2001 0720 /32
2001:0720::/32 2001 0720 101C /48
2001:0720:101C::/48 2001 0720 101C 0000 /64
2001:0720:101C:0000::/64
U H
Un Host
FFFF:…:FFFF
:…:
2001:0720:101C:0000:0200:5EFE:9E2A:F255
Prefijo de Red ID de Interface

(64 bits)
i ) (64 bits)
Figura 5.5. Proceso de asignación de direcciones IPv6
5.4.5. Asignación del identificativo de interface
Las direcciones IPv6 utilizan un identificador de interface de 64 bits (ver figura 5.3)
para identificar cada interface de un dispositivo IPv6. Dicho identificador debe ser
único y coincide con el identificativo del host dentro de la dirección IPv6.
Se distinguen varias formas de asignar un identificativo de interface de una direc-
ción IPv6 a una de las interfaces de un dispositivo IPv6, tanto de forma estática
como de forma dinámica.
5.4.5.1. Asignación estática del identificativo de interface
La asignación estática se puede realizar de dos formas: asignando la dirección IPv6

completa a la interface del dispositivo de forma manual, tal y como se hacía para
IPv4, o bien mediante la asignación estática de un ID de interface EUI-64 (Exten-
139
139
Direccionamiento
ded Unique Identifier). Esta segunda manera consiste en configurar el prefijo de red
de la dirección IPv6 (64 bits) y obtener la parte del ID de la interface (64 bits res-
tantes) a partir de la dirección de Capa 2 (dirección MAC en redes Ethernet) del
dispositivo. Se obtiene mediante el estándar EUI-64, extendiendo las direcciones
MAC de 48 hasta 64 bits.
El estándar EUI-64 explica cómo extender las direcciones MAC de 48 a 64 bits
mediante la inserción de la secuencia hexadecimal ‘0xFFFE’ (16 bits) justo en la
mitad de la dirección MAC para crear un identificador de interface único de 64 bits.
Por ejemplo, si la dirección MAC (48 bits, es decir, 6 bytes) del interface al que se
le va asignar la dirección IPv6 es (en hexadecimal) 80-00-60-0F-E8-00, la dirección
modificada EUI-64 será la siguiente:
80 00 06 FF FE 0F E8 00
Figura 5.6. Dirección MAC modificada EUI-64

Si el dispositivo a configurar no dispusiera de dirección física, se escogería un iden-
tificador al azar (que con suerte no coincidirá con ningún otro de la red).
5.4.5.2. Asignación dinámica del identificativo de interface
La asignación dinámica del identificativo de interface a las direcciones IPv6 se

puede realizar también de dos maneras: haciendo uso del servicio DHCP que asigne
configuración IPv6, en el que el cliente puede solicitar al servidor tanto la dirección
completa como sólo el prefijo de red (64 bits); y mediante la autoconfiguración
automática, que se explica en el siguiente apartado.
5.5. Autoconfiguración automática de equipos
La autoconfiguración permite configurar automáticamente la dirección IPv6. Se

introdujo para permitir interconexión plug&play y facilitar la transición de IPv4 a
IPv6.
El dispositivo IPv6 obtiene la dirección a partir de dos bloques de 64 bits. El primer
bloque constituye el prefijo de red y lo obtiene de algún router de la red IPv6 a la
que se conecte el equipo. El otro bloque de 64 bits lo obtiene a partir de su direc-
ción MAC extendida EUI-64.
140
140
IPv66
El proceso seguido por el equipo se resume en la siguiente figura y consiste en los

siguientes pasos:
Router IPv6
Prefijo red: 2001:0720:101C:0000
11. Solicitud (multicast a 1

todos los routers IPv6)
d l prefijo
del fij de
d esta
t redd
2
2 Respuesta (unicast): El
2.
prefijo es
2001:0720:101C:0000
Equipo IPv6
MAC: 0F22:0A2C:C5DB
EUI-64: 0F22:0AFF:FE2C:C5DB
IPv6: ??
3 Entonces
3. E t mii di
dirección
ió IPv6
IP 6 deberá
d b á ser
2001:0720:101C:0000:0F2:0AFF:FE2C:C5DB
2001 0720 101C 0000 0F2 0AFF FE2C C5DB
Figura 5.7. Autoconfiguración automática
En primer lugar (paso 1) el dispositivo envía una solicitud multicast a todos los
routers de la red preguntando por el prefijo de la red a la que pertenecen. Los
routers, al recibir la solicitud le contestarán con una respuesta unicast conteniendo
el prefijo de la red IPv6 (paso 2). Una vez ya se tiene el prefijo de red, el identifica-
tivo de interface se obtiene mediante la extensión EUI-64 de la dirección MAC de
la interface de red a configurar.
5.6. Retraso en la implantación de IPv6
Aparte del fuerte desembolso económico que supone a los ISPs y operadores la
migración de sus equipos a IPv6, han ido apareciendo mejoras o soluciones que
paliaban los problemas y carencias de IPv4, y que, de forma indirecta, han retrasado
la implantación de IPv6. Entre dichas mejoras se pueden destacar las siguientes,
entre muchas otras:
141
141
Direccionamiento
- Mecanismos de ahorro de direcciones: NAT (Network Address Transla-

tion), Proxies, Cortafuegos, direccionamiento privado.
- Reducción del tamaño de las tablas de encaminamiento mediante el uso de
CIDR.
- En cuanto a seguridad, la aparición de IPSec (RFC 2410).
- En cuanto a mejoras relativas a Calidad de Servicio o QoS, las especifica-
ciones de Servicios integrados o Intserv (RFC 1633) y Servicios Diferen-
ciados o Diffserv (RFC 2475).
- Movilidad y autoconfiguración: DHCP (RFC 1534).
5.7. Estrategias de migración a IPv6
En el mes de febrero de 2011, la IANA asignó el último bloque que quedaba libre
de direcciones IPv4, finalizando, por tanto, el debate sobre si nos debemos preocu-
par o no de IPv6. La migración a IPv6 será un proceso que durará años y requerirá
una buena planificación, conocimiento del tema y herramientas de monitorización
(analizadores de tráfico) adecuadas. Actualmente, la migración a IPv6 se viene
haciendo de forma paulatina, de tal manera que van a convivir ambas versiones del
protocolo IP (versiones 4 y 6) durante algún tiempo. De esta manera, nodos con la
versión 6 necesitarán conectarse a nodos con la versión 4, y viceversa. Además,
tampoco se puede forzar a las empresas y organizaciones a que abandonen sus sis-
temas de direccionamiento actual y sus direcciones asignadas.
Se están desarrollando mecanismos que facilitan la realización y el entendimiento
de la transición de IPv4 a IPv6. Entre dichos mecanismos que permitirán dicha
convivencia y la migración progresiva tanto de las redes como de los equipos de
usuario se pueden destacar los siguientes:
- Dual-Stack o doble pila IPv4 e IPv6.
- Túneles.
- Traducción.
5.7.1. Dual-Stack o doble pila
La doble pila (Dual-Stack) hace referencia a una solución de nivel IP con doble pila
de protocolos (RFC 4213) incluyendo, de forma simultánea, tanto la pila de proto-
142
142
IPv66
colos de IPv4 como la de IPv6 en cada dispositivo conectado a la red. Por tanto,
cada dispositivo tendrá dos direcciones IP, una IPv4 y otra IPv6. Esto permite a los
dispositivos establecer sesiones utilizando tanto IPv4 como IPv6, según sus necesi-
dades. Se trata de una solución fácil de implementar y ampliamente soportada, lo
cual facilita el despliegue de IPv6.
El problema añadido al utilizar la doble pila es que en la red se requieren tablas de
encaminamiento y procesos de encaminamiento separados para cada protocolo
Doble Pila
…
IPv4 IPv6 IP 4
IPv4
IP2v4R
Subred
Router
IP1v4R/IP1v6R IP2v6R
…
IPv6
IPv41/IPv61 IPv42/IPv62
Figura 5.8. Solución de Doble Pila (Dual-Stack)
5.7.2. Tunneling IPv6
Un túnel IPv6 permite conectarse a redes IPv6 pasando por redes IPv4 (figura 5.9).
Para ello, los routers deben tener instalada la doble pila IPv4/IPv6, de tal manera
que los datagramas IPv6 puedan ser encapsulados en datagramas IPv4, tal como se
aprecia en la siguiente figura. De esta manera, se pueden enviar datagramas IPv6
sobre una infraestructura IPv4.
Se trata de una medida temporal, ya que, en el futuro, IPv4 irá desapareciendo pau-
latinamente y todos los dispositivos implementarán IPv6 de forma nativa.
Se pueden encontrar diferentes tipos de túneles:
• Manual. Se configuran las asignaciones entre direcciones IPv4 e IPv6 del

túnel de forma manual.
143
143
Direccionamiento
• 6-to-4: Funcionan de manera similar al túnel manual pero con direcciones

públicas, con la excepción de que los túneles 6-to-4 utilizan direcciones
IPv6 que enlazan las direcciones 2001::/16 con la dirección IPv4 (32bits)
del router frontera creando un prefijo de 48 bits. La asignación de direccio-
nes IPv6 se realiza de tal forma que contenga a la dirección IPv4 pública
del router. De esta manera, cuando sea necesario encapsular un datagrama
IPv6 para que atraviese la red IPv4, el router sabe la dirección a la que de-
be estar dirigido el datagrama IPv4 generado. Requiere que el final del tú-
nel tenga una dirección IPv4 pública, por lo que en caso de utilizar NAT el
final del túnel deberá ser el dispositivo que realice NAT, ya que será el que
tendrá dirección IPv4 pública.
• Túneles Teredo: Encapsulan datagramas IPv6 en segmentos UDP sobre
IPv4 y trabajan de manera similar a los mecanismos anteriores, con la ven-
taja de que pueden atravesar redes que estén utilizando NAT (como los
routers domésticos) y/o cortafuegos. Existen nodos denominados Teredo
relays, que tienen acceso a la red IPv6, reciben los datagramas IPv4 por su
conexión a la red IPv4, los desencapsulan y los reenvían (encaminan) por
la red IPv6.
Router de Router de
Doble Pila Doble Pila
IPv4R1 IPv4R2
IPv4
Red 1 IPv6 IP 6R1 Router
IPv6 Router Red 2 IPv6
Tunel
IPv6R2
… …
IPv61 IPv62 IPv63 IPv64
Figura 5.9. Tunneling IPv6
• Túneles ISATAP (Intra-Site Automatic Tunnel Addressing Protocol): per-

miten conectar dispositivos con doble pila (IPv4/IPv6) a través de redes
IPv4. Los dispositivos con doble pila utilizan ISATAP para encapsular da-
tagramas IPv6 en datagramas IPv4, utilizando la red IPv4 como un nivel de
enlace (o subred subyacente) para IPv6. A diferencia de 6-to-4, ISATAP
utiliza IPv4 como un nivel de enlace de una red de acceso múltiple sin
broadcast (NBMA o Non-broadcast multiple-access network), por lo que
144
144
IPv66
no requiere que la red IPv4 subyacente soporte multicast. ISATAP está im-
plementado en los últimos sistemas operativos de Microsoft (incluso para
dispositivos móviles), así como en algunas versiones de Cisco IOS (sistema
operativo de los dispositivos de Cisco).
5.7.3. Traducción
Todos los mecanismos de tunneling explicados anteriormente requieren que los

routers frontera tengan instalada la doble pila IPv4/IPv6 (Dual-Stack), es decir, que
soporten IPv4 e IPv6 simultáneamente. El mecanismo de traducción o translation
es un tipo de solución diferente que permite a dispositivos IPv6 comunicarse con
dispositivos IPv4 sin necesidad de dicho requerimiento.
La traducción será necesaria, por ejemplo, cuando un dispositivo que sólo soporta
IPv4 intente comunicarse con otro dispositivo que sólo soporte IPv6.
Existen numerosos mecanismos de traducción, como, por ejemplo los descritos en
la RFC 2766 (Network Address Translation - Protocol Translation, NAT-PT) o la
RFC 3142 (An IPv6-to-IPv4 Transport Relay Translator), entre otros.
145
145
Encaminamiento en IP
Capítulo 6. Encaminamiento en IP
6.1. Introducción
En una interred IP, los sistemas finales y los routers cooperan para facilitar el en-
caminamiento de la información (datagramas) desde el sistema final o host de ori-
gen hasta el sistema final o host de destino, pasando por cuantas subredes y routers
intermedios sea necesario.
En este proceso de encaminamiento extremo a extremo, existen tres procesos prin-
cipales:
1. El sistema final de origen necesita saber cuándo y cómo enviar la informa-

ción a un router.
2. El router o routers intermedios necesitarán saber cómo determinar una ruta
correcta hacia el destino de la información.
3. El router de entrada a la subred a la que pertenece el sistema final de des-
tino debe saber cómo conectarse o enviarle la información a dicho nodo.
La función de encaminamiento se realiza en el nivel de red o nivel IP de la pila

TCP/IP. Por tanto, debe ser transparente al nivel superior (donde estarán normal-
mente TCP o UDP), cuyas entidades se comunican extremo a extremo sin tener
constancia del procedimiento de encaminamiento utilizado por los niveles inferiores
en cada nodo de la red.
Figura 6.1. Encaminamiento en el nivel de red
147
147
Direccionamiento
Encaminamientoeeninterconexión
IP de redes basada en TCP/IP
Los protocolos o algoritmos de encaminamiento que se ejecutan en el nivel de red

(IP) se encargan de rellenar las tablas de encaminamiento IP de los routers. Aunque
se pueden configurar rutas estáticas en los mismos, lo habitual es que los adminis-
tradores de red utilicen algoritmos de encaminamiento dinámicos. Dichos algorit-
mos permiten que los routers puedan actualizar y mantener sus tablas de encami-
namiento de forma automática y dinámica según el estado de la red en cada
momento, y sin necesidad de la intervención del administrador de la red. Pueden
añadir a su tabla de encaminamiento rutas a nuevas redes remotas según las vayan
descubriendo, o bien modificar/actualizar rutas existentes a las redes conocidas, o
bien eliminar rutas obsoletas.
Los algoritmos de encaminamiento dinámico deberán adaptarse al estado de la red
en cada momento de la forma más rápida posible (tiempo de convergencia mínimo)
y evitando los denominados bucles de encaminamiento. Un bucle de encamina-
miento se produce cuando uno o varios paquetes se transmiten de forma continua a
través de un conjunto de nodos, pero sin posibilidad de llegar al destino hasta que
no se salgan de dicho bucle. Si el conjunto de nodos es de 2, uno de los dos nodos
estará enviándole los paquetes al otro nodo mientras que éste se los devolverá al
primero, y así sucesivamente hasta que no se corrijan dichas decisiones de encami-
namiento. Este tipo de bucle produce un efecto de ida y vuelta a los paquetes por un
mismo enlace, conocido como efecto ping-pong.
Las causas de la aparición de bucles de encaminamiento en las redes pueden ser,
por ejemplo, las siguientes:
- Configuración errónea de las rutas estáticas y/o de las rutas por defecto.
- Configuración errónea de la redistribución de rutas.
- Lenta convergencia. Mientras la red converge (ante la detección de un
cambio en la topología o estado de la red) puede que se tomen decisiones
de encaminamiento erróneas e incluso opuestas en los nodos contiguos.
- Problema de conteo a infinito.
Entre los efectos adversos de la aparición de un bucle de encaminamiento se pueden

destacar los siguientes:
- Aumento del uso del ancho de banda e los enlaces sin causa aparente.
- Mayor exigencia de recursos de procesamiento (CPU) de los nodos.
- Aumento del Tiempo de Convergencia.
148
148
Capítulo 6.Encaminamiento
Encaminamiento en
en IP
- Posible pérdida de actualizaciones de encaminamiento o que no se proce-

sen oportunamente.
Por tanto, los algoritmos de encaminamiento deberán reducir al máximo el tiempo

de convergencia, evitando al máximo los bucles de encaminamiento. Para ello se
necesitan procedimientos rápidos de descubrimiento y de notificación de cambios
en la red. Será necesario un intercambio de información (bien de forma periódica o
bien de forma eventual) entre los routers. Dicha información la toman directamente
de sus tablas de encaminamiento y, según el algoritmo utilizado, contendrá más o
menos información. Por ejemplo, en caso de que se trabaje con subnetting de más-
cara variable (VLSM) será aconsejable que los routers se intercambien la máscara
de subred utilizada en aquellas redes que conozcan.
Los protocolos de encaminamiento en los que los routers intercambian la máscara
de subred utilizada en las actualizaciones de encaminamiento, se denominan proto-
colos classless (sin clase), mientras que a los que no la envían se les denomina pro-
tocolos classfull.
Normalmente, el administrador de la red de un Sistema Autónomo25 (SA) elige un
protocolo de encaminamiento dinámico determinado para configurar y usar en to-
dos sus routers dentro del SA. A dichos protocolos se les denomina Protocolos de
Gateway26 Interiores (IGP). Como ejemplos de protocolos IGP se pueden citar a
RIP (Routing Internet Protocol), EIGRP (Protocolo mejorado de encaminamiento
de gateway interior o Enhanced Interior Gateway Routing Protocol), OSPF (Open
Shortest Path First), IS-IS (Intermediate System to Intermediate System), etc.
Por otro lado, los routers que interconectan SAs ejecutan otro tipo de protocolos de
encaminamiento denominados Protocolos de Gateway Exterior (EGP). El protocolo
BGP (Border Gateway Protocol) es un ejemplo de un protocolo EGP para encami-
namiento entre sistemas autónomos.
En la figura 6.2 se muestran los dos ámbitos de uso de ambos tipos de protocolo.
25
Desde el punto de vista del encaminamiento, un Sistema Autónomo (SA) consiste en un grupo de routers intercambiando
información mediante el uso de un mismo protocolo de encaminamiento.
26
Históricamente los routers TCP/IP se han denominado (IP) gateways, de ahí que en algunos nombres de protocolos se haya
mantenido esta palabra Sin embargo, en la literatura actual sobre TCP/IP se utiliza la palabra router cada vez con más fre-
cuencia, sustituyendo, por tanto, a la palabra Gateway, ya que ambas palabras tienen distinto significado en el modelo OSI.
149
149
Direccionamiento
En este capítulo se va a explicar únicamente el funcionamiento básico de dos de los

protocolos de encaminamiento IGP más utilizados en redes IP, y que siguen dos
filosofías de encaminamiento distintas, como son: el protocolo RIP (Routing Inter-
net Protocol), que sigue la técnica de encaminamiento por vector distancias y utiliza
como métrica el número de saltos; y el protocolo OSPF (Open Shortest Path First),
que sigue la técnica encaminamiento por estado del enlace y tiene en cuenta el an-
cho de banda de los enlaces en el cálculo de la métrica utilizada.
Figura 6.2. Encaminamiento de gateway interior (IGP) y exterior (EGP)
Ambos protocolos se encuadran dentro del conocido encaminamiento dinámico o

adaptativo, es decir, que las decisiones de encaminamiento (equivalente a la confec-
ción de las tablas de encaminamiento) varían en función del estado de la red posibi-
litando que el encaminamiento se adapte a dicho estado y seleccione rutas óptimas
en cada momento. Además, ambas técnicas también se encuadran dentro de lo que
se denomina un encaminamiento distribuido, que es aquél en el que las decisiones
de encaminamiento las toman cada uno de los nodos de forma independiente, sin
150
150
Encaminamiento en
en IP
necesidad de la existencia de ningún nodo especializado que tome dichas decisio-

nes, tal y como ocurre en el encaminamiento centralizado.
Por otro lado, la versión 1 de RIP era un protocolo classfull, mientras que la versión
2 de RIP y OSPF son protocolos classless.
6.1.1. Métrica y Distancia Administrativa (DA)
La métrica de una ruta es el valor calculado como la suma del coste de los enlaces
atravesados por dicha ruta. Los algoritmos de encaminamiento siempre elegirán
rutas con el mínimo valor obtenido en dicho cálculo (rutas de mínimo coste). Como
ejemplo de métricas utilizadas por los protocolos de encaminamiento IGP más co-
nocidos podemos citar las siguientes:
- RIP utiliza el número de saltos.

- IGRP y EIGRP tienen en cuenta el ancho de banda (por defecto), el retardo
(por defecto), la carga y la fiabilidad de los enlaces.
- IS-IS y OSPF utilizan como coste el ancho de banda de los enlaces.
Por otro lado, se define el concepto de Distancia Administrativa (DA) como un

valor numérico que indica la preferencia de una ruta determinada. En caso de en-
contrar varias rutas al mismo destino, tendrá preferencia aquella ruta que tenga un
valor de DA menor.
Las rutas conectadas directamente, tienen un valor de DA por defecto de 0 (máxima
preferencia, ya que se trataría de una Entrega Directa). Las rutas estáticas tienen un
valor de DA por defecto de 1. El resto de rutas aprendidas mediante diferentes pro-
tocolos de encaminamiento tienen diferentes valores de DA, según se muestra en la
tabla 6.1.
Por tanto, las rutas aprendidas con RIP tienen una DA de 120, mientras que las
aprendidas con OSPF tiene una DA de 110. Por tanto, si un router aprende dos rutas
a un mismo destino, una aprendida con RIP y otra con OSPF, la aprendida con
OSPF tendrá preferencia.
Aunque no es habitual, los administradores de red pueden cambiar las DA de de-
terminadas rutas para cambiar la prioridad de dichas rutas frente a otras que tienen
menor valor por defecto de DA.
151
151
Direccionamiento
Tabla 6.1. Distancias Administrativas por defecto

Ruta Valor de DA
Red directamente conectada 0
Ruta estática 1
Ruta resumida EIGRP 5
BGP externo 20
EIGRP interno 90
IGRP 100
OSPF 110
IS-IS 115
RIP 120
EIGRP externo 170
BGP interno 200
En la tabla de encaminamiento de los routers IP se encuentra tanto la información

de la métrica de las rutas como su DA.
En caso de que haya varias rutas con el mismo valor de métrica (coste) y obtenidas
con el mismo protocolo (por ejemplo, con RIP se pueden encontrar dos rutas al
mismo destino con el mismo número de saltos), los routers que tengan dicha opción
habilitada pueden utilizar ambas, realizando un balanceo de carga (distribuyendo
paquetes por las dos rutas según se le haya configurado, como por ejemplo, uno 50-
50% o un 25-75%..., o según estado de ocupación del enlace de salida de cada ruta).
6.1.2. Detección de redes
Cuando un router arranca (arranque en frío), éste añade las redes directamente
conectadas y las rutas estáticas que tenga en su configuración inicial a su tabla de
encaminamiento.
A partir de ahí, si dispone de un protocolo de encaminamiento dinámico, empezará
a enviar y recibir actualizaciones de encaminamiento (información de control de
encaminamiento) hasta que se produzca una convergencia total en la que todos los
routers conozcan rutas hasta las demás redes de la interred y se alcance un régimen
permanente, que no se verá alterado mientras no se produzcan cambios en la red.
152
152
Encaminamiento en
en IP
6.2. Protocolo de encaminamiento RIP
6.2.1. Encaminamiento por vector distancias
El protocolo RIP sigue la técnica de encaminamiento por vector distancias, al igual

que, por ejemplo, IGRP o EIGRP. Dicha técnica se basa en un intercambio periódi-
co entre routers vecinos (con conexión directa) de información de encaminamiento
(el vector de distancias). Sus principales problemas son la lenta convergencia y el
problema de conteo a infinito.
Tal y como se ha indicado en la tabla 6.1, la DA de las rutas aprendidas con RIP es
de 120, por defecto, aunque se puede cambiar. Como métrica se utiliza el número
de saltos, buscando aquellas rutas al destino con el mínimo número de saltos. Para
evitar problemas de conteo a infinito, se fija un máximo de 15 saltos en una ruta. Si
se supera dicho valor, el destino se considerará inalcanzable.
Existen 2 versiones del protocolo RIP: la versión 1 o RIPv1 (RFC 1058, 1988) y la
versión 2 o RIPv2 (RFC 1723, 1994, y RFC 2453, 1998):
- Por un lado, la versión 1 (RIPv1) es classfull, en las actualizaciones de en-

caminamiento no se incluyen las máscaras de subred (por tanto no soporta
VLSM). Además, el envío de actualizaciones se realiza mediante broadcast
cada 30 segundos y no admite CIDR.
- Por otro lado, la versión 2 (RIPv2) es classless, en las actualizaciones de

encaminamiento sí se incluyen las máscaras de subred (por tanto sí soporta
VLSM). Además, dichas actualizaciones incluyen la dirección del siguiente
nodo en las actualizaciones, que se envían por multicast. RIPv2, además,
admite autenticación (y envío de mensajes cifrados) de forma opcional.
A continuación se explica el formato de los mensajes y el funcionamiento de la

versión 1 y, posteriormente, se mostrarán las diferencias en estos dos aspectos de la
versión 2 con respecto a la versión 1.
153
153
Direccionamiento
6.2.2. RIP versión 1
6.2.2.1. Uso de temporizadores
RIP hace uso de 4 temporizadores:

- Temporizador de actualizaciones (por defecto, cada 30 segundos). Se usa
para el envío de las actualizaciones periódicas.
- Temporizador de invalidez. Si no se recibe actualización para renovar la ru-
ta existente una vez transcurridos 180 segundos (por defecto), la ruta se
marca como no válida (configurando la métrica máxima, es decir, con un
valor de 16). Se retiene la ruta en la tabla de encaminamiento hasta que se
vence el temporizador de purga que se explica a continuación.
- Temporizador de espera. Estabiliza la información de encaminamiento y
ayuda a evitar bucles de encaminamiento durante los períodos en los que la
topología converge a la nueva información. Una vez marcada una ruta co-
mo inalcanzable, ésta debe permanecer en espera el tiempo suficiente como
para que todos los routers de la interred aprendan sobre la red inalcanzable.
Por defecto, está configurado en 180 segundos.
- Temporizador de invalidez o de purga. Por defecto, se configura en 240 se-
gundos (60 segundos más que el de invalidez). Cuando vence, la ruta se
elimina de la tabla de encaminamiento.
6.2.2.2. Actualizaciones disparadas (triggered updates)
Para acelerar la convergencia cuando se produce un cambio en la topología (princi-

pal problema de la técnica de encaminamiento por vector distancias), RIP utiliza las
denominadas actualizaciones disparadas o triggered updates, que se envían sin
esperar a que venzan los temporizadores de actualización. Dichas actualizaciones
serán activadas o disparadas por eventos (no son periódicas como las actualizacio-
nes normales) como los siguientes: cuando cambia de estado una interface, cuando
una ruta pasa a ser inalcanzable, o cuando se añade una ruta a la tabla de encami-
namiento.
154
154
Encaminamiento en
en IP
6.2.2.3. Formato del mensaje RIPv1
En la siguiente figura se aprecia el formato de un mensaje RIPv1.
Figura 6.3. Formato de mensaje RIPv1
La cabecera del mensaje RIPv1 está dividida en 3 campos:

- Campo de comando. Toma el valor 1 para una solicitud o Request, y el va-
lor 2 para una respuesta o Reply.
- Campo de versión. Toma el valor 1 en este caso.
- 16 bits todos a ‘0’.
A continuación habrá hasta un máximo de 25 entradas de ruta, cada una de las cua-
les consiste básicamente en 3 campos:
- Identificador del tipo de direcciones. Indica el tipo de la dirección. En el
caso de trabajar con direcciones IP toma un valor 2, con la excepción de
cuando se solicita una actualización completa de la tabla de encaminamien-
to, que toma el valor de 0.
- Dirección IP de destino. Puede ser la de un equipo o host concreto o la de
una subred IP (con el HostId todo a ceros).
- Métrica. Contiene el número de saltos que tiene la ruta hasta el destino in-
dicado en el campo anterior. Contendrá un valor de 1 a 16. Un valor de 16
indica una ruta inalcanzable.
155
155
Direccionamiento
Nótese que los dos últimos campos constituyen la parte correspondiente a cada
destino en el vector de distancias del router que envía el mensaje
Dichos mensajes se envían en modo broadcast, encapsulados en UDP/IP con puer-
tos origen y destino 520, tal y como se muestra en la siguiente figura.
Figura 6.4. Encapsulamiento de los mensajes RIPv1 en redes Ethernet
6.2.2.4. Funcionamiento de RIPv1
RIPv1 funciona en modo solicitud/respuesta, para lo cual se definen 2 tipos de men-

sajes:
- Solicitud (Request). Se envían al iniciarse el router por cada una de las in-
terfaces (o enlaces) en las que se haya activado o habilitado RIP27. Se trata
de una solicitud a todos sus routers vecinos que tengan RIP habilitado para
que le envíen la información de actualización de encaminamiento (vector
distancias).
- Respuesta (Reply). Los routers vecinos envían la respuesta conteniendo di-
cha información.
Cada router, cuando se inicia, enviará por aquellas interfaces en las que tenga habi-
litado RIP una solicitud para que sus routers vecinos le envíen sus actualizaciones
completas. Cuando reciba las respuestas, actualizará su tabla de encaminamiento y,
a continuación, enviará por todas sus interfaces que tengan RIP habilitado su propia
actualización para que los routers vecinos la procesen, y actualicen su propia tabla
de encaminamiento, en caso necesario.
27
En los routers se puede activar o desactivar las actualizaciones de encaminamiento en determinadas interfaces por las que
interese o no enviarlas, respectivamente. Por ejemplo, por las interfaces que estén conectadas a subredes en las que no haya
más routers no tiene sentido enviar actualizaciones de encaminamiento, pues se estaría desperdiciando ancho de banda.
156
156
Encaminamiento en
en IP
6.2.2.5. Sumarización de rutas
Se definen los routers de borde como aquellos routers que conectan varias redes
con clase (classfull), es decir, que tienen interfaces en más de una red principal con
clase. En dichos routers, para reducir el tamaño de las tablas de encaminamiento y
obtener las ventajas que ello conlleva, se puede activar un mecanismo que permite
agrupar las rutas. Dicho mecanismo se denomina sumarización de rutas. Este pro-
ceso facilita la escalabilidad y puede ser configurado para eliminar muchos prefijos
de red de las actualizaciones de encaminamiento y dejar en las mismas sólo un pre-
fijo que los englobe a todos. De esta manera se reduce la cantidad de información
intercambiada y el tamaño de las tablas de encaminamiento, así como su procesa-
miento, facilitando la escalabilidad de la solución de encaminamiento.
Para explicar en qué consiste la sumarización de rutas, utilizaremos el ejemplo de
las figura 6.5, donde hay 3 subredes con clases B y C (172.16.0.0/16 de clase B, y
las subredes 192.168.1.0/24 y 192.168.2.0/24 de clase C), utilizadas de la siguiente
forma:
- La red 172.16.0.0/16 se subdivide en tres subredes: 172.16.1.0/24,
172.16.2.0/24 y 172.16.3.0/24
- De la red 192.168.4.0 se utiliza la subred: 192.168.1.4/30
- La red 192.168.2.0/24 se utiliza de forma completa para la red de la dere-
cha.
En dicha red, por tanto, el router R2 es un red de borde que interconecta la red de
clase B 172.16.0.0/16 con la red de clase C 192.168.1.0/24.
RIP resume automáticamente las redes con clase o classfull. Los routers de borde
resumen las subredes RIP desde una red principal hasta otra. En el ejemplo de la
figura, el router de borde R2 resumirá automáticamente las actualizaciones para las
tres subredes 172.16.1.0, 172.16.2.0 y 172.16.3.0 en 172.16.0.0 cuando se envíen
desde la interface I2, es decir, a R3 le enviará la ruta a la red con clase
172.16.0.0/16. Sin embargo a R1 le enviará la ruta a 172.16.3.0/24, además de las
rutas a las subredes 192.168.1.4/30 y a la subred 192.168.2.0/16.
RIPv1 utiliza la máscara de subred de la interface saliente para determinar qué su-
bredes publicar.
157
157
Direccionamiento
Figura 6.5. Sumarización de rutas
La tabla de encaminamiento del router R3 de la figura quedaría como sigue:
Figura 6.2. Tabla de Encaminamiento de R3

Destino Siguiente nodo Saltos
172.16.0.0/16 R2 1
192.168.1.4/30 Directamente conectada a I1
192.168.2.0/24 Directamente conectada a I2
158
158
Encaminamiento en
en IP
La sumarización de rutas permite, por tanto, reducir el tamaño de las tablas de en-
caminamiento de los nodos con el consiguiente ahorro de memoria en los mismos;
reducir el tamaño de las actualizaciones de encaminamiento, con el consiguiente
ahorro de ancho de banda utilizado por dichas actualizaciones; así como búsquedas
más rápidas en la tabla de encaminamiento y, por tanto, más rapidez en las decisio-
nes de encaminamiento.
Sin embargo, el principal inconveniente que tiene esta técnica es que no se puede
utilizar con subredes no contiguas (con una red classfull en medio). Es el caso de la
figura 6.6, donde R1 y R3, a diferencia de R2, tienen subredes provenientes de la
red principal 172.16.0.0/16. R1 y R3 serían routers de borde para 172.16.0.0/16
porque están separados por otra red principal, 10.0.0.0/8. Dicha separación crea una
subred no contigua, debido a que dos grupos de subredes 172.16.0.0/24 están sepa-
rados, al menos, por otra red principal. La red 172.16.0.0/16 es una red no contigua.
Figura 6.6. Subredes no contiguas
El problema de conteo a infinito típico de un algoritmo de encaminamiento de tipo

vector distancias se puede solucionar utilizando las técnicas Split-Horizon (horizon-
te dividido) y Split-Horizon Poisoned Reverse (horizonte dividido con envenena-
miento en reversa) que se usan para evitar que se produzcan bucles de encamina-
miento. Por un lado, la técnica split-horizon consiste en que un router no enviará a
través de una interface actualizaciones que incluyan rutas a redes si dichas rutas
las obtuvo a partir de actualizaciones recibidas por dicha interface. Por otro lado,
la técnica split-horizon poisoned reverse consiste en que una vez que un router
159
159
Direccionamiento
detecta una ruta inalcanzable a través de una interface, debe anunciar que es inal-
canzable a través de la misma interface (con un valor de 16 saltos como métrica o
coste).
6.2.3. RIP versión 2
La versión 2 de RIP se especificó en 1994 y está definida en la RFC 1723.
6.2.3.1. Similitudes con RIPv1
En cuanto a las similitudes con la versión 1, RIPv2 también se basa en el uso de

temporizadores para evitar bucles de encaminamiento; utiliza las técnicas de split-
horizon y split-horizon poisoned reverse para evitar el problema de conteo a infini-
to; incluye el uso de actualizaciones disparadas (triggered updates) para reducir el
tiempo de convergencia; y la métrica utilizada es el número de saltos, fijando un
máximo de 15 saltos, a partir del cual se considera una ruta como inalcanzable.
Aunque se puede deshabilitar esta función, RIPv2 también permite el resumen au-
tomático de rutas por los routers de borde en los límites de red principales y tam-
bién permite resumir rutas con una máscara de subred menor que la máscara de
subred classfull (CIDR). Los routers podrán enviar rutas agrupando subredes en una
superred de tal manera que sólo publicaran información de la superred y no de cada
una de las subredes de su interior.
La implementación y mantenimiento de RIPv1 y RIPv2 es mucho menos compleja
que en otros protocolos de vector distancias como, por ejemplo, EIGRP. Sin embar-
go, RIP tiene un tiempo de convergencia mucho más lento que EIGRP. Es por ello
que, aunque sea más complejo, EIGRP se utilizará en redes más grandes, dejando el
uso de RIP para redes de tamaño más reducido.
6.2.3.2. Formato de mensajes RIPv2
El formato del mensaje RIPv2 se muestra en la siguiente figura. Se puede apreciar

que es similar al de RIPv1, pero en este caso la entrada de cada ruta incluye una
Etiqueta de ruta y 2 extensiones adicionales:
- Campo de la máscara de subred.
- Campo de la dirección IP del siguiente nodo o salto.
160
160
Encaminamiento en
en IP
Figura 6.7. Formato de mensaje RIPv2
Al incluir la máscara de subred en las actualizaciones, RIPv2 se puede utilizar en

interredes IP donde se utiliza VLSM o máscaras de subred de tamaño variable.
6.3. Protocolo de encaminamiento OSPF (Open Shortest Path First)
6.3.1. Protocolos de estado del enlace
El protocolo OSPF (Open Shortest Path First) se basa en la técnica de encamina-

miento conocida como encaminamiento por estado del enlace. A los protocolos que
utilizan esta técnica también se les conoce como protocolos SPF o Shortest Path
First (primero la ruta más corta) y se crean sobre la base del algoritmo SPF de Dij-
kstra.
A continuación, se explica el proceso básico seguido, de forma resumida. En primer
lugar, los routers deben detectar aquellas redes a las que están conectados directa-
mente. A continuación, intercambian un paquete de saludo (hello) por sus enlaces
para descubrir a los routers vecinos; posteriormente que utilicen la misma técnica
de estado del enlace, crean paquetes de estado de enlace (LSP o Link State Packet)
con información específica que se detalla a continuación, y los envían al resto de
nodos de la red (a todos) utilizando técnicas controladas de inundación. Una vez
recibidos todos los LSP de los demás nodos de la red, cada nodo dispone de una
161
161
Direccionamiento
base de datos que le sirve para crear un mapa de la topología de la red (o su matriz
de costes equivalente) y calcular la mejor ruta (SPF) para cada destino, por ejemplo,
utilizando el algoritmo de Dijkstra.
Una vez los routers conocen a sus vecinos formarán una adyacencia. De esta mane-
ra, 2 routers vecinos adyacentes intercambiarán paquetes de saludo que servirán
para la monitorización de actividad en el enlace, detectando caídas de los propios
enlaces o de los nodos adyacentes.
El paquete LSP contiene la siguiente información sobre el estado de los enlaces del
router: información sobre la interface (Dirección IP, Máscara de subred, Tipo de
red), coste del enlace conectado a dicha interface, y los routers vecinos a través de
dicho enlace.
Los paquetes LSP se envían durante el inicio o arranque del router o proceso de
encaminamiento y cada vez que el router detecta cualquier cambio en la topología
que afecte a sus enlaces o a sus vecinos.
Comparados con los protocolos de vector distancias (como, por ejemplo, RIP, IGRP
y EIGRP), los protocolos de encaminamiento de estado de enlace necesitan más
memoria y requieren más capacidad de procesamiento de CPU. Además, el arran-
que de los protocolos de encaminamiento de estado de enlace puede consumir mu-
cho ancho de banda, pues todos los nodos envían sus LSP mediante técnicas de
inundación.
Entre los protocolos de estado de enlace podemos destacar el Open Shortest Path
First (OSPF, primero la ruta libre más corta) y el Intermediate System-Intermediate
System (IS-IS, sistema intermedio a sistema intermedio). En este apartado se explica
el protocolo OSPF.
6.3.2. Funcionamiento del Protocolo OSPF
En 1989, se publicó la versión 1 de OPSF (OSPFv1) en la RFC 1131 que consistió

en una versión experimental que nunca se implementó. La versión 2 del protocolo
OSPF (OSPFv2) se definió en 1991 en la RFC 1247 y se mejoró en 1998 en una
actualización definida en la RFC 2328. La versión 3 (OSPFv3, incluyendo para
IPv6) se publicó en la RFC 2740 en 1999 y se mejoró en la RFC 5340, en 2008.
La DA por defecto de las rutas aprendidas mediante OSPF es de 110. OSPF incor-
pora mecanismos para cifrar y autenticar la información de encaminamiento, de tal
forma que sólo se acepte información de encaminamiento de otros routers que ha-
yan sido configurados con las credenciales adecuadas.
162
162
Encaminamiento en
en IP
OSPF es un algoritmo de encaminamiento classless, por lo que en las actualizacio-

nes de encaminamiento se incluirá la máscara de subred. De esta forma se permite
trabajar con subnetting de máscara de tamaño variable (VLSM) y con CIDR.
A diferencia de RIPv2, OSPF no sumariza rutas automáticamente en los límites o
borde de las redes principales. Además, OSPF utiliza el ancho de banda de los enla-
ces como métrica para determinar la mejor ruta (de mínimo coste), mientras que
RIP utilizaba el número de saltos como métrica.
A continuación se presentan los aspectos más importantes de OSPF.
6.3.2.1. Tipo de áreas OSPF
OSPF permite dividir los sistemas autónomos en áreas numeradas para facilitar su
administración. Un área OSPF es un grupo de routers que comparten información
sobre el estado de enlace (todos tendrán la misma base de datos de LSPs).
En OSPF se pueden distinguir 3 tipos de área:
1. Área Backbone. También conocida como área 0 y debe estar presente en

todas las redes OSPF. Forma el centro o núcleo de una red OSPF, mante-
niendo conexión, bien física o bien lógica, con las demás áreas de la red.
La conexión entre un área y el backbone se realiza mediante los Router de
Borde (fronterizo) de Área (Area Border Router o ABR) explicados en el
siguiente apartado.
2. Área Stub. Una red stub es una red, o parte de una interred, que no tiene
conocimiento de otras redes, y que normalmente enviará todo el tráfico que
no sea local a través de un único camino a través un router de salida, es de-
cir, con el único conocimiento de un router de salida por defecto hacia to-
dos los posibles destinos externos a la red.
3. Área not-so-stubby (NSSA). Son un tipo de área stub que puede importar
rutas externas de SAs y enviarlas al Área Backbone, pero que no puede re-
cibir rutas externas de SAs desde el Área Backbone u otras áreas.
163
163
Direccionamiento
6.3.2.2. Tipos especiales de routers en OSPF
Al dividir una red en áreas, se necesitará, por un lado, poder encaminar todo el trá-
fico dentro de las propias áreas (encaminamiento intra-área) para lo que se encarga-
rán los routers OSPF dentro de la propia área que, mediante OSPF, mantendrán
información sobre la topología de la red dentro de la propia área. Sin embargo,
también será necesario encaminar tráfico entre las distintas áreas de un SA (enca-
minamiento inter-área) y entre distintos SAs (encaminamiento externo). Para estos
dos tipos de encaminamiento, OSPF define dos tipos de routers especiales que man-
tendrán información topológica más completa que la del área en la que se sitúan.
1. Routers de borde (fronterizos) de área o ABRs (Area Border Routers).

Mantienen la información topológica de las áreas a las que pertenece y co-
nectan éstas con el resto de áreas (encaminamiento inter-área). Son los res-
ponsables de la gestión de las rutas no-internas del área (entre el área y el
resto de la red).
2. Routers de borde (fronterizos) de un Sistema Autónomo (Autonomous Sys-
tem Border Routers o ASBRs). Estos routers permiten el encaminamiento
de información fuera del SA (encaminamiento externo).
En el caso más extremo, que es aquél en el que los datagramas que salgan de un SA,
siguen rutas jerárquicas, los datagramas serán enviados por los routers, dentro del
área donde se hayan originado, hasta el ABR correspondiente de dicho área, y, a su
vez, éste los reenviará al ASBR correspondiente para que los encamine fuera del
SA.
6.3.2.3. Identificativo de un Router
En OSPF, se utiliza como identificativo de un router un identificativo de 32 bits que

lo identifica de forma unívoca dentro de un sistema autónomo. Suele ser una direc-
ción IP utilizada para identificar a cada router.
Se suelen seguir los siguientes criterios para obtener el identificativo de un router:
1. Utilizar el identificativo configurado de forma manual en el router. Éste

tiene prioridad sobre las direcciones de las interfaces loopback (interfaces
164
164
Encaminamiento en
en IP
internas, para pruebas, de lazo propio al router, sin conexión a ningún enla-
ce) y físicas.
2. Si no se dispone de un identificativo configurado, el router elige la direc-
ción IP más alta de cualquiera de las interfaces loopback, en caso de que
tenga configuradas.
3. Si no se dispone de un identificativo configurado, y no hay interfaces
loopback configuradas, se utiliza la dirección IP más alta de cualquiera de
las interfaces activas.
Cuando se utiliza OSPF, se pueden configurar interfaces loopback en los routers por
razones de seguridad ya, que éstas son internas al propio router y nunca fallan. Las
interfaces físicas suelen tener más problemas.
6.3.2.4. Mensajes OSPF
También se pueden distinguir los 5 tipos de mensajes OSPF que se muestran en la

siguiente tabla:
Tabla 6.3. Tipos de Mensajes OSPF
Tipo Nombre Propósito
1 Saludo Descubrir vecinos para crear adyacencias
Descripción de Bases Para controlar la sincronización de la información entre
2
de Datos (DBD) routers
Solicitud de Estado del Solicitar registros específicos de estado del enlace de
3
Enlace (LSR) router a router
Actualización de Estado Enviar los registros de estado del enlace específicamente
4
del Enlace (LSU) solicitados
Acuse de Recibo de
5 Estado del Enlace Reconocimiento de cada uno de los demás paquetes
(LSAck)
El mensaje de actualización de estado de enlace (LSU o Link State Update) se utili-

za para para entregar publicaciones del estado de enlace (LSA o Link State Adverti-
sement). Las LSA contienen información de ruta para las redes destino. Una LSU
contiene una o más LSA y, por tanto, contiene información acerca de los vecinos y
los costes de las rutas hasta ellos.
Las áreas OSPF se definieron, además, para mejorar la escalabilidad. De esta forma,
algunas LSAs no se enviarán por inundación utilizando todas las interfaces de sali-
165
165
Direccionamiento
da, sino sólo por aquellas interfaces que pertenecen a un área OSPF determinada.
Así, la información detallada de todas las rutas puede mantenerse de forma locali-
zada (por ejemplo, dentro de un área), mientras que sólo se enviará por inundación
la información sumarizada al resto de la red. De esta manera, se favorece la escala-
bilidad, pues se consumen menos recursos de red (procesamiento, ancho de banda y
memoria).
Hay varios tipos de LSA, todos ellos con una cabecera común, de 20 bytes, que se
muestra en la figura 6.8.
Cada enlace de un router puede ser de 4 tipos (ver la tabla 6.4). Uno de los campos
de la cabecera es el ID del estado del enlace (link-state ID) que identifica, por la
dirección y la máscara de la subred, el objeto al cual se conecta dicho enlace. De-
pendiendo del tipo, dicho identificativo del enlace tiene diferentes significados
(tabla 6.4).
Figura 6.8. Formato de una LSA
Tabla 6.4. Tipos de Enlaces

Tipo Identificativo del enlace
de Descripción Datos del enlace
(link-state ID)
Enlace
Conexión punto a punto Dirección IP de la inter-
1 ID del router vecino
con otro router face origen
Conexión a una red de Dirección IP del Router Dirección IP de la inter-
2
tránsito Designado face origen
Conexión a una red Máscara de subred de la
3 Red IP/máscara de subred
final o stub interface
Dirección IP de la inter-
4 Enlace virtual ID del router vecino
face origen
166
166
Encaminamiento en
en IP
OSPF define los siguientes tipos de LSA:
- Tipo 1 (Router LSA). Con esta publicación el router anuncia su presencia a

los demás routers así como una lista de los enlaces a otros routers o redes
en la misma área junto con la métrica de cada uno de ellos. Sólo se envían
por inundación dentro de su área. El Identificativo del enlace (link-state
ID) del LSA de tipo 1 es el ID del router originador del mensaje.
- Tipo 2 (Network LSA). El router designado (DR28) en un segmento broad-
cast (como, por ejemplo, Ethernet) lista qué routers están unidos entre sí
por dicho segmento. Los LSAs de este tipo se inundan sólo por el área co-
rrespondiente. El Identificativo del enlace (link-state ID) del LSA de tipo 2
es la dirección IP de la interface del DR.
- Tipo 3 (Summary LSA). Un router de borde de un área (Area Border Router
o ABR), conectando varias áreas, toma la información que ha aprendido de
una de las áreas y la sumariza antes de enviarla al resto de áreas a las cuales
está conectado. Esto ayuda a facilitar la escalabilidad eliminando informa-
ción de detalle de otras áreas, ya que la información de encaminamiento se
sumariza en sólo un prefijo de red y una métrica. El Identificativo del enla-
ce (link-state ID) del LSA de tipo 3 es la dirección de subred de destino y
la máscara de subred.
- Tipo 4 (ASBR-Summary LSA). Los LSA de tipo 4 se envían por inundación
a todas las áreas y es posible que en algunas de ellas la información deta-
llada del siguiente salto no esté disponible. Esto un ABR lo resuelve inun-
dando la información para el router origen del LSA de tipo 4 (por ejemplo,
el router de borde de un SA, ASBR), mediante un LSA de tipo 4. El Identi-
ficativo del enlace (link-state ID) del LSA de tipo 4 es el router ID del
ASBR.
- Tipo 5 (External LSA). Contiene información importada a OSPF de otros
procesos de encaminamiento. Son enviadas por inundación a todas las
áreas. El Identificativo del enlace (link-state ID) del LSA de tipo 5 es la di-
rección de red externa.
- Tipo 6 (Group Membership LSA). Sólo lo soportan unos pocos routers y
fue definido para el protocolo de encaminamiento OSPF multicast
(MOSPF), que está en desuso desde la aparición de OSPFv3.
28
Su significado y función se explica más adelante en el capítulo.
167
167
Direccionamiento
- Tipo 7. Los routers en una Not-so-stubby-area o NSSA no reciben LSAs ex-

ternos de los ABRs pero sí se les permite enviar información de encami-
namiento externa para su redistribución. Para ello, mediante este tipo de
LSAs informan a los ABR sobre estas rutas externas que el ABR traducirá
a LSAs de tipo 5 y que los enviará de forma normal por inundación al resto
de la red OSPF.
- Tipo 8 (A link-local only LSA for OSPFv3). Son utilizados para enviar in-
formación sobre direcciones de enlace local y una lista de direcciones IPv6
en el enlace.
- Los tipos 9, 10 y 11 han sido definidas en actualizaciones posteriores a
OSPF, para propósitos específicos (for application-specific purposes).
Un mensaje OSPF consta de una cabecera más un conjunto de campos adicionales

que dependen del tipo de mensaje. La cabecera de un mensaje OSPF tiene los si-
guientes campos: versión, tipo del mensaje OSPF, longitud del mensaje, identifica-
tivo del router e identificativo del área.
En la siguiente figura se muestra, como ejemplo, el formato del mensaje de tipo 1
(saludo o hello).
Figura 6.9. Formato de mensaje de saludo (hello) OSPF
168
168
Encaminamiento en
en IP
El mensaje de saludo se utiliza con varios propósitos:
1. Detectar vecinos OSPF y establecer adyacencias.

2. Publicar pautas sobre qué routers deben estar de acuerdo para convertirse en
vecinos.
3. Elegir un router designado (DR) y un router designado de respaldo (BDR) en
redes de accesos múltiples, tal y como se explica más adelante. En dichas re-
des, el DR es el responsable de la actualización de todos los demás routers
OSPF, mientras que un BDR será el router que asumirá las responsabilidades
del DR si este último falla.
Los campos más importantes del mensaje OSPF de saludo son los siguientes:
- Tipo: En este caso toma el valor 1.

- ID del router: Identificativo del router de origen.
- ID del área: Identificativo del área desde la cual se originó el mensaje.
- Máscara de red: Máscara de subred asociada con la interface de envío.
- Intervalo de saludo: cantidad de segundos entre los saludos del router de
envío.
- Router Designado (DR): Identificativo del router del DR, si corresponde.
- Router Designado de Respaldo (BDR): Identificativo del router del BDR, si
corresponde.
- Prioridad del router: Se utiliza en la elección DR/BDR (se analiza más ade-
lante).
- Lista de vecinos: enumera el identificativo del router OSPF de los routers
vecinos.
6.3.2.5. Encapsulamiento OSPF
A diferencia de RIP, cuyos mensajes se encapsulaban en UDP/IP, los mensajes

OSPF se encapsulan directamente sobre IP (indicando en el campo protocolo de la
cabecera del datagrama IP el valor 89, correspondiente a OSPF) y son enviados a
una dirección multicast IP, tal y como se muestra en la figura siguiente.
169
169
Direccionamiento
Figura 6.7. Encapsulamiento de mensajes OSPF en redes Ethernet
6.3.2.6. Temporizadores utilizados en OSPF
En OSPF se definen dos temporizadores:
- Temporizador de intervalo de saludo OSPF (Hello Interval): Generalmente,

se produce un envío multicast (a la dirección 224.0.0.5), cada 30 segundos
(por defecto) para segmentos NBMA.
- Temporizador de intervalo muerto OSPF (Dead Interval): El intervalo
muerto es el que debe transcurrir antes de que el vecino se considere inac-
tivo o desactivado. El valor por defecto es de 4 veces el intervalo de saludo
(120 segundos, por defecto). El temporizador se reinicia cuando se recibe
un paquete de saludo.
Los intervalos de saludo y muertos deben ser los mismos entre vecinos.
6.3.2.7. Adyacencias en OSPF
Como se ha indicado anteriormente, dos routers vecinos adyacentes intercambiarán

paquetes de saludo de forma periódica (según el intervalo de saludo) que servirán
para la monitorización de actividad en el enlace, detectando caídas de los propios
enlaces o de los nodos adyacentes.
170
170
Encaminamiento en
en IP
En algunos casos dos routers vecinos físicamente no forman una adyacencia por
alguno de los siguientes motivos, que deberán subsanarse para evitar males mayo-
res:
- Las máscaras de subred no coinciden, es decir que ambos routers están en

diferentes subredes (por ejemplo, por una mala configuración).
- No coinciden los temporizadores muerto y de saludo de OSPF.
- Los tipos de redes OSPF no coinciden.
- OSPF está mal configurado en alguno de los dos routers.
Las consecuencias directas de la falta de una adyacencia se traducen en que no se

intercambie información del estado de enlace entre nodos OSPF vecinos y que los
árboles SPF y tablas de encaminamiento sean incorrectos, llevando a la posible
aparición de bucles de encaminamiento.
6.3.2.8. Métrica en OSPF
OSPF utiliza el Ancho de Banda (AB) de los enlaces como métrica para determinar
la mejor ruta (de mínimo coste). Para ello, la expresión utilizada es la siguiente:
Coste de un enlace= (AB de referencia)/(AB de la interface)
, tomando un AB de referencia de 108 Mbps, aunque dicho valor puede ser modifi-
cable en algunos routers, ya que las velocidades de los enlaces son cada vez mayo-
res.
El coste de una ruta será el resultado de sumar el coste de cada uno de los enlaces
obtenido según la ecuación anterior.
Los valores de ancho de banda y coste de los enlaces, por defecto, para diferentes
tecnologías y velocidades se muestran en la siguiente tabla:
171
171
Direccionamiento
Tabla 6.5. Métrica en OSPF

Tipo de interface Ancho de Banda Coste
Fast Ethernet y tecno- 8
10 y superiores 1
logías más rápidas
7
Ethernet 10 10
E1 2048 Kbps 48
T1 1544 Kbps 64
-- 128 Kbps 781
-- 64 Kbps 1562
-- 56 kbps 1785
6.3.2.9. Redes de Accesos Múltiples
OSPF define los siguientes cinco tipos de redes:
- Punto a punto.
- Accesos múltiples con broadcast (Broadcast Multiple-Access Net-
work o BMA), como, por ejemplo, una red Ethernet.
- Accesos múltiples sin broadcast (Non-Broadcast Multiple-Access
Network o NBMA) como, por ejemplo, una red Frame-Relay o
ATM.
- Punto a multipunto.
- Enlaces virtuales
En una red punto a punto sólo hay dos dispositivos en la red, uno en cada extremo.
Sin embargo, en una red de accesos múltiples existen más de dos dispositivos en los
mismos medios compartidos (por ejemplo, una LAN). Dichas redes tendrán múlti-
ples adyacencias (n*(n-1)/2, siendo n el número de routers vecinos en la red de
accesos múltiples), y se producirán inundaciones masivas de LSA. Cabe destacar
que por cada LSA que se envía, debe haber un acuse de recibo enviado de vuelta al
router que realizó la transmisión.
Una posible solución al problema que dicha inundación masiva de LSA puede su-
poner a la red es la utilización de un Router Designado (DR) y Router Designado de
Respaldo (BDR)
De esta manera, en vez de inundar la red con LSAs, los routers envían LSAs a una
dirección multicast 224.0.0.6, en la que escuchan tanto el DR como el BDR. El DR
172
172
Encaminamiento en
en IP
reenvía las LSA agrupadas a la dirección multicast 224.0.0.5 en la que escuchan

todos los routers de la red.
6.3.2.10. Proceso de selección de DR/BDR
En las redes punto a punto no se produce selección de DR/BDR. Sólo en las redes
de accesos múltiples.
Los criterios para la selección de DR y BDR serán los siguientes:
1. El DR será el router con la prioridad29 de interface OSPF más alta.

2. El BDR será el router con la segunda prioridad de interface OSPF más alta.
3. Si las prioridades de la interface OSPF son iguales en varios routers, se uti-
liza el identificativo del router más alta para deshacer la igualdad.
Se puede influir en el proceso de selección de DR y BDR, de las 2 formas siguien-

tes:
1. Primero iniciar el DR, después el BDR y luego todos los demás routers.
2. Apagar la interface en todos los routers y, a continuación, activar las inter-
faces en el DR, luego en el BDR y, a continuación, en todos los demás
routers.
Además, también se puede influir en la prioridad de un interface OSPF a través de

la configuración de OSPF. Configurando una prioridad muy baja a un router, dicho
router tendrá pocas posibilidades de ser el DR, y viceversa.
29
Se define una prioridad para cada una de las interfaces de un router que puede participar de varios procesos OSPF. El valor
predeterminado de la prioridad OSPF de una interfaz es 1.
173
173
Direccionamiento
La selección del DR y BDR se produce en los dos casos siguientes:
1. Cuando se habilita la interface del primer router en la red de accesos múlti-

ples.
2. Un DR seleccionado permanecerá como DR hasta que ocurra una de las si-
guientes situaciones:
- El DR falla.
- El proceso OSPF en el DR falla.
- La interface de accesos múltiples en el DR falla.
174
174
Bibliografía
Bibliografía
1. Postel, J. (Ed.), “Internet Protocol”, RFC 791, Defense Advanced Research

Projects Agency, September 1981.
2. Comer, Douglas E., ‘Internetworking with TCP/IP. Vol 1’, 3a edición,
Prentice-Hall, páginas 613, 1995, ISBN 0132169878.
3. Thomas, S. A., “IPng and the TCP/IP Protocols. Implementing the Next
Generation Internet”, Ed. Wiley Computer Publishing, John Wiley & Sons,
Inc., 1996, 481 páginas, ISBN 0471130885.
4. Droms ,R., “Dynamic Host Configuration Protocol”, RFC 2131, IETF
Network Working Group, March 1997, Category: Standards TrackHalsall
F., Comunicación de Datos, Redes de Computadores y sistemas Abiertos,
4ª edición, Addison-Wesley Iberoamericana, 955 páginas, 1998, ISBN
0201653079.
6. Stevens, W., ‘TCP/IP Illustrated, vol 1: The protocols’ addison-Wesley,
EE.UU., 1ª Edición, 576 páginas, 1994, ISBN 0201633469Malkin, G.,
“RIP Version 2”, RFC 2453, Bay Networks , IETF Network Working
Group, November 1998
8. Moy, J., “OSPF Version 2”, RFC 2328, Ascend Communications, Inc.,
IETF Network Working Group, April 1998.
9. Deering, S. and Hinden, R., “Internet Protocol, Version 6 (IPv6) Specifica-
tion (IPv6)”, RFC 2460, IETF Network Working Group, Diciembre 1998.
10. Forouzan, Behrouz A., ‘TCP/IP Protocol Suite’, 2da Edición, McGraw-
Hill, 942 páginas, 2003, ISBN 0072460601
11. Feit, S.,”TCP/IP, Arquitectura, Protocolos, Implementación y Seguridad”,
2ª edición, Mc Graw-Hill, 623 páginas, 2004, ISBN 0070213895.Vachon,
B. and Graziani, R., “Acceso a la WAN, guía de estudio de CCNA Explo-
ration”, Cisco Networking Academy, 2009, 726 páginas, ISBN
9788483224748.Tanenbaum, A. S., Computer networks, 5ª edición, Boston
etc.: Pearson Education, 952 páginas, 2011, ISBN 978013255-3179
175
175

Direccionamiento

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Direccionamiento

Încărcat de

Drepturi de autor:

Formate disponibile

Direccionamiento e

Fernando Boronat Seguí,

Direccionamiento e interconexión de redes basada en TCP/IP

    

Para referenciar esta publicación utilice la siguiente cita: BORONAT, F. y MONAGUD, M.

Primera edición, 2013 (versión impresa)

© de la presente edición: Editorial Universitat Politècnica de València

ISBN: 978-84-9048-037-3 (versión impresa)

Queda prohibida la reproducción, la distribución, la comercialización, la

- ABR: Routers de Borde (fronterizos) de Área (Area Border Routers).

- FTP: File Transfer Protocol.

- NPA: Dirección de Punto de Conexión a la Red (Network Point of Attach-

- TFTP: Trivial File Transfer Protocol.

2.3.2. Interredes IP........................................................................................... 39

Capítulo 4. NAT (Network Address Translation) ................................................. 109

5.7.1. Dual-Stack o doble pila ....................................................................... 142

Capítulo 1. Principios de Interconexión de Redes

El concepto de Interred o InterNetwork (abreviado internet) hace referencia a un

Los sistemas intermedios, también denominados Internetworking Units (IWU), son

SF: Sistemas Finales

Figura 1.1. Interconexión de subredes mediante sistemas intermedios

Figura 1.2. Esquema OSI de una interconexión

1.2. Interconexión a Nivel Físico

Un sistema de interconexión de nivel 1 (nivel físico) será necesario cuando se desee

conectividad física. Conceptualmente es equivalente a que todos los dispositi-

c) Caso de interconexión de dos subredes, aunque sean iguales, cuya conexión

1.3. Interconexión a Nivel de Enlace de Datos

Un sistema de interconexión de nivel 2 (nivel de enlace de datos), como el mostrado

b) Mediante enlace de fibra óptica

Figura 1.5. Solución al problema de cobertura

Figura 1.8. Ejemplo de utilización de un puente

En la figura se muestra el caso de un puente interconectando cuatro segmentos de

1.4.- Interconexión a Nivel de Red

Un sistema de interconexión de nivel 3 (nivel de red ) será necesario será necesario

En la figura 1.10 se muestra el funcionamiento de un router. En ella, además, se

pondiente a la subred por la cual se vaya a enviar (o encaminar), dependiendo de la

Subred 1 (de nivel 3) Subred 2 (de nivel 3)

Figura 1.10. Funcionamiento de un router

Este tipo de interconexión es difícil de implementar y sólo es posible en el caso de

1.5. Interconexión a Nivel de Interred

Cuando se realiza una interconexión a nivel de interred, se deberá añadir un nuevo

El funcionamiento se detalla en la figura 1.12 y es similar al de un router de nivel 3,

1.6. Aspectos a tener en cuenta en la Interconexión de RedesTal y como se

blemente heterogéneas, es decir, de diferentes tipos) debe ser transparente al usuario

Router con N.I. P

C3 CI Datos C3’ CI Datos

... ... ...

N.T. N.T. N.T.

Figura 1.13. Servicio de Red de Interred

A la hora de tratar de interconectar varias subredes independientes para formar una

1.6.1. Servicio de Capa de Red ofrecido al Nivel de Transporte

Existen dos tipos de servicio de capa de red: el servicio No Orientado a la Conexión

En una interred, la sintaxis, el formato y asignación de las direcciones de los Siste-

En una interred existen diferentes subredes interconectadas entre sí a través de sis-

misma subred si conoce su dirección física, utilizando la tecnología de dicha su-

Figura 1.14. Interred formada por 4 subredes

- Un SI debe poder determinar la dirección física de otros SI conectados a

1.6.4. Calidad de servicio o QoS (Quality of Service)

El concepto de Calidad de Servicio (QoS) de la interred se refiere al conjunto de

1.6.5. Tamaño Máximo de PDU

1.6.6. Control de Flujo y Control de la Congestión

1.6.7. Notificación de Errores

Cada tecnología de subred puede disponer o no de mecanismos de notificación de

1.7. Diferentes Soluciones propuestas a la Interconexión de Redes

African Network Information Centre (AfriNIC) para África.