Direccionamiento e Interconexión de Redes Basada en TCPIP IPv4IP

Direccionamiento e interconexión de redes basada en TCP/IP (IPV4/IPV6, DHCP, NAT, Encaminamiento RIP y OSPF) Fernando Boronat Seguí Mario Montagud Climent

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: [email protected] /

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 Protocol).

-

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 conBroadcast ( 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). 3

3

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

4

4

-

FTP: File Transfer Protocol.

-

HLEN: Longitud de la Cabecera o(H eader length ).

-

HTTP: HyperText Transfer Protocol

-

IAB: Junta de Arquitectura de Internet I(nter net Activity Boar d ).

-

IANA: I nter net Assigned Numbe r s Authori ty . IEEE: Instituto de Ingenieros Eléctricos y Electrónicos The ( Institute of Electric and Elec tr onic Engine er s ).

-

IETF: Internet Engineering Task Force .

-

InterNIC: I nter net Netwo rk I nformation Cen tr e .

-

IPSec: Internet Protocol Security.

-

IP v4: I nter net Pr otoco l ver sion 4.

-

IP v6: I nter net Pr otoco l ver sion 6.

-

IRTF: Internet Research Task Force .

-

ISATAP: Intr a-Site Automa tic T unnel A ddr essing Pr otocol .

-

ISO:

-

I nter national Standa r dization Or ganization ISOC: Internet Society .

-

ISP: Proveedores de Acceso a Internet (I nter net Ser vice Pr oviders) .

-

IWU: Unidad de Interconexión (Internetworking Unit ).

-

LACNIC: Lati n Amer ica and Cari bbean Network Infor mation Ce ntre .

-

LAN: Red de Área Local (Local Ar ea Network ).

-

LSA: Publicaciones de Estado de Enlace L( ink State Advert isement ).

-

LSP: Paquete de Estado de Enlace (L ink State Packet ).

-

LSU: Actualización de Estado de Enlace L( i nk State Update ).

-

MILNET: M ili tary Ne two rk .

-

MTU: Unidad Máxima de Transferencia M ( aximun Trans mission U nit ). NAT: Traducción de Direcciones de Red (Network Addr ess Tr anslati on ).

-

NBMA: Red de Acceso Múltiple sin Broadcast (Non-Broadcast MultipleAccess Networ k ).

-

NCC: Networ k Coordination Centre .

.

Acrónimos Acrónimos

-

NPA: Dirección de Punto de Conexión a la Red ( Network Point of Attachment ).

-

NSAP: Punto de Acceso al Servicio de Red (Network Service Access

Point). -

NSF: Nati onal Sc ience Foundation .

-

NSP: Proveedor de Servicio de Red (Network Ser vice Pr ovider ). OSI: Interconexión de Sistemas Abiertos (Open Systems Int er connection ).

-

OSPF: Open Shor test P ath F ir st.

-

PA: Point of At tachment .

-

PAT: Traducción de Direcciones de Puerto ( Port Address Translation ).

-

PDA: Asistente Personal Digital (Personal Digital Assistant ).

-

PDU: Unidad de Datos de Protocolo ( Protoc ol D ata Unit ).

-

PLP: X.25 Packe t L ayer Pr otocol .

-

QoS: Calidad de Servicio (Quality of Service ).

-

RARP: Protocolo de Resolución de Direcciones Inverso (Reverse Address

-

Resoluti on Pr otocol ). RDSI-BE: Red Digital de Servicios Integrados de Banda Estrecha.

-

RFC: Request F or Comments .

-

RIP: Routing Internet Protocol .

-

RIPE: Réseaux IP Européens

-

RIR: Regional I nternet R egistry .

-

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 Mai l Tr ansfer Pr otoco l .

-

ST: Tipo de Servicio (Servi ce Type ).

-

TCP: Transmission Control Protocol

.

5

5

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

6

6

-

TFTP: Trivial File Transfer Protocol

.

-

TS: Tipo de Servicio (Type of Servi ce).

-

UDP: U ser D atagram Protocol .

-

VLSM: Máscara de Subred de Longitud Variable V( ariable Length Subnetwork Mask ).

-

VPN: Red Privada Virtual (Vir tual Pri vate Network ).

-

WAN: Red de Área Amplia (Wide Area Network ).

-

WINS: Windows I nternet Naming Ser vice.

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

7

7

Direccionamiento e interconexión de redes basada en TCP/IP 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 (I nter net Contr ol M essage 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 (D ynamic H ost Configurati on 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

8

8

Í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

9

9

Direccionamiento e interconexión de redes basada en TCP/IP 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 Shor test Path F ir st ) .............. 161 6.3.1. Protocolos de estado del enlace ........................................................... 161 6.3.2. Funcionamiento del Protocolo OSPF .................................................. 162 Bibliografía ............................................................................................................ 175

10

10

Pr inci pios de Int erconexión de Redes

Capítulo 1. Principios de I nter conexió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-,que etc.), denominadas , interconectadas sí formando una reda subredesentre global permite la comunicación los diferentesentre dispositivos conectados cualquiera de dichas subredes. Las diferentes subredes que forman la interred pueden ser muy heterogéneas. Pueden estar basadas en el uso de la misma o distinta tecnología. Pueden utilizar medios 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, Ethernet 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 ( M aximun Trans mission U nit ) 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 direccionamiento 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 diferentes 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 heterogeneidad 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 e interconexión redes basada en TCP/IP Pr in cipi os de In terconexión de Rede des

Los sistemas intermedios, también denominados Inte rnet working U nit s (IWU), son sistemas auxiliares que interconectan subredes y que no incluirán necesariamente todos los niveles de la arquitectura OSI (Open System Interconnection ). Normalmente incluirán, como máximo, hasta la capa 3, aunque pueden incluir capas superiores o funcionalidades de las mismas. Pueden ser desde simples conectores o adaptadores de medios hasta encaminadores o routers muy complejos.

SI 1 -

SI 2 SI 4 Subredes

SI 5

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. ‘

’

’ N3 N2

N3’ N2

N2’

Figura 1.2. Esquema OSI de una interconexión

12

12

N2’

Capítulo Principios 1. Principios de interconexión de redes de Interconexión de 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 inte r r ed . 1.2. I nter conexió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 realizará funciones de pasarela entre, al menos, ambos niveles físicos, tal y como se muestra en la figura 1.3.

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 pasivos. 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 diferentes (cable coaxial y cable de pares). b) Conexión de dos segmentos de red Eth ernet, ambos con cabl e de par tr enzado . 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 dispositivo de red se conecta a un puerto del hub , con lo que éste les proporciona

13

13


conectividad física. Conceptualmente es equivalente a que todos los dispositivos estuvieran conectados al mismo medio. Los dos ejemplos a y b se reflejan en la figura 1.4. SF 1 Coaxial

HUB

… 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 subredes, 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 mediante 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. I nter conexió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

Capítulo Principios 1. Principios de interconexión redes de Interconexión de de Redes Radioenlace Rep Re

HUB

HUB

a) Mediante radioenlace

Enlace de f.o. HUB

b) Mediante enlace de fibra óptica Figura 1.5. Solución al problema de cobertura

N1

N1

SI Figura 1.6. Interconexión a Nivel de Enlace de Datos o de capa 2

15

15

Direccionamiento e interconexión de redes basada en TCP/IP Principios de Interconexión 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 o B rid e

Memoria

osa

osa

Toen-R ng

Eternet Figura 1.7. Funcionamiento de un puente o bridge

Supongamos que llega una trama por el puerto Token-Ring del puente. El procesador 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 datos 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 e xisten conmutadores que trabajan a diferentes niveles.

16

16

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

de dicha trama con los datos srcinales (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 srcen será la del equipo que generó la trama srcinal 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 subredes muy parecidas (como Ethernet y Token-Ring, por ejemplo), normalmente subredes 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 distintos, 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 denominados segmentos (por ejemplo, Ethernet), con el fin de obtener mayor privacidad (figura 1.8).

HUB

HUB

HUB

HUB

Figura 1.8. Ejemplo de utilización de un puente

17

17


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 cualquier 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 interconectar los segmentos, ya que éstos son meros repetidores). 1.4.- Inter conexió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 independencia de si los niveles inferiores son iguales o no. En este caso, se utilizan sistemas intermedios de capa 3, y se suelen denominar routers 2, encaminadores o enrutadores.

’

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 Protoco l 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, eliminará 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 paquete (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 pasquete recibido y se generará una cabecera de la tecnología de nivel 3 (C3’) corre

2

18

18

Normalmente para referirse a este tipo de dispositivos se utiliza la palabra inglesa router.


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). Endel este caso, enellaque cabecera la dicha dirección de nivel 2 de srcen será la del puerto router por se va aC2’, enviar trama.

ou er

Memoria ’ C2

C3

Datos

C2’

C3’D

atos

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. I nter conexió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


…

…

N4

N4’

NI

NI’

N3

’

N3’

N2

’

N2’

N1’

N1’

N1

N1

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 cabeceras (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 protocolos, pues se trata de siempre del mismo protocolo de nivel de interred . Las cabeceras 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 desencapsulamiento 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.

Tal y como se 1.6. Aspectos a tener en cuenta en la Inter conexión de Redes 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áctica son las entidades de protocolo de nivel de transporte, la interred debería proporcionar 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


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 (Quali ty of Se r vice ).

-

Tamaño máximo de PDU.

-

Control de flujo y control de la congestión.

-

Notificación de errores.

1.6.1. Servici o de Capa de Red of r ecido al N ivel de Tr ansporte 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 O r iented 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 empleará en la interface de la interred con cada una de las estaciones finales o usuarios. 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. Di reccionami ento En una interred , la sintaxis, el formato y asignación de las direcciones de los Sistemas Finales y los Sistemas Intermedios difieren según la subred a la que se conecten. Cada tecnología dispone de un sistema de direccionamiento propio bien definido 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


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 encaminar 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á alcance 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. E ncaminami ento

En una interred existen diferentes subredes interconectadas entre sí a través de sistemas 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 separado. 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 perteneciente a la misma subred que el sistema final de srcen. Podría perfectamente referirse 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, consideramos 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, recordemos 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


misma subred si conoce su dirección física, utilizando la tecnología de dicha subred. 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 simple 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 2

SI 2 SI 4

u re

Subred 4

3

SI 5

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:

24

24

-

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.


-

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. Cal idad de ser vici o o QoS (Qu al ity of Ser vice) 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 establecimiento de la llamada virtual, mientras que en subredes con servicio C.L. no se negocia nada y el sistema debe conocer la QoS que le proporciona la red. En una interred 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 conocimiento 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 entidades del nivel de transporte) espera del proveedor de dicho servicio (NSP o Networ k Ser vice Provi der ) 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 información útil al destino especificado; el nivel de protección requerido contra una vigilancia 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 conexión, tiene lugar una negociación par a par entre los dos usuarios del nivel de red. El usuario srcen especifica los parámetros de QoS que espera y el destino modifica, 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 subyacente.

25

25


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 conocimiento 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 áxi mo 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)

-

Retardo de tránsito . A mayor tamaño máximo de las PDUs, mayor tiempo

. 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. 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 capacidad se necesitara en los buffers requeridos para su almacenamiento.

-

Gastos extr a de pr ocesamiento . A menor tamaño, mayor será el número de PDUs necesarias para enviar cada bloque de información, con el consecuente 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 conocido, 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 segmentación (fragmentación) y re-ensamblado necesarias. Mediante usolade la primera alternativa algunas redes se vuelven ineficientes, mientras queelcon segunda alternativa la capa de red debe realizar una función adicional. Por tanto, se presentan varias opciones: que el protocolo de transporte segmente al mínimo de los tamaños máximos de PDUs de subred o bien disponer en la capa de red de las estaciones y de los SI, de mecanismos de segmentación y re-ensamblado.

26

26


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 relacionadas con una sola conexión entre dos sistemas, así como tratar de resolver la diferencia entre la velocidad con que un Sistema Final de srcen transmite PDUs y la velocidad con la que el Sistema Final de destino puede aceptarlas. Si el SF de destino puede aceptar PDUs con mayor rapidez de lo que el SF de srcen puede enviarlos, 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 tomando 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 similar, a nivel más local, si las PDUs llegan a un nodo de la red – un SI, por ejemplocon 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 ejemplo 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 transporte del srcen nuevos datos a la red. De nuevo, aunquedeeste mecanismo ayuda dejarán a aliviarde la enviar 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


1.6.7. Notif icación de Er rores 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 mecanismo de notificación extensible y compatible con el de las distintas subredes que la compongan.

1.7. Difer entes Soluciones pr opuestas a la Inter conexió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 solucionar el problema de interconexión de redes heterogéneas, planteadas por parte de ISO (I nter national Standa r dization Or ganization ) e IAB (I nter net Activity Board ).

1.7.1. Solu ción pr opuesta por I SO (I nternati onal Standardization Or gani zation) 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 transparencia el encaminamiento y todas las demás funciones relacionadas con la retransmisió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 protocolos (de subcapa), que en la terminología de ISO toman los siguientes nombres:

28

28

-

Protocolo de convergencia independiente de la subred (SNICP, Subnetwork Independent Convergence Protocol ).

-

Protocolo de convergencia dependiente de la subred (SNDCP, S ubnetwork Dependent Convergence Protocol ).


-

Protocolo de acceso dependiente de la subred (SNDAP, Subnetwork Dependent Access Pr otocol ).

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.

. .

. .

... T.

... . .

N.

T.

N.

Encaminamiento Retransmisión

SNDCP

SNDCP SNDCP’

SNDCP

SNDAP

SNDAP SNDAP’

SNDAP

N.E.D

N.E.D

N.F.

N.F.

N.E.D’ N.F.

N.E.D N.F.

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 (entidades de transporte residentes en sistemas finales remotos). Su función consiste en realizar las diversas funciones de armonización (convergencia) que pueden ser necesarias 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


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 PL P ) 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 dependiente 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 propue sta por el I AB (I nter net Acti vity 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 publican sus logros en los documentos RFC ( Request F or Comments ). El I nter net Ar chite cture Board o IAB (Junta de Arquitectura de Internet) es el organismo encargado de aprobar si una RFC se convierte en estándar de internet (Internet 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 propuesta 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 Subcapa Independiente de la Subred (cuyo protocolo es SNICP). Ofrece un servicio sin conexión, pero nono sigue la definición OSI del servicio CL. Estáprincipalmente diseñado para ofrecer un servicio fiable a los protocolos de transporte, TCP (Tr ansmission Control Pr otoc ol ) y UDP (U ser D atagram Protocol ). Además, también existen otras RFCs en las que se dan instrucciones de implementación de las funciones que ISO ha incorporado posteriormente en la Subcapa Dependiente de la Subred (cuyo protocolo es SNDCP), como, por ejemplo, la

30

30


RFC948, que define el Estándar par a l a tr ansmisión de datagramas IP sobre r edes IEEE 802. 3 .

31

31

La F amilia de Protocolos TCP/IP

Capítulo 2. La familia de Protocolos TCP/IP 2.1. Introducción

El concepto de la red Internet 3, 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 de de manera que los usuarios conectados a dichas redes puedan hacer usoy servicios, de servicios información y comunicación de alcance mundial.

2.1.1. Br eve hi stor ia de I nt er net

Internet surgió a partir de un proyecto de la agencia estadounidense ARPAAdvan( ced Resear ch and P r oj ects Agency ) con el objetivo de conectar las computadoras de sus departamentos de investigación mediante la técnica de conmutación de paquetes. 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 fueactividad puesto ade disposición de ladurante comunidad investigadora, que resultó en unainicial intensa investigación la década de los 70,locuyo 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 protocolos 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 época 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 ARPANET. En 1983, la Agencia de Comunicación de Defensa (Defense Communication Agency 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 e interconexión La F amilia de Protoc olos TCP /IPde 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 conocida como NSFNET, que, a su vez, en 1986, fue conectada a ARPANET. El conjunto de todas las computadoras y redes conectadas a esos dos backbones (redes principales) pasó a ser conocido ya oficialmente como la Internet Global (la Internet, 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 privadas como IBM, MCI (empresa de telecomunicaciones) y MERIT (institución responsable de una red de computadoras de instituciones educacionales de Michigan), 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 (D efense Resear ch I nter net ). En 1991-92, la ANS desarrolló un nuevo backbone , 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 acadé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 computadoras 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 I nternet

Tanto la Administración la operación de Internet descentralizadas,y exceptuando algunas tareas,cuanto tales como la coordinación de son las investigaciones está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. F Laamilia familia protocolosTCP/IP TCP/IP dedeProtocolos

Las principales instituciones responsables por esas tareas son: 



The Internet Society (ISOC). Sociedad que, a través de foros, debates y publicaciones, procura orientar la investigación y utilización de Internet. The Interne t Ar chite cture Board (IAB o Junta de Arquitectura de Internet). Fundado en 1983 como Internet Activities Board e integrado en la Internet 1992. Guíainvolucrados la evoluciónen deelInternet, coordinando toda la invesSociety tigaciónen y desarrollo funcionamiento de Internet. Coordina los grupos de trabajo, como por ejemplo, los grupos de investigadores voluntarios IETF e IRTF , que se presentan a continuación.





The I nter net Resear ch Task For ce (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.



(InterNIC). Originalmente comThe Internet Information Center puesto por 3 Network instituciones (AT&T, PSI y General Atomics) y sus objetivos consisten en centralizar la distribución de informaciones de la Internet Society (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 California, que controla la distribución de identificadores para servicios que serán suministrados vía Internet. Las direcciones IP que se utilizan en Internet son asignadas por esta autoridad central. No obstante, cuando una organización se une a Internet, puede obtener direcciones de red del Regional Internet Registry (RIR) de su región. En la zona de Europa el registro 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 aorganización determinará, ciones cada estación de su red. de forma interna, cómo asignar las direcUn RIR es una organización que gestiona la asignación y registro de recursos 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




Afri can Ne twork I nformation Ce ntre (AfriNIC) para África.



American Registry for Internet Numbers



Asia-Pacific Network Information Centre

(ARIN) para los Estados Unidos, Canadá y ciertas zonas del Caribe y la Antártida. (APNIC) para Asia, Aus-

tralia, Nueva Zelanda y países vecinos. 



Latin America and Caribbean Network Information Centre

NIC) para Latinoamérica y otras zonas del Caribe.

Réseaux IP Européens Network Coordination Centre

(LAC-

(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. Ar quitectur a TCP/I P

La pila de protocolos TCP/IP es el primer conjunto de protocolos que soporta completamente 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 nombre, 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 coincidencias, 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 deinterred . El servicio que se da a niveles superiores es, por tanto, independiente de la tecnologí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 conexión (CL o ConnectionLess ). Su finalidad esencial es ocultar la heterogeneidad de subredes, ofreciendo un servicio deinterred independiente de ellas.

36

36

CapítuloLa 2. La familia protocolos TCP/IP Familia de de Protocolos TCP/IP

Ejemplos de

Ar uitectura TCP/IP

FTP, TELNET, SMTP, , , .

A licación

Equivalente en el

Niveles 5 a 7

,

IP, ICMP, ARP, RARP Ethernet, 802.3, 802.5, FDDI, X.25, ATM, etc.

Niveles 1, 2 y, en algunas 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 conexión y cumple perfectamente con los requisitos de fiabilidad. Su principal inconveniente es su complejidad. UDP (User Datagr am Protoco l ): Ofrece un servicio no orientado a la conexió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 protocolos TCP/IP es la siguiente: 





A los sistemas finales se les denomina Hosts . Las PDUs (Protoc o Unidades ol D ata Units vel de se denominan . datos del Protocolo) del niinterred Datagramas IP de A las PDUs de nivel de transporte se las denomina segmentos.

37

37

Direccionamiento e interconexión La F amili a de Protoc olos TCP /IPde redes basada en TCP/IP

2.3. Nivel deInterred . 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 utilizada en Internet. Su normalización corre a cargo del IETF. En este capítulo se presenta 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. Servici o de Red ofr ecido por I P 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 conexió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 finales 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 tamañ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

38

38

En algunos libros de la b ibliografía se traduce el término ‘best-effort ’ como ‘de buenas intenciones’.

CapítuloLa 2. Famil La familia protocolosT TCP/IP ia dede P rotocolos CP/I P

2.3.2. I nterr edes I P

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 subred 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 pr otocolos de con ver gencia . ‘

’

2.3.2.1. M odo de oper ación I P 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 direccionamiento IP completa, formando un datagrama IP. Dicho datagrama es transmitido encapsulado en una PDU de subred (trama o paquete, dependiendo de si la tecnologí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 continuación se presenta un ejemplo de cada uno de los dos tipos. Ejemplo 1 de IP sobre tec nología de subr ed que ofrez ca un ser vi cio no or ientado 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 contenido de la dirección IP de destino en la cabecera del datagrama IP.

39

39

Direccionamiento e interconexión La Famil ia de Protoc olos T CP/IPde redes basada en TCP/IP

Gráficamente:

IP

IP

Ethernet HETH

DatosETH

Trama Et ernet 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 IP

HX.25

a osIP

DatosX.25

a agrama

Paquete X.25

RFC 1356

.

apas 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 2. La familia protocolos TCP/IP Familia dede Protocolos 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

Router

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 extremos:

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 paquete/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 encapsulará en tramas Ethernet dirigidas a SF2. 4. El CV quedará establecido durante un tiempo para otros envíos de información posteriores, tanto en un sentido como en el otro.

41

41

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

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

P

Router

X.25

SF2

thernet

Cabecera IP

Data. Req

Datos

. onn. n del CV

Con n. Con f

Conn. Resp

Cabecera X.25

Data. ReqX.25

Cabecera IP

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 preocuparse 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 Decidirá siguiente al que el le deberá enviar el datagrama es unIP. nodo de unaque redel X.25 (SF 1),nodo utilizando 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


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 información posteriores tanto en un sentido como en el otro.

6.

Transcurrido un tiempo (predefinido) sin envíos el CV se liberará.

.

Cabecera Ethernet Cabecera IP

Data. ReqETH Datos

Conn. Re Conn. Ind sa

ecme no 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 I P

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


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 32 utilización de unos 4.000 millones de direcciones diferentes (2 ), aproximadamente. 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 identifica 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 pueden 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ínimo, 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 7 24 (2 , 128 redes de clase A) y los últimos 24 indican el HostId (2 , 16777216 posibles combinaciones, algunas de ellas reservadas). Véase la figura 2.8.



32 bits ango:

0

NetId (128)

HostId (16777216)

0.0.0.0 a .

.

.

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 (normalmente se asignan a redes de operadores o backbones ). No interesa, sin embargo,

44

44

CapítuloLa 2. F Laamil familia protocolos TCP/IP ia dede Protoco los TCP/IP

para pequeñas redes locales con pocos equipos, pues se desperdiciarían multitud de direcciones.

Clase B: En esta clase, los dos primeros bits son ‘10’, los siguientes 14 bits 14 indican el NetId (2 , 16384 redes de clase B), y los próximos 16 son elHostId



16

(2 , 65536 figura 2.9. posibles combinaciones, de las cuales 2 están reservadas). Véase la 32 bits

10

128.0.0.0 a HostId(65536)

NetId (16384)

.

.

.

Figura 2.9. Direcciones IP de Clase B

•

Clase C: Los primeros tres bits son ‘110’, los siguientes 21 bits indican el 21 8 NetId (2 , 2097152 redes de clase C), y los últimos 8 son el HostId (2 , 256 posibles combinaciones, de las cuales 2 están reservadas). Véase la figura 2.10. 32

ts

Ran o: ... 223.255.255.255

Figura 2.10. Direcciones IP de Clase C

Esta clase de direcciones está pensada para subredes pequeñas con pocos equipos (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 grupomulticast 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 necesario tener que generar un datagrama para cada destinatario con cada direcció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


32 bits

Rango:

... 239.255.255.255

Figura 2.11. Direcciones IP de Clase D

•

Clase E: Esta clase está reservada para posibles usos futuros. Rango:

1111

Reservado

240.0.0.0 a 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úmeros 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, considerá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:

46

46



Clase A: 10.1.2.3



Clase B: 138.4.3.59



Clase C: 192.16.192.1



Clase D: 224.1.1.10

CapítuloLa 2. Famil La familia protocolos TCP/IP ia dede Protoco los TCP/I P

Las empresas u organismos que necesiten de direcciones IP válidas, deberán solicitar 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 Registro RIR Europeo, el Réseaux IP Européennes (RIPE).

2.3.3.1. D ir ecciones IP Especial es 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 utiliza 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 hacer un envío masivo, a diferencia de la anterior que puede ser utilizada desde 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 encaminar estas direcciones IP hacia la Internet Global): -

5

1 rango completo de direcciones Clase A (10.0.0.0/8) 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


-

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 I P 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 definitivamente este problema se hace uso de los denominados nombres IP . Consiste en asignar a los sistemas nombres con significado comprensible para el usuario (normalmente, 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


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 deducir 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 principal www (normalmente indica que contiene el servicio web o, dicho de otra manera, que es un equipo con funciones de servidor web) y que incluirá más subdominios, 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 deun 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 Cabecer a (Header length o HL EN): 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


(correspondiente a la longitud de las 5 palabras de 32 bits que contienen los campos obligatorios de la cabecera).

Versión

HLEN

TS

Longitud Total

ro oco o Dirección de srcen

Cabecera

ec sum

Cam o de Datos

Figura 2.13. Formato del Datagrama IPv4

•

Campo T ip o de Ser vicio (

o T S): Es el campo donde se indica Type para of Service la calidad de servicio requerida 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

PRIORIDAD

3

4

5

D

T

R

Figura 2.14. Campo Tipo de Servicio

50

50

6

7

Sin uso


donde tenemos los siguientes sub-campos: -

Bits 0 a 2 (de prioridad): Se utiliza en casos de congestión. Indica la importancia del datagrama. (Valor 0: datagrama normal; valor 7: datagrama de control). Se utiliza para permitir que la información de control tenga preferencia sobre la de datos.

-

Bit 3 (D o Delay ): Dar prioridad al retardo. Si está activado es que se requiere 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 cumplimiento 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 Bits 0 a 2 (bits de prioridad)

Bit 3 (Delay , D) Bit 4 (Throughput , T) Bit 5 (Reliability , R) Bits 6 y 7

Valor Desde 0 Prioridad normal hasta 7 Prioridad más alta (control de red). 0 para retardo normal 1 para bajo retardo 0 para throughput normal 1 para alto throughput 0 para fiabilidad normal 1 para alta fiabilidad 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 Puede que rutas que sí existen hacia ellosdestino puedan cumplir de conlalored. solicitado. Enlas caso de que lo cumplan, routersno intentarán seleccionar aquella ruta, de entre todas las posibles, que cumpla con la solicitud del srcinador 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 by16 tes (2 ). Datagramas de tal longitud no son prácticos para la mayoría de hosts y

51

51


subredes. Según la RFC 791, todos los hosts deben estar preparados para aceptar 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 r e-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 tiene un valor aproximado de 1500 bytes y en Token-Ring de unos 4440 bytes. Este valor máximo es la MTU ( M aximum Transfer Unit ). Si el datagrama no cabe en dicha PDU se ha de descomponer en trozos más pequeñ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 cabecera 6 + 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

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 cabecera y un máximo de 800 octetos en el campo de datos. Por tanto, se tomará el campo de datos del datagrama srcinal de 2000 octetos y se dividirá en bloques 6

52

52

Suponemos cabeceras de longitud mínima, con sólo los campos obligatorios.


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 datagrama 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 deberá de indicar de algún modo que forman parte de dicho datagrama srcinal para que en el destino se puedan reordenar los fragmentos y reconstruir el bloque de 2000 octetos del datagrama srcinal. 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

20

800

400

Figura 2.16. Datagrama srcinal 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 reensamblado son los 3 siguientes: -

I dentif icador : Consiste en un identificador del datagrama, asignado por el

srcinador del mismo. Cuando un datagrama se segmenta, el valor de este campo se copiará en el campo identificador de todos los datagramas generados en dicho proceso. Será el mismo para todos los datagramas generados al segmentar, e igual al del datagrama srcinal. Junto con la dirección IP de srcen identifican al datagrama srcinal como un todo (no se identifica 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 srcinal. 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 srcinal, para facilitar, así, el re-ensamblado en el receptor. El primer fragmento tiene un offset de 0 bytes.

53

53


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:

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 protocolo ICMP que se explica más adelante en este capítulo) al srcinador del datagrama descartado.

•

Bit 2 (bit MF): si vale ‘0’, el datagramacontiene el último fragmento o bloque de datos de un datagrama srcinal segmentado (Last Fragment ). Si vale ‘1’ el datagrama contiene un fragmento o bloque de datos de un datagrama srcinal que no es el de la última posición (M ore Fr agments). Una vez ha llegado el último bloque o fragmento, el destino podrá saber la longitud total del datagrama srcinal 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 último fragmento más la longitud del bloque de datos de dicho último 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


Offset del

se

e º ragmen o ytes = º y es =

Figura 2.18. Segmentación y Re-ensamblado

Por tanto, si suponemos un identificador de 50 en el datagrama srcinal, los campos de segmentación y re-ensamblado de cada datagrama generado serían los siguientes: en =

20

800

=‘ ’ =‘ ’

Ident = 50 set = = =‘ ’

Ident = 50 Offset = 200 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 srcinal. Los fragmentos sólo se re-ensamblarán en el destino del datagrama srcinal que no se puede asegurar que pasen todos independiente ellos por un mismo equipos de ya interconexión, ya que se encaminan de forma 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, desordenados. 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


fragmentos se descartan los que sí se hayan recibido y se hará uso de un protocolo 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 (Ti me To Li ve ). 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 descartado. El propósito de este campo es que los datagramas que no puedan ser entregados a su destino sean descartados, limitando el máximo tiempo de permanencia del datagrama en la red IP.

•

Campo Pr otocolo: 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 correspondientes a cada protocolo están definidos en la RFC 790.

•

Campo Checksum : Es el resultado de aplicar un código de protección de errores a la cabecera con los bits del campo checksum puestos a cero. Normalmente, 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 Dir ecciones IP de origen y destino: Son de 32 bits cada uno y contienen la dirección IP del srcen y del destinatario del datagrama, respectivamente.

•

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 datagrama copian en este campo su dirección de forma acumulativa. Ya que como máximo este campo puede tener 40 octetos, sólo se podrían registrar hasta 10 direcciones (de 4 bytes cada una).

56

56

•

Campo de Relleno:En caso de que el campo de opciones no tenga una longitud exacta en cuanto a palabras de 32 bits se refiere, se utilizará relleno ( padding ).

•

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 Longi tud de la Cabe cer a (ambos en bytes).


2.4. I CM P (I nternet 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 ningú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 srcen de dicho 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. a ece ra

Datos ICMP

Datos Datagrama 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 producirse 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 funciones.

57

57

La Famili a de Protoc olos TCP /IP

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

2.4.2. Tipos de mensajes I CM P Existen dos tipos principales de mensajes ICMP: los mensajes de error y los mensajes 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:

po

Código

Checksum

a os pc ona es 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 opcional es: algunos mensajes ICMP incluyen información importante en este campo (tal y como se explica para uno de los mensajes estudiados posteriormente).

58

58


Entre otros, se pueden destacar los siguientes tipos de mensajes ICMP de error: 1.

Destino inalcanzable o D estinati on U nreac hable ( 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 encaminamiento).

2.

•

'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 cortafuegos (firewall ).

•

‘4’ (Fragmentación needed and DF set ). Error que ocurre porque el datagrama ha llegado a un router que necesita fragmentarlo para poder reenviarlo pero no puede por tener el bit ‘do not fr agment ’ activado.

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 descartado los fragmentos que sí habían llegado, generándose un mensaje de error de este tipo). En la parte opcional de un mensaje de notificación de un determinado error, se incluye la cabecera IP y los primeros 64 bits (que, probablemente, contendrán la cabecera del nivel de transporte) del datagrama que se descartó. De esta manera, al

59

59


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):

po

u

Código (0)

Identificador

Checksum 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 tr ace r oute , 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 basadasen el uso demensajes I CMP 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 tr ace r oute .

60

60

CapítuloLa 2. F Laamil familia protocolosTCP/IP TCP/IP ia dede Protocolos

2.4.3.1. Utilidad de comprobación de alcanzabili to.

dad y estado de un sistema remo-

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 determinado. Una vez que el destino devuelve el Echo Repl y correspondiente, se concluye que el destino es perfectamente alcanzable, es decir que se puede tener una comunicació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 IP D .

IPA

IP

IP

IP

Figura 2.23. Envío del mensaje Echo Request

Realmente, al ejecutar el comando, se envían 4 paquetes ICMP de tipo Echo Request, encapsulados en un datagrama IP enviado a la dirección IP de D (IP D), y cada uno con un identificador y un número de secuencia consecutivo.

0

8 en

16

ca or

31 m ecuenc a

a os pc ona es 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 datagrama independiente enviado a la dirección IP de A (IP A).

61

61

Direccionamiento e interconexión La Famil ia de Protocolos TCP/IPde redes basada en TCP/IP

B

IP

B

C C

D D

Figura 2.25. Envío del mensaje Echo Reply

El formato del mensaje Echo Reply es el siguiente:

I ent ca or X

N m Secuenc a Y a os pc ona es

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


2.4.3.2. Utilidad

de traz abil idad de r utas (Tr ace r oute)

En la mayoría de sistemas el comando que utilizan los usuarios es el comando tracert . Esta utilidad permite obtener la ruta más probable que siguen los paquetes IP desde un srcen IP a un destino IP. Es decir, devuelve una lista con los routers intermedios existentes entre los dos equipos. Si se detecta falta de conectividad entre equipo srcen destino IP, tracert ayuda a detectar a partir de qué router se produce el error. Los mensajes ICMP enviados son los siguientes: el equipo srcen envía un mensaje ICMP Echo Request (tipo 8, código 0) encapsulado en un datagrama con dirección IP srcen 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 responderá con un mensaje ICMP Echo Reply (tipo 0, código 0) dirigido al equipo srcen. El procedimiento seguido para obtener la dirección de los routers intermedios consiste en forzar un mensaje de error en dichos routers, que éstos enviarán al equipo srcen en un datagrama con dirección de srcen la de dichos routers (de dicho datagrama se obtendrá la dirección de cada router intermedio). Para ello, se forzará a que el TTL de los datagramas enviados desde el srcen 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á forzosamente 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 srcen de dicho datagrama). De esta manera, en este primer paso se ha obtenido la dirección IP del primer router. A continuación se repite el proceso: se envía otro Echo Request , encapsulado 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 Repl y 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


A continuación se muestra el resultado de ejecutar el comando tracert en una ventana 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 mensajesI CMP 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 fiabilidad o protección frente a errores, no se puede afirmar que se asegure fiabilidad total.

2.5. Envío de información en I P

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 generados por laenmisma fuente.figura: Existen dos tipos de envíoe de información que se esquematizan la siguiente Transmisión Directa Indirecta.

64

64


IP

B

MACB

A

Origen y destino en una misma red A

MAC TRANSMISI N INDIRECTA

R

B Router

IP2R

R

MAC

Red IP 2

r gen y es no en re es s n as 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 srcen 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.

IP

B A

MACB

Figura 2.30. Transmisión Directa

65

65


El equipo A conoce las direcciones IP srcen (IP A) y destino (IP B) y las incluye en la cabecera IP del datagrama que envía. Además, también conoce su propia dirección física o MAC (MAC A). 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 datagrama y enviarlo en una trama de nivel 2 necesita conocer la dirección física MAC B (destino al que enviar la trama). Para ello se necesitará un mecanismo de resolución B de direcciones le proporcione partir de la IP B conocida (por ejemplo, mediante elque protocolo ARP quelaseMAC explicaa más adelante).

El procedimiento es el mostrado en la figura siguiente: IP

B

MACB

A

es MACB

rg po MACA 800

es IPB

rg IPA

…

Datos

Cola

Capa 2: Trama Ethernet

Figura 2.31. Encapsulamiento en una Transmisión Directa

7

2.5.2. Entr ega o Tr ansmi sión i ndi r ecta 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 srcen 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 srcen y destino del datagrama enviado no cambian en todo su trayecto entre el host srcen y el host destino. Por otro lado, las direcciones físicas de srcen 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 2. F Laamilia familia protocolosTCP/IP TCP/IP dede Protocolos

sí que cambian a medida que la información (el datagrama) se reenvía de un dispositivo 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 datagrama. 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 R

R

B Router

MAC2R

IP2R B

R ed I P 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+ SubnetI d ) 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 srcen la suya propia (MAC A) 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 IP y, tal como se explica más adelante, buscará en su tabla B 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 directamente, 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


4.

El router encapsula el datagrama IP en una nueva trama Ethernet con dirección srcen la MAC2 R del interface de salida del router en la red 2 y dirección destino la MAC del equipo Host B (MAC B), y la envía a través de la interface de la red IP 2.

IP MAC R

R

IPB Router

MAC2 Capa 2: Trama Ethernet

B

apa

:

a agrama

… R

A

B

Datos

Cola

A

a) Pasos 1 y 2

A

e A

MAC1R

IP1R

IP Router

R

R

MAC

Red IP 2

Capa 2: Trama Ethernet apa

:

a agrama

… B

R

B

Datos

Cola

A

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 srcen y destino) de router a router, encapsulado en tramas Ethernet, con las direcciones MAC srcen y destino cambiando en cada paso, tal como se muestra en la figura 2.34.

68

68


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 indirectamente (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 direcció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 obstante, este tipo de entradas en la tabla las suelen especificar los administradores 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 aquellos datagramas cuya dirección de destino no coincida o no se encuentre dentro de las direcciones anteriores. Se usa, normalmente, en aquellas subredes 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 contrario, en caso de existir, la decisión de encaminamiento siempre se decantaría por la ruta por defecto, etc.).

70

70


recc ones e S stema Direcciones de Subred

recc ones IP Destino

Direcciones IP Si uiente Nodo

158.20.100.2 158.20.100.3 …

158.20.100.2 158.20.100.3 …

. . . 158.20.300.0 158.20.400.0 … . . .

. . . 158.20.100.1 158.20.100.1 … . . .

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 subredes 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 siguiente nodo). RED . . . .2.2

.2.1 INTERNET

.1.2 Router

. . 192.168.3.0

RED 192.168.1.0

. . .1 . 3

.1.4

. 3 .1

Router

.4.3

. .

Router

. .

.4.4 192.168.4.0

. . Router

. .

Router

.6.1

192.168.5.0 .5.3

192,168.6.0 . .

Figura 2.36. Escenario IP

71

71


En el ejemplo de la figura 2.36, la tabla de encaminamiento del router central (dentro de un círculo con línea de puntos) sería:

est no

recc ones Siguiente Nodo

recc ones e stema

192.168.1.1 192.168.1.2 192.168.1.3 . . . . . .

192.168.1.1 192.168.1.2 192.168.1.3 . . . . . .

e u re

. . . . . . 192.168.4.0 192.168.6.0

. . . . . . 192.168.5.1 192.168.5.1

Ruta por defecto

0.0.0.0

192.168.1.1

Figura 2.37. Tabla de Encaminamiento del router central

Nótese que, si del se quiere simplificar al máximo la tabla, todascon laselfilas la de tabla cuya dirección siguiente nodo (segunda columna) coincide de ladefila 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 encaminamiento 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


Este problema es comúnmente conocido como el problema de resolución de direcciones (address resolution problem ) y existen varias soluciones al mismo que se explican a continuación.

2.5.4.1. U ti lización de tablas estáti cas En este caso, cada equipo tendría una tabla con asignaciones estáticas con direcciones IP y sus correspondientes direcciones de subred asociadas, tal y como se muestra en la figura para una red Ethernet. A

IP

IP

MAC B

r

IP

ur

MAC

r

ur

r

IP

C

ur

MAC

IP

MAC

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 direcciones, la dirección IP es de 32 bits mientras que la de subred puede ser mayor (como, 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


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 Di rect M apping , puesto que es más eficiente que la de técnica de Dynamic Binding que se explica a continuación.

2.5.4.3. Asociación dinámica o D inamic Bi nding 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 datagramas IP.

ARP

Cabecera Trama

Mensaje ARP

atos

rama

Cola

Figura 2.39. Encapsulamiento ARP sobre tramas Ethernet

74

74


El funcionamiento de ARP se explicará mediante el ejemplo de la siguiente figura: A IPB

A

IPD

IPC

MAC B

C

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á encapsulando los datagramas en tramas Ethernet, enviadas desde la dirección srcen MAC A 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 (MAC C). 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.

IPA

IP

IP

IP

A

B

D

C

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

IP

A

B

C

D

MACB

MACC

MACD

es a

r.

C

Figura 2.42. Respuesta ARP ( unicast )

75

75


El formato de los dos mensajes ARP se muestra en la figura 2.43. 32 bits

Ti o de hardware1 =Ethernet Lon. Dir. Hard. (6)

Ti o de rotocolo 800=IP

Lon. Dir. Red (4)

Operación (1-Request o 2-Replay)

.

-

Dir. MAC Emisor (oct 4-5)

Dir. IP emisor (octetos 0-1)

Dir. IP emisor (octetos 2-3)

Dir. MAC destino (oct. 0-1)

Dir. MAC destino octetos 2-5 Dir. IP destino

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 IP A, IPC y la dirección MAC A, y necesita MACC para poder enviarle los datagramas encapsulados en tramas Ethernet dirigidas a dicha dirección MAC C. 2. Para obtener la dirección MACC, envía un mensaje ARP Request encapsulado en una trama Ethernet enviada de forma broadcast (dirección MAC de destino todo unos: FF:FF:FF:FF:FF:FF).

IPA

IP A

IP

IP B

D

C

Bu sco la MAC del C

… (FFFF…..F)

Orig

Tipo 806

…

TIPO 1

MAC Fte

MAC Dest

MAC

00000…0

IP Fte IPA

IP Dest IPC

oa

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 IP A-MACA en su tabla ARP.

76

76


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, aparecerá 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 implementar 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 (Rever se Addr ess Resol uti on Pr otocol )

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


de arranque (boot image ) y así poder comunicarse a partir de ese momento utilizando TCP/IP.

A

B

C

SERVIDOR D

A

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 software 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


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 I P en Subr edes oSubnetting

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 embargo los administradores de la red pueden ‘jugar’ con los bits delHostId para subdividir 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.42.0.0

SUB RED2

Router

INTERNET

SUBRED 3

Router

Router

SUBRED 4 Router

SUBRED 5

SUBRED 6

Figura 2.49. Red IP de ejemplo

80

80


En los 16 bits del HostId , la frontera entre lo que es subred y sistema la fija el administrador de la red. En este caso lo ha dividido en 8 bits ( SubnetId ) y 8 bits (HostI d ), 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 izquierda 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 significativos 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 I P Desti no

M áscar a de Subr ed

Dir I P del Siguiente Nodo

Coste

Para la r uta 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 siguiente.

82

82


Tabla 2.3. Tabla de encaminamiento de ejemplo

Dir I P Desti no 172.30.1.0 172.30.2.0 172.30.3.0 0.0.0.0

M áscar a de Subr ed 255.255.255.0 255.255.255.0 255.255.255.0 0.0.0.0

Dir I P del Siguiente Nodo 172.30.10.1 172.30.10.2 172.30.10.3 172.30.10.4

Coste 1 1 1 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 ( NetI d+ SubnetId ) de dicha dirección de destino, mediante una operación AND (bit a bit) con la máscara 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 (figura 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 primeras 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


Veamos, a continuación, un ejemplo un poco más complejo de subnetting . Supongamos 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 posible 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

Equipo (13 bits)

Subred (19 bits)

(hasta 8190 equipos, 213-2)

un et

ts ,

3

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 Número de subred 0 1 2 3 4 5 6 7

8 9

84

84

Dirección de subred (HostId todo ‘0’) 158.42.0.0 158.42.32.0 158.42.64.0 158.42.96.0 158.42.128.0 158.42.160.0 158.42.192.0 158.42.224.0

Dirección del primer equipo8

Dirección del último equipo9

158.42.0.1 158.42.32.0 158.42.64.0 158.42.96.0 158.42.128.0 158.42.160.0 158.42.192.0 158.42.224.0

158.42.31.254 158.42.63.254 158.42.95.254 158.42.127.254 158.42.159.254 158.42.223.254 158.42.192.254 158.42.224.0

Sería la primera dirección válida que se podría asignar a un equipo de la subred Sería la última dirección válida que se podría asignar a un equipo de la subred

Dirección de

broadcast (HostId todo ‘1’) 158.42.31.255 158.42.63.255 158.42.95.255 158.42.127.255 158.42.159.255 158.42.223.255 158.42.192.255 158.42.224.0

CapítuloLa 2. F Laamili familia protocolos a dede Protoc olos TTCP/IP CP/IP

2.6.1. Subnettin g de máscara vari able (VL SM ) 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 configurar 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 tamañ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 estudiaremos 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 direcciones 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, utilizá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


Tabla 2.5. Subnetting de máscara variable Número de subredes y direcciones

16 subredes de 256 direcciones cada una



1 subred de 32768 direcciones

Dirección de Subred

Máscara a emplear

Subred/bits máscara

158.42.0.0

255.255.255.0

158.42.0.0/24

158.42.1.0

255.255.255.0

158.42.1.0/24

…

…

…

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

158.42.20.0

255.255.252.0

158.42.20.0/22

…

…

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

158.42.96.0

255.255.240.0

158.42.96/20

158.42.112.0

255.255.240.0

158.42.112/20

158.42.128.0

255.255.128.0

158.42.128/17

2.7. Conceptos de Super r edes.Supernetting y CI DR

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 alternativa 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


Subred 158.42.128.0/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

Máscara

0.0.0.0

0.0.0.0

Dir Sig.

192.168.0.2/30

192.168.1.2/30 Router

192.168.0.2

Internet

192.168.1.1/30

Router

192.168.0.1/30 Router

Destino

158.42.1.1/24

.

. . …

158.42.1.7/24 Rtr 158.42.1.1

158.42.1.5/24 Rtr 158.42.1.1

Máscara .

. . …

. .

. . …

158.42.1.12/24 Rtr: 158.42.1.1

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.5 6.

NetI

HostI

Superredes

Subredes

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 e interconexión La F amili a de Protoc olos T CP/IP de redes basada en TCP/IP

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 esquema 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 tantas para eldirecciones Ensubredes vez de esto, se conectar le podríana SubnetId (máscara asignarían de clase255.255.255.0). C válidas como desee 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 solicite 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 Servicio de Red (NSP o Network S er vice Providers ) proporcionen la conectividad a Internet. 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 resuelve 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


NSPs, es decir, una entrada por NSP que identifique el bloque de direcciones propiedad 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 equiposCIDR que utilicen CIDR necesitan tener instalada versión de de software queysoporte y entienda los rangos de direcciones queuna se manejan esta manera. Por ejemplo, considérese una organización a la que se le asignaron 4096 10 direcciones consecutivas, empezando en la dirección 245.85.80.0. La siguiente tabla muestra los valores binarios del rango de direcciones.

Tabla 2.6. Bloque de 4096 direcciones IP Dott ed Decimal

Binar io

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 direcciones 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 direccio25 nes IP cuyo prefijo es ‘1100001’, que estaría formado por 2 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


-

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: Centro y Sudamérica:

198.0.0.0 - 199.255.255.255 (198.0.0.0/7) 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 I P 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 interface de conexión a la misma a la tarjeta Ethernet, caso enviar de estary conectado a una LAN basada(por en ejemplo, la tecnología Ethernet), antes en de elpoder 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 interconexió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 dispositivos sin disco (disk-less ) o en dispositivos en redes cambiantes, donde se añaden, mueven o cambian (física y lógicamente) los equipos de la red. En este caso 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 e interconexión de redes basada en TCP/IP Asignación de Direcciones IP

raciones IP estáticas facilitando, de esta forma, su uso, gestión y mantenimiento.

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 arduasmovimientos labores de configuración equipos. Las demandas de conectividad, los cambios, temporales yde reconfiguraciones de red frecuentes no pueden consumir altos porcentajes del tiempo de los administradores cuyo coste económico es bastante alto. Estas situaciones han provocado 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 proporcionará la configuración y/o el software adecuado. En este capítulo se presentan los protocolos BOOTP ( Bootstr ap Pr otocol ) y el protocolo DHCP (Dynamic Host Configuration Protocol ), que funcionan en modo cliente/servidor, y ofrecen mecanismos de asignación de direcciones y configuració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 software 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 transferencia de ficheros o FTP) en el momento de inicialización del propio dispositivo.

3.2. El Protocolo BOOTP (Bootstr ap 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 administrarles la configuración IP básica, mediante UDP y utilizando los puertos 67 y

92

92

Capítulo 3. Asignación IP Asignación dedeDidirecciones reccione s 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 introducción del capítulo: -

Dirección IP.

-

Mascara de subred.

-

Dirección IP de un router por defecto o D efault G ateway .

-

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 dicha dirección física en un mensaje BOOTP Request , encapsulado en un mensaje UDP, a su vez encapsulado en un datagrama IP dirigido al servidor, utilizando el puerto UDP 68 de srcen y el puerto UDP 67 de destino. Si no conoce ni su dirección ni la del servidor (el cliente podría estar parcialmente configurado), en la cabecera del datagrama utiliza como dirección srcen todo ceros (0.0.0.0) y como dirección destino todo unos (la direcció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 (asignación estática). El servidor rellena los datos en una respuesta ( BOOTP Repl y), encapsulada en un mensaje UDP, a su vez encapsulado en un datagrama IP enviado por broadcast , usando el puerto UDP 67 de srcen y

93

93

Direccionamiento interconexión Asignaci ón de D ireecciones IP de redes basada en TCP/IP

enviado al puerto UDP 68 de destino. Dicha respuesta puede, opcionalmente, 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 Protocol ) de descarga de ficheros y la ubicación dentro del servidor y el nombre 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 podrá 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 ejecutará.

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 este 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), sustituye al protocolo BOOTP descrito en el apartado anterior, presentando una alternativa 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 capacidad de asignación automática de direcciones de red reutilizables y opciones adicionales de configuración. Los participantes DHCP pueden interoperar con participantes 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 clientes 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

Capítulo 3. Asignación direcciones Asignación de de Direcciones IP IP

3.3.1. Di fere ncias DH CP y B OOTP 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 predefinida, se suministraba esta información IP. La correspondencia entre direcciones físicas (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 direccionamiento. 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 tuviera 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 permite el alquiler de información IP, mientras que BOOTP la asigna de forma permanente. 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 interconexión de redes basada en TCP/IP Asignación de Dir eecciones IP

3.3.2. Descri pción de DH CP 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 enviados 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 ‘puer to D H CP de cli ente ’ (68). El servidor DHCP puede proveer más de 30 opciones de configuración IP al dispositivo 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

•

Servidores NIS (Ser vici o de Inf or mación de Re d ).

•

Dominios NIS.

•

Servidores NTP (Protocolo de Tiempo de Red ).

•

Servidor SMTP.

•

Servidor TFTP.

•

Nombre del servidor WINS.

) para la interface.

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

Capítulo 3. Asignación Asignaci ón dedeDdirecciones irecciones IP

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 configuración IP:

-

Asignación manual o estáti ca: Es el mecanismo más rígido y poco flexible. El administrador de la redIPpuede establecer explícitamente en (o el aservidor DHCP una configuración específica a máquinas específicas todas). El servidor DHCP se la comunicará al cliente cada vez que éste se lo solicite y siempre será la misma (asignación estática), es decir, la que esté configurada 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 cambiante 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 solicitud al servidor DHCP , quedando asignada al cliente de forma permanente hasta que el propio cliente la libera. Este tipo de asignaciones se suele utilizar 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 configuración IP a los clientes por un período de tiempo limitado, que es configurable. Este tipo de asignación es el único método que permite la reutilizació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 definido 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. F unci onamie nto de DH CP

Veamos en primer lugaraeluna funcionamiento un servidor cliente DHCP en un equipo conectado red en la que básico hay uncon único DHCP instalado disponible. Los pasos seguidos serían los siguientes, tal y como se muestra en la figura 3.1:

97

97


1.

El cliente envía en modo broadcast un mensaje DHCP Discover , que consiste 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 Servidor 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 reconocimiento mediante el envío (unicast ) de un mensaje DHCP ACK (o Acknowledge ) 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 configuración IP del cliente.

Determina la Configuración a as gnar

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

Capítulo 3. Asignación direccionesIPIP Asignación dede Direcciones

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 recibidas de otros dicha servidores) sólo le confirmará mediante un mensaje ACK el servidor que le envió oferta y(en el caso de la figura, el servidor DHCP B).

SERVIDOR

CLIENTE

DHCP - A

D H CP

SERVIDOR D HC P - B

Determina la Determina la on gurac n

selección de configuración

Envío Unicast

Figura 3.2. Diagrama de tiempos del intercambio de mensajes entre un cliente y varios servidores

3.3.4 . Estad os D H CP

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 continuación, pasa a estar en el estado de selección, en el que recibirá una o varias ofertas (mensaje DHCP Offer ) de uno o varios servidores. En dichas ofertas, los servidores 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 intervalos de 2 segundos. Si sigue sin recibir respuesta, el cliente descansa durante 5

99

99


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 pasando 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 (incluyendo la el dirección IPasignación que tiene asignada) D H CP Request para renovar la asignación. Nótese que estando en estado de , el cliente 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 ini cialización e intentará obtener una configuración IP cuando la necesite de nuevo.

Inicio (boot)

Inicialización

Selección

OFFER

Solicitud

empo a qu er venc o

ance ac n a qu er

Asi nación Tiempo alquiler vencido

Renovación

Reasignación 87,5% tiempo alquiler 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

Capítulo 3. Asignación direccionesIPIP Asignación dede Direcciones

Cuando el cliente envía una solicitud de renovación entra en un estado de renovació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 r easignaci ó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 NACK 12 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 configuración IP válida para la nueva red.

3.3.5. F orm ato de los mensajes DH CP El formato de los mensajes DHCP está basado en el formato de los mensajes BOOTP para garantizar la interoperabilidad de clientes BOOTP existentes con servidores DHCP 13. 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 i nteracciones entre clientes y servidores BOOTP y DHCP .

101

101


Código Operación

Long. Dir HW Num. Saltos Tipo de HW Identificador de Transacción e a a ores ags Dirección IP del Cliente (ciaddr recc n e erv or s a r Dirección IP del Gateway (giaddr) Dirección Hardware (16 bytes (chaddr Nombre del Servidor (64 bytes) (sname)

Nombre de archivo bootfile (128 bytes) pc ones ong tu var a e asta

ytes

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 Discover , Request, Inform 14, Decline 15 y Release. Valdrá 2 para los mensajes Offer ,

ACK y NACK. -

Tipo de Hardware (1 byte):

-

Longitud D ir ección H ardwar e (1 by te): Indica la longitud en bytes de la direc-

Indica el tipo de red física. Por ejemplo, para 10 Megabit Ethernet el tipo es 1. 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

Capítulo 3. Asignación IP Asignación dedeDidirecciones reccione s IP

-

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 incrementará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 solicitudes 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 renovació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 poniendo 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 ejemplo, el servidor DHCP podría utilizar esta información para dar prioridad a determinados 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 denominado , el resto no se usan. Los clientes los ponen a cero y los Broadcast flag El bit Broadcast flag lo puede activar un cliente para servidores los ignoran. forzar al servidor una respuesta broadcast en vez de unicast .

-

Dirección IP del cliente (ciaddr, 4 bytes):

-

Tu Di r ección IP (yiaddr, 4 byte s): Será la dirección IP del cliente que rellenará

Contiene la dirección IP del cliente. Si el cliente no dispone de esta información incluirá todo ceros (0.0.0.0). el servidor en su mensaje de respuesta a la solicitud asociada.

-

Dirección IP del Servidor (siaddr, 4 bytes):

-

Dirección IP del Gateway (giaddr, 4 bytes):

-

Dirección Hardware del Cliente (chaddr, 16 bytes):

Contiene la dirección IP del servidor. La rellena el servidor en el mensaje de respuesta. Dirección IP del router de salida a la red. La rellena el servidor en el mensaje de respuesta. Dirección física del clien-

te. -

Nombre del Servidor (sname, 64 bytes):

-

Nombre de Fichero de configuración de arranque (bootfile):

Campo opcional rellenado por el servidor en una respuesta. Contiene una cadena de texto terminada en un carácter nulo (NULL) conteniendo el nombre de dominio del servidor. Campo opcional de 128 bytes que puede ser rellenado por el servidor. Estará vacío (NULL) en

103

103


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 configuració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 Release). 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 debe estar preparado para recibir un mensaje de hasta 576 bytes16, que se corresponde con el tamaño mínimo de un datagrama que un host IP debe estar preparado para aceptar, según la RFC 1123 ( Requirements for Internet Hosts Communicati on Laye r s). 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 sobre las opciones en la RFC 2131. El campo opciones contiene información adicional estructurada en opciones siguiendo el formato definido srcinalmente 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 dicha opción), un byte de longitud de los datos de la opción (en este caso la longitud es de 1 byte) mensaje y otro byte de datos conteniendo el tipo o código de mensaje DHCP (ver tabla 3.1).

go=

ong=

po=…

Figura 3.5. Opción de tipo de mensaje DHCP (3 bytes)

16

104

104

548 bytes del mensaje DHCP + 8 bytes de cabecera UDP + 20 d e cabecera IP.


Tabla 3.1. Campo de opción de tipo de mensaje DHCP

Tipo de mensaje 1 2 3 4 5 6 7

Mensaje DHCP

Discover Offer Request Decline ACK NACK 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:

158.42.100.200/16 MACServidor

MACA

DH CP Di scover MAC Ori : MAC A MAC Dest: FF:FF:FF:FF:FF:FF

IP Ori : 0.0.0.0 IP Dest: 255.255.255.255

UDP 67

Ciaddr: ?? Mascara: ?

Giaddr: ? Chaddr: MACA …

Datagrama IP

Figura 3.6. Solicitud ( Discover ) enviada al servidor DHCP por un cliente

17

17

El puerto UDP que aparece en las figuras es el puerto de destino.

105

105


158.42.100.200/16

MACA

M

Servidor

DHC P O er MAC Ori : MAC MAC Dest: MAC A

IP Ori : 158.42.100.200 IP Dest: 158.42.100.10

UDP 68

Ciaddr: 158.42.100.10 Giaddr: 158.42.100.1 Máscara: 255.255.0.0 Chaddr: MAC A …

Datagrama IP

Figura 3.7. Respuesta (Offer ) enviada al cliente por un servidor DHCP

3.3.6. Conmut ación (r elay) D H CP. El Relay Age nt 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 separada 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 ubicado 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 (D HCP Re lay ). Esta segunda opción se implementa mediante el uso de un agente de reenvío o Relay 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, cuando 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 haya(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 probablemente la dirección del Gateway que se le configurará posteriormente al cliente). Realmente 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).

DH CP D iscover Cliente DHCP

MAC Orig: MACA MAC Dest: FF:FF:FF:FF:FF:FF

¿

IP Orig: 0.0.0.0 est: . . .

UDP 67

Ciaddr: ?? ascara:

Giaddr: ? a r:

A

…

A A R-A

Red A

IPR-A

er v

or

Router

(R elay Agent)

MACR-B R-B

Servidor Servidor

2

MAC Orig: MACR-B MAC Dest: MACServidor

DH CP D iscover

Red B IP Orig: IP R-B IP Dest: IP Servidor

UDP 67

Ciaddr: ?? Mascara: ?

Giaddr: IPR-A Chaddr: MAC A …

Unicast

Figura 3.8. Reenvío del mensaje Discover por el Relay Agent

107

107


DH CP Offer Cliente DHCP

IP Orig: IP Servidor est: A

MAC Orig: MACR-A est: A

¿

UDP

Ciaddr: IPA Giaddr: IPR-A ascara: asc. e a r:

A…

A A R-A

Red A

IPR-A

Servidor DHCP

Router

(R elay Agent)

MACR-B R-B

Servidor Servidor

DH CP Offer

Red B MAC Orig: MACServidor MAC Dest: MACR-B

IP Orig: IP Servidor IP Dest: IP A

UDP 68

Ciaddr: IP A Giaddr: IPR-A Mascara: Masc. Red A Chaddr: MAC A …

Figura 3.9. Respuesta del servidor DHCP remoto

108

108

NAT (Network Address Translation)

Capítulo 4. NAT (Networ k Addr ess Tr anslation) 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 cony la delalasred redes, aspecto a tener cuenta a medida querelacionados Internet crece, la privacidad seguridad en resulta cada vez másen 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 infraestructura 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. T ipos 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 I ntrane t 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 algunos recursos pueden ser accedidos desde el exterior, por grupos de usuarios externos, pero bajo el control del administrador de la red. Una Red Privada Virtual (Virtual Private Network o VPN) consiste en una red privada que utiliza infraestructura de red pública. Representa una solución más económica bastante extendida en las organizaciones que utilizan Internet para sus comunicaciones tanto internas como externas, pero con requisitos de privacidad en sus comunicaciones internas.

109

109

Direccionamiento e interconexión NAT (Network Addres s Trans lati de on)redes basada en TCP/IP

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 Pr ivadas 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 Permanentes (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 organización con 2 sedes: Sede A

Sede B

…

…

R1

Línea alquilada o CVP

Router

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 4. NAT (Network Address Translation) NAT (Network Address Translation)

4.1.1.2. Redes Híbridas Actualmente, la mayoría de las organizaciones necesitan privacidad en sus comunicaciones 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

R3

R4

. .,

R o ut e r

Sede A

R o ut e r

Sede B

…

…

Router

R1

Línea al uilada o CVP

ou er

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 alquilada a un operador (o un CVP), ente los routers 1 y 2, mientras que los datos destinados a comunicaciones externas con otras organizaciones a través de Internet se encaminará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 direcciones públicas para las comunicaciones a través de Internet.

4.1.1.3. Redes Pr ivadas Vi r tuales (VPN) El principal inconveniente de los dos tipos de redes anteriores es el coste económico. 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

Direccionamiento e interconexión NAT (Network Addr ess Trans lati de on)redes basada en TCP/IP

función del número de puntos a interconectar y del ancho de banda de las conexiones. 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 utilización de Internet para ambos propósitos.

R1

A

Sede

Red Pública (P. ej., Internet)

Rout e r

…

R2

Rou t er

B

Sede

…

Figura 4.3. Red Privada Virtual (VPN) de una empresa con dos sedes

Se le denomina red privada porque garantiza privacidad en comunicaciones internas y virtual porque no utiliza redes (WAN) privadas. Se trata de una red físicamente pública pero virtualmente privada. Para garantizar la privacidad cuando se utiliza una red pública subyacente, se utilizan dos técnicas:

-

-

112

112

IPSec (Internet Protocol Security)

, que consiste en un conjunto de protocolos para ofrecer seguridad a las comunicaciones IP mediante la autenticación y el cifrado de cada paquete IP. Incluye protocolos para el establecimiento 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. , que como proporciona una especie de camino seguro a través de Tunneling red no segura, es Internet. Se basa en el encapsulamiento de una 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 mecanismos adicionales que doten de seguridad (por ejemplo, el cifrado de la información transportada).


En las siguientes figuras se puede apreciar cómo un datagrama IP srcinal (incluida su cabecera) es primero cifrado y, a continuación, encapsulado en otro nuevo datagrama con una cabecera nueva. De esta forma, el datagrama srcinal permanece ‘invisible’ hasta que llega al router remoto del otroextremo del túnel IP. Este router extraerá el campo de datos del datagrama recibido, lo descifrará y, de esta manera, obtendrá el datagrama srcinal y se lo entregará al destino, según la dirección IP de destino contenida en la cabecera. H

Datos

Bloque cifrado

’IP

’IP Datagrama IP enviado

Figura 4.4. Encapsulamiento utilizado en las técnicas de tunneling

Comunicación cifrada

Red Pública (P. ej., Internet) A

Sede

R o ut e r

R o ut e r

B

…

Sede

…

Figura 4.5. Comunicación cifrada en un servicio de VPN

4.2. Dir eccionamiento 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


ciones IP debido, principalmente, al sistema inicial de asignación de bloques completos 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 Addr ess Tr anslati on ). En la RFC losutilizadas 3 bloquesendecualquier direcciones siguientes uso privado, es 1918 decir se quedescriben pueden ser red IP privada para para su direccionamiento 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 pertenecientes 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 Internet 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 direccionamiento 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


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 datagrama 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á realizar el proceso inverso, es decir, de nuevo dirección IP equipo públicaIPa de la dirección IP interna privada para se su traducirá entrega dentro de lalared interna al srcen.

192.168.5.2/24

192.168.5.3/24

192.168.5.20/24

…

HIP

192.168.5.1/24

DatosIP

200.1.1.1/30

200.1.1.2/30

Internet

Dir IP srcen: 192.168.5.2 outer

atosIP

H’IP

NAT

r

o rg e n :

. . .

Traducc ión de dir ecc ion es 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 IP

IP

.

200.1.1.1/30

. . .

Internet

. . Router

H’IP

DatosIP

Router

Dir IP Destino: 200.1.1.1

Traducción de direcciones en

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

Direccionamiento e interconexión de redes basada en TCP/IP NAT (Networ k Address 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 direcciones 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:

-

Di rección Loca l Inte rna: Se trata de la dirección IP utilizada en la red interna. 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 srcen con la que salen los paquetes de la red Interna 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 Local Externa:

Dirección IP pública de destino con la que el srcen ve al host externo con el que se desea comunicar. 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 (srcen) 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


INTERNET

R1

Sede A

Ro u t e r

R2 .

200.1.1.1 recc n

Global Interna

.

.

Dirección

Ro u t e r

Sede B

Global Externa

172.16.10.2

192.168.1.2

recc n

Dirección Local

Local Externa

nterna

Figura 4.7. Terminología NAT

4.3.2. Tablas NA T

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 el traducciones en cada momento. El registro de cada traducción muestra mapeo entrerealizadas 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 192.168.1.2

Dirección Global Interna 200.1.1.1

Dirección Global Externa 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, prim e-

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

Direccionamiento e interconexión de redes basada en TCP/IP NAT (Network Address Translation)

4.3.3. NA T con u na o vari as dir eccion es públ icas 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 varios) de direcciones (pool ) IP públicas para poder asignar a cuantos equipos se necesite 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.

INTERNET

R1

192.168.1.1 Router

Sede A

200.1.1.1 oo : . . . a

…

192.168.1.2

200.1.1.10

Servidor Web .

.

.

192.168.1.3 .

. .

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 traducción NAT de la siguiente manera:

118

118

Capítulo NA 4. NAT (Network Translation) T (Network A Address ddres s Trans lation)

Tabla 4.2. Tabla de traducciones NAT Dirección Local Interna 192.168.1.3 192.168.1.5

Dirección Global Interna 200.1.1.2 200.1.1.3

Dirección Global Externa 158.42.10.10 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 dispone 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. Sobrec arga N AT Existe un mecanismo para poder permitir el acceso a Internet a un número de equipos mayor al número de direcciones IP públicas disponibles en la empresa, denominado Sobrecarga NAT . Esta técnica también se conoce como Traducción de direcciones 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 srcen temporal asignado por el host que enví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 Interna 192.168.1.2

Puerto Origen 1500

Dirección Global Interna 200.1.1.1

Dirección Global Externa 158.42.10.10

Puerto Destino 80

192.168.1.3

1501

200.1.1.1

158.42.10.10

80

En la respuesta del servidor web, el puerto srcen 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 identificará a cuál de los hosts de la red privada va dirigida dicha respuesta.

119

119

Direccionamiento e interconexión de redes basada en TCP/IP NAT (Networ k Address Translation)

INTERNET

.

e e

. .

ou er

200.1.1.1

Servidor Web …

.

. .

158.42.10.10

.

. .

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 consecutivo (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 conectar de forma simultánea a Internet sea significativamente superior a N.

4.3.5. Ej emplo de I SP con NA T 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 obligatoriamente. 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 srcen 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 4. NAT (Network AddressTranslation) Translation) (Networ k Address

ISP

172.16.1.1

172.16.1.2

outer

…

172.16.1.100

.

. .

.

INTERNET

. . 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. Ventaj as 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úmero 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 acceder a Internet compartiendo direcciones públicas, mediante NAT y/o PAT.

121

121


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, e)

además, no se permite el rastreo de las comunicaciones extremo a extremo. Proporciona una mayor facilidad de administración y coherencia en los esquemas 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 siguientes:

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 modificación alguna (por ejemplo, por seguridad). c)

No se pueden trazar las comunicaciones extremo a extremo, ya que las direcciones cambian debido al uso de NAT en uno o varios puntos a lo largo del camino 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)

122

122

Introduce problemas en servicios que requieren inicialización de conexiones TCP desde el exterior de la red privada, e incluso algunas comunicaciones mediante protocolos sin conexión, como UDP, pueden verse interrumpidas.

IPv6

Capítulo 5. I P ver sió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 sión 4 (IPv4).se produciría el agotamiento del espacio de direccionamiento IP verEn 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, aproximadamente, 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 Internet espectacular, especialmente en el mundo asiático. Por otro lado, el crecimiento que se vislumbraba de dispositivos conectados a Internet era muy elevado, especialmente 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 agotarí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 desarrollado, fundamentalmente, para resolver este problema de escasez de direcciones de IPv4 y, además, incorpora otras muchas mejoras en otros aspectos bastante limitados en IPv4, como en seguridad, eficiencia, calidad de servicio, tráficomulticast , 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 srcinalmente en la RFC 1883 (12/1995) y fue modificado posteriormente en la RFC 2460 (12/1998).

123

123

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

5.2. El Protocolo IPv6

5.2.1. Principalesdiferencias con I Pv4 Los requisitos principales a la hora del diseño de IPv6 fueron tres: que fuera compatible 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 128 de 32 bits (4 bytes) en IPv4 a ser de 128 bits (16 bytes) en IPv6, consiguiendo hasta 2 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 cambiar de ubicación. Como se verá más adelante, existe la posibilidad de que un dispositivo 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:





124

124

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 elimina 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 necesiten. 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.

Capítulo 5. IP versión IPv66





















Direccionamiento jerárquico. Las direcciones siguen una estructura jerárquica, lo cual permite reducir el tamaño de las tablas de encaminamiento, permitiendo satisfacer los requerimientos cada vez más complejos del direccionamiento jerárquico que IPv4 no proporcionaba. No se admite broadcast y, por tanto, se evitan las tan temidas tor mentas de broadcast . Posibilidad de envíos unicast , multicast y anycast, con mejor soporte para multicast . La escalabilidad del encaminamiento multicast se mejora incluyendo un campo ámbito a las direcciones multicast . Seguridad: IPv6 incorpora mecanismos de autenticación, integridad de datos y confidencialidad a nivel IP. Se incluyen técnicas de validación mediante técnicas de cifrado (seguridad mejorada mediante el uso de IPsec ), así como extensiones para utilizar autenticación, integridad de datos y, opcionalmente, 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 datagramas. 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 srcen solicita tratamiento especial, como la QoS no estándar o un servicio en ti empo real . Sencillez: Incluye la posibilidad de autoconfiguración de equipos y un manejo más simple del direccionamiento. Proporciona nuevos métodos de autoconfiguración automática de direcciones, así como de comprobación de direcciones únicas. Movilidad: Permite movilidad manteniendo la misma dirección ( M obile 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 enlace (host multi homed ). Por ejemplo, un dispositivo podría conectarse a varios ISPs a través de un único enlace.

125

125


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 posteriormente.

b) Multicast. Dirección de grupo que permite el envío a grupos de hosts, permitiendo 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. Identifica 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 srcen, 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 identificar 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 servicios de distribución de contenido. En el caso de que la dirección identifique a los routers de un ISP, puede indicar que se acceda a dicho ISP usando el router por el camino más corto.

5.3. Cabecer a 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

Capítulo 5. IP versión 6 IPv6

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 ongt u e carga t

Etiqueta de flujo g. a ecera mt esat os

recc n e or gen

ytes Dirección de destino (16 bytes)

Version Lon.Cab. DS ent cacn

Longitudtotal esp azam ento

Dirección de destino Opciones

>=20 b tes =

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 correo electrónico).

127

127


-

3: Reservado.

-

4: Transferencias de datos atendidas (por ejemplo, transferencia 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 utilizados 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. 











128

128

Etiqueta de Flujo. Se trata de una etiqueta que permite diferenciar clases de flujos, permitiendo diferentes tratamientos en función de la etiqueta. De esta 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 decir, del resto del datagrama a partir del último byte de la cabecera. Nótese que las extensiones de cabecera (extension headers) presentes en el datagrama, 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 datagrama 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 destino final de la información, como pasa, por ejemplo, en el caso de que se incluya una cabecera de encaminamiento.


En IPv6 se define como flujo a una secuencia de datagramas desde un srcen 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 srcen, dirección destino, clase de tráfico y etiqueta de flujo.

5.3.1. Cabe cer as de Ex tensi ón I Pv6

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 transporte utilizado (TCP o UDP). Estas cabeceras se denominan cabeceras de extensión . Existen unas pocas cabeceras de extensión definidas en RFCs, cada una identificada por un valor que se codificará en el campo Sigui ente Cabece r a de la cabecera IPv6. Un datagrama IPv6 puede contener ninguna, una, o varias cabeceras de extensión, cada una identificada por el campo Sigui ente Cabe cera 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 srcen 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 utilizar 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 srcen. Fragmento. Se utilizada por el srcen IPv6 para enviar un datagrama de 19

mayor tamaño en delIPv6 que la cabría en ellasrcen MTUy de la ruta con hacia el extensión destino .de La fragmentación realiza se indica esta

19

A diferencia de IPv4, en IPv6 la fragmentación sólo se lleva a cabo por los nodos srcen, no por los nodos intermedios

(Sección 5 de la RFC 2460)

129

129


cabecera. Incluye información muy parecida a la de los campos de segmentación y re-ensamblado de la cabecera de los datagramas IPv4. 



Opciones de Destino. Se utiliza para llevar información opcional que necesita ser examinada solamente por el/los nodo/s de destino del datagrama. Autenticación. Se utiliza para proporcionar integridad sin conexión y autenticaciónprotección del srcencontra de datos para datagramas IPv6, así como para proporcionar reenvíos.



Seguridad del Encapsulado de la Carga Útil. Se utiliza para para proporcionar 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, respectivamente. 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 campos 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 TCP

Datos

Cabecera IPv6 Campo Sig. Ca b. = = nc a m na m en o

Cabecera encaminam. Siguiente Cab. = TCP

Cabecera IPv6 ampo g. ab. = = ncam n a m e n o

Cabecera encaminam. Ca be ce ra Fra me nt o Siguiente Cab. = Siguiente Cab.=TCP = ra gmen o

a ecera

a os

Cabecera TCP

Datos

Figura 5.2. Cabeceras de extensión

Excepto en el caso de la cabeceraOpciones de Salto a Salto , que se explica a continuació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


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 procesar 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 Opci ones de Salt o a Sal to contiene información que debe ser procesada por cada nodo a lo largo de la ruta entre el srcen y el destino del datagrama IPv6, incluyendo los nodos de srcen y de destino. Cuando esté presente, dicha cabecera seguirá inmediatamente a la cabecera IPv6 y se indicará por el valor‘0’ en el campo Sigui ente Cabe cer a 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


Si la cabecera de capa superior fuera otra cabecera IPv6 (caso de tunn eli ng I Pv6 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á restringida a aparecer sólo inmediatamente después de una cabecera IPv6. Sin embargo, es recomendable que los datagramas IPv6 se creen respetando el orden recomendado 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. Dir ecciones en I Pv6

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 autoconfiguració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 inviable 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 grupos 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


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 representados en notación hexadecimal utilizandolos ‘:’, 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 u( nspecified address ): 0:0:0:0:0:0:0:0:0 , o bien, su equivalente ‘:: ’.

133

133

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

-

Dirección de loopback o bucle interno: 0:0:0:0:0:0:0:0:1 , o bien, su equivalente ‘::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 delas direccionesI Pv6

Los primeros bits de una dirección se llamanPrefijo de Formato ( Format Prefix ) e identifican el tipo de dirección. En la tabla 5.1 se muestran algunos de estos prefijos. 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 0000 0001 0000 001

Reservado (incluye IPv4) No asignado Direcciones OSI NSAP

0000 0000 010 011, 0000 1, 0001

Direcciones No asignadoIPX de Novell Netware Direcciones globales unicast agregables No asignado No asignado No asignado Direcciones privadas para enlaces locales Direcciones privadas Direcciones multicast

001…

(2000::/3)

010, 011, 100, 101 110, 1110, 1111 0, 1111 10 1111 110, 1111 1110 0 1111 1110 10… (FE80::/10) 1111 1110 11… (FEC0::/10) 1111 1111… (FF00::/8)

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ónmulticast , según sean permanentes o temporales, 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


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 direccionesmulticast asignadas de forma temporal o transitoria, que empezarán, por tanto, con la cadena hexadecimal ‘0xFF1’. Ámbito (4 bits): indican el ámbito del envíomulticast . 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 alenlace.

-

‘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.

multicast FF02::2 tiene un alcanPor ejemplo, todo elEntráfico a la nunca dirección ce local al enlace. IPv6 dirigido los routers 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 direccionesmulticast : FF01::1 (node-local scope all-nodes address ) FF02::1 (link-l ocal scope all -nodes address) Para identificar a todos los routers del ámbito local al nodo y al enlace, se definieron las siguientes direccionesmulticast :

22 23

El prefijo 0xff indica que la dirección es de multicast http://www. iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml

135

135


FF01::2 (node-l ocal scope al l-r outer s addr ess) 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. Dir ecciones 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 adicionales, como NAT, o bien reconfigurar toda la red. En IPv6 se ha tenido en cuenta 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

+ D ir ección ú nica para la te cnología del enlace

es decir la secuencia binaria fija ‘1111111010’ al principio y al final la dirección

física la tecnología utilizada. se rellenalacon ceros. En el caso que elpropia enlacede fuera una conexión a una En red medio local Ethernet, dirección única seríade 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


5.4.3.2. D ir ecciones Local es Si los equipos están conectados a una red en la que existen routers, pero sin conexión a un ISP, se pueden generar direcciones internas de la siguiente forma:

1111111011 +

00…00 +

ID de subred + Dir ección ú nica para la tec nologí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. Di r ecciones Públ icas Jerár qui cas (RF C 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 menores, 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 estructura jerárquica (Registro RIR  organización o ISP  Lugar o Sitio  Subred), 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 dispositivo 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 comparar 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


El proceso de asignación de direcciones IPv6 seguido por la IANA se ve reflejado en la siguiente figura:

spac o e recc ones comp eto

Espacio para los Registros asignado por la IANA ::

::

sp aco asgna o aun e gs t r o

sp aco asgn a o au n

2 0 0 1 : 0 7 0 0 :: / 2 3

sp aco asgna o a u n ao r g a nz a có n

2 0 0 1 :0 7 2 0 : :/ 3 2

:

na u re

:

::

:

::

::

Un Host

FFFF:…:FFFF

Prefijo de Red (64 bits)

ID de Interface (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 direcció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áti ca del identi fi cativo de int er face 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


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 restantes) 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:

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 identificador 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 dirección MAC extendida EUI-64.

140

140


El proceso seguido por el equipo se resume en la siguiente figura y consiste en los siguientes pasos:

.

1 e p re o e es a re

2 . :

:

:

Equipo IPv6 MAC: 0F22:0A2C:C5DB EUI-64: 0F22:0AFF:FE2C:C5DB IPv6: ?? . n onces m recc n v e er ser 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 identificativo 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


-

Mecanismos de ahorro de direcciones: NAT (Network Address Translation ), 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 especificaciones de Servicios integrados o Intserv (RFC 1633) y Servicios Diferenciados o Diffserv (RFC 2475).

-

Movilidad y autoconfiguración: DHCP (RFC 1534).

5.7. Estr ategias 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 preocupar 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 paulatina, tal manera van aDe convivir ambas versiones protocolo de IP forma (versiones 4 y 6)de durante algúnque tiempo. esta manera, nodos condel 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 sistemas 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 d oble 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

Capítulo 5. IP versión 6 IPv6

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 necesidades. 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

… IPv4

IPv4

IPv6

IP v4

Subred

IP1v4R/IP1v6R

IP2v6R

…

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 paulatinamente 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


•

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 direcciones 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 be estar dirigido el datagrama IPv4 generado. Requiere que el final del detú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 ventaja 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 v

R1

IPv4R2

Tunel

Re d 2 IP v6 IPv6R2

…

…

IPv61

IPv63

IPv6

IPv6

Figura 5.9. Tunneling IPv6

•

144

144

Túneles ISATAP (Intra-Site Automatic Tunnel Addressing Protocol ): permiten conectar dispositivos con doble pila (IPv4/IPv6) a través de redes IPv4. Los dispositivos con doble pila utilizan ISATAP para encapsular datagramas 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


no requiere que la red IPv4 subyacente soporte multicast . ISATAP está implementado 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 I Pv6-to-IPv4 Tr ansport Relay Tr anslator ), entre otros.

145

145

Encaminamiento en I P

Capítulo 6. Encaminamiento en IP 6.1. Introducción En una interred IP, los sistemas finales y los routers cooperan para facilitar el encaminamiento de la información (datagramas) desde el sistema final o host de origen hasta el sea sistema final o host de destino, pasando por cuantas subredes y routers intermedios necesario. En este proceso de encaminamiento extremo a extremo, existen tres procesos principales:

1. El sistema final de srcen necesita saber cuándo y cómo enviar la informació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 destino 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 normalmente 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 e interconexión de redes basada en TCP/IP Encaminamiento en 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 administradores de red utilicen algoritmos de encaminamiento dinámicos. Dichos algoritmos permiten que los routers puedan actualizar y mantener sus tablas de encaminamiento de forma automática y dinámica según el estado de la red en cada momento, sin necesidad de la intervención del administrador desegún la red. añadir a suytabla de encaminamiento rutas a nuevas redes remotas lasPueden 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 encaminamiento 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 encaminamiento. Este tipo de bucle produce un efecto de ida y vuelta a los paquetes por un mismo enlace, conocido como efecto pi ng-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:

148

148

-

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.

Capítulo 6.Encaminamiento Encaminamiento enenIPIP

-

Posible pérdida de actualizaciones de encaminamiento o que no se procesen 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 cambios en la red. Será necesario un intercambio de información (bien de forma de 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áscara 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 protocolos classless (sin clase), mientras que a los que no la envían se les denomina protocolos 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 todos sus routers dentro del SA. A dichos protocolos se les denomina Protocolos de

Gateway 26 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 Shor test Path F ir st ), IS-IS (I nter medi ate System to Intermedi ate 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 Pr otoc ol ) es un ejemplo de un protocolo EGP para encaminamiento 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 frecuencia, sustituyendo, por tanto, a la palabra Gateway , ya que ambas palabras tienen distinto significado en el modelo OSI.

149

149

Direccionamiento de redes basada en TCP/IP Encaminamiento ee interconexión nIP

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 Internet 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 Short est Pat h F i r st ), que sigue la técnica encaminamiento por estado del enlace y tiene en cuenta el ancho 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 confección de las tablas de encaminamiento) varían en función del estado de la red posibilitando 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

Capítulo 6.Encaminamiento Encaminamientoen en IP

necesidad de la existencia de ningún nodo especializado que tome dichas decisiones, 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 étri ca y Dist ancia Admi ni strativa (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 conocidos 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 encontrar 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 protocolos 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 determinadas rutas para cambiar la prioridad de dichas rutas frente a otras que tienen menor valor por defecto de DA.

151

151

Direccionamiento de redes basada en TCP/IP Encaminamiento ee interconexión n IP

Tabla 6.1. Distancias Administrativas por defecto Ruta

Valor de DA

Red directamente conectada Ruta estática Ruta resumida EIGRP BGP externo EIGRP interno IGRP OSPF IS-IS RIP EIGRP externo BGP interno

0 1 5 20 90 100 110 115 120 170 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 5050% o un 25-75%..., o según estado de ocupación del enlace de salida de cada ruta).

6.1.2. D etecci ón de r edes

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

Capítulo 6.Encaminamiento Encaminamientoeen IP n IP

6.2. Protocolo de encaminamiento RIP

6.2.1. En camin amiento por vector distanci as 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ódico 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 encaminamiento 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


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.

-

Tempor izador de inval idez. Si no se recibe actualización para renovar la ruta 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 como 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. Tempor izador de invali dez o de pur ga. Por defecto, se configura en 240 segundos (60 segundos más que el de invalidez). Cuando vence, la ruta se elimina de la tabla de encaminamiento.

6.2.2.2. Actual izaciones dis par adas (tr igger ed updates) Para acelerar la convergencia cuando se produce un cambio en la topología (principal 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 actualizaciones 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 encaminamiento.

154

154

Capítulo 6.Encaminamiento Encaminamientoen enIPIP

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 valor 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 cuales 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 encaminamiento, 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 indicado en el campo anterior. Contendrá un valor de 1 a 16. Un valor de 16 indica una ruta inalcanzable.

155

155


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 puertos srcen 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. F uncionamiento de R IPv1 RIPv1 funciona en modo solicitud/respuesta, para lo cual se definen 2 tipos de mensajes: -

Solicitud (Request). Se envían al iniciarse el router por cada una de las interfaces (o enlaces) en las que se haya activado o habilitado RIP 27. 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 dicha información.

Cada router, cuando se inicia, enviará por aquellas interfaces en las que tenga habilitado 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

Capítulo 6.Encaminamiento Encaminamiento enen IPIP

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 proceso 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 prefijo 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 procesamiento, 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 derecha.

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é subredes publicar.

157

157

Direccionamiento interconexión de redes basada en TCP/IP Encaminamiento een IP

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

Desti no 172.16.0.0/16 192.168.1.4/30 192.168.2.0/24

158

158

Sigui ent e nodo Saltos R2 1 Directamente conectada a I1 Directamente conectada a I2


La sumarización de rutas permite, por tanto, reducir el tamaño de las tablas de encaminamiento 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 decisiones 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 subr ed no contigu a , debido a que dos grupos de subredes 172.16.0.0/24 están separados, 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 (horizonte dividido) y Split-Horizon Poisoned Reverse (horizonte dividido con envenenamiento en reversa) que se usan para evitar que se produzcan bucles de encaminamiento. 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 Por otro lado, las obtuvo a partir de actualizaciones recibidas por dicha interface. la técnica split-horizon poisoned reverse consiste en que una vez que un router

159

159


detecta una ruta inalcanzable a través de una interface, debe anunciar que es inalcanzable 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. Simi l it udes 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 splithorizon y spli t-hor izon poisone d r ever se para evitar el problema de conteo a infinito; 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 automático de rutas por rutas los routers de borde en de los subred límites menor de red que principales y también permite resumir con una máscara 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 embargo, 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. F or mato de mensajes RI Pv2 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:

160

160

-

Campo de la máscara de subred.

-

Campo de la dirección IP del siguiente nodo o salto.


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 Shor test Path F ir st )

6.3.1. Protocolos de estado del enlace El protocolo OSPF (Open Shortest Path First ) se basa en la técnica de encaminamiento 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 Dijkstra . 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 directamente. A continuación, intercambian un paquete de saludo (hello la ) por sus enlaces para descubrir a los routers vecinos; posteriormente que utilicen misma técnica de estado del enlace, crean paquetes de estado de enlace (LSP o Li nk 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


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 manera, 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 arranque de los protocolos de encaminamiento de estado de enlace puede consumir mucho 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. F unci onamie nto del Pr otocolo OS PF

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 incorpora 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 hayan sido configurados con las credenciales adecuadas.

162

162


OSPF es un algoritmo de encaminamiento classless, por lo que en las actualizaciones 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 enlaces 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, manteniendo conexión, bien física o bien lógica, con las demás áreas de la red. La conexión entre un área y elbackbone 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 decir, con el único conocimiento de un router de salida por defecto hacia todos los posibles destinos externos a la red. 3. Área not-so-stubby (NSSA). Son un tipo de área stub que puede importar Backbone u, pero rutas externas de SAs enviarlas no puede recibir rutas externas deySAs desde al el Área ÁreaBackbone otrasque áreas.

163

163


6.3.2.2. Ti pos especial es de rou ters 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 encargarán los routers OSPF dentro de la propia área que, mediante OSPF, mantendrán información la topología la red entre dentro la propia área. embargo, también será sobre necesario encaminardetráfico lasdedistintas áreas de Sin un SA (encaminamiento inter-área) y entre distintos SAs (encaminamiento externo). Para estos dos tipos de encaminamiento, OSPF define dos tipos de routers especiales que mantendrá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 conectan éstas con el resto de áreas (encaminamiento inter-área). Son los responsables 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 ( System 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 srcinado, 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. I denti fi cativo de un Route r

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 direcció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 interfacesloopback (interfaces 164

164


internas, para pruebas, de lazo propio al router, sin conexión a ningún enlace) y físicas. 2. Si no se dispone de un identificativo configurado, el router elige la dirección IP más alta de cualquiera de las interfaces loopback, en caso de que tenga configuradas. 3. Si no se configuradas, dispone de unse identificativo configurado, y nodehay interfaces loopback utiliza la dirección IP más alta 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. M ensaj es 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

Ti po 1 2 3 4 5

Nombre Saludo Descripción de Bases de Datos (DBD) Solicitud de Estado del Enlace (LSR) Actualización de Estado del Enlace (LSU) Acuse de Recibo de Estado del Enlace (LSAck)

Propósito Descubrir vecinos para crear adyacencias Para controlar la sincronización de la información entre routers Solicitar registros específicos de estado del enlace de router a router Enviar los registros de estado del enlace específicamente solicitados Reconocimiento de cada uno de los demás paquetes

El mensaje de actualización de estado de enlace (LSU o Link State Update ) se utiliza para para entregar publicaciones del estado de enlace (LSA o Link State Advertisement). 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


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 localizada (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 escalabilidad, 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. Dependiendo 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 de Enlace 1 2 3 4

166

166

Descripción Conexión punto a punto con otro router Conexión a una red de tránsito Conexión a una red final o stub Enlace virtual

I dentif icati vo del enlace (li nk-state ID ) ID del router vecino Dirección IP del Router Designado Red IP/máscara de subred ID del router vecino

Datos del enlace Dirección IP de la interface srcen Dirección IP de la interface srcen Máscara de subred de la interface Dirección IP de la interface srcen


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 del inundación dentro El Identificativo enlace (link-state LSA de tipo 1 esde el su ID área. del router srcinador del del mensaje. ID)

-

Tipo 2 (Network LSA ). El router designado (DR28) en un segmento broadcast (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 correspondiente. 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 (Ar ea Bor der 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 informació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 enlace (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 detallada del siguiente salto no esté disponible. Esto un ABR lo resuelve inundando la información para el router srcen del LSA de tipo 4 (por ejemplo, el router de borde de un SA, ASBR), mediante un LSA de tipo 4. El Identificativo 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 direcció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


-

Tipo 7. Los routers en una Not-so-stubby-area o NSSA no reciben LSAs externos de los ABRs pero sí se les permite enviar información de encaminamiento 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 informació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 appli cation-spe cifi c purpose s).

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 siguientes campos: versión, tipo del mensaje OSPF, longitud del mensaje, identificativo 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


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 unaccesos router designado y un router designado de respaldo (BDR)reen redes de múltiples, (DR) tal y como se explica más adelante. En dichas 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 srcen.

-

ID del área: Identificativo del área desde la cual se srcinó 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 adelante).

-

Lista de vecinos: enumera el identificativo del router OSPF de los routers vecinos.

6.3.2.5. Encaps ul amiento OS PF

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


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 inactivo 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


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 mayores:

-

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étr ica 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 r efer encia)/( AB de la i nter face) 8

, tomando un AB de referencia de 10 Mbps, aunque dicho valor puede ser modificable en algunos routers, ya que las velocidades de los enlaces son cada vez mayores. 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


Tabla 6.5. Métrica en OSPF

Tipo de inter face Fast Ethernet y tecnologías más rápidas Ethernet E1 T1 ----

Ancho de Banda

Coste

8

1

107 2048 Kbps 1544 Kbps 128 Kbps 64 Kbps 56 kbps

10 48 64 781 1562 1785

10y superiores

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 Network 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últiples 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 suponer 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

Capítulo 6.Encaminamiento Encaminamientoen enIPIP

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. Pr oceso de selección de D R/BD R

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 prioridad 29 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 utiliza 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 siguientes:

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 interfaces 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 interconexión de redes basada en TCP/IP Encaminamiento een IP

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últiples. 2. Un DR seleccionado permanecerá como DR hasta que ocurra una de las siguientes 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) Specification (IPv6)”, RFC 2460, IETF Network Working Group, Diciembre 1998. 10. Forouzan, Behrouz A., ‘TCP/IP Protocol Suite’, 2da Edición,McGrawHill, 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 Exploration”, Cisco Networking Academy, 2009, 726 páginas, ISBN 9788483224748.Tanenbaum, A. S., Compute r networ ks, 5ª edición, Boston etc.: Pearson Education, 952 páginas, 2011, ISBN 978013255-3179

175

175

Direccionamiento e Interconexión de Redes Basada en TCPIP IPv4IP

Recommend Documents