Tema 2. Direccionamiento IP y protocolos asociados

Tema 2. Direccionamiento IP y

protocolos asociados

Ingeniería de protocolos

Curso 2012/13

Jaime Benjumea Mondéjar Dpto. Tecnología Electrónica

 Una dirección siempre pertenece a una clase,

dependiendo de los MSB de la IP.

 “parte de host” especial: 0…0 para identificar a la red, 1…1 para broadcast en esa red (broadcast dirigido)

(RFC919).

 Las direcciones 111…

tenían un significado especial (RFC791).

Direcciones IP. Clases

 Direcciones de 32-bits, habitualmente: A.B.C.D (numero de 8 bits, en decimal). Una parte es la “parte de red” y la otra “parte de host”.

 Originalmente (RFC791) se decidió crear tres clases de redes, cada una con una parte de red y de host fija (pero distinta en cada clase).

C

B

A

C

B

A

2.097.152 redes 256-2 = 254 hosts en c/u

11000000 01100100 01100010 11110101

192 . 100 . 98 . 245

11000000 01100100 01100010 11110101

192 . 100 . 98 . 245

2.097.152 redes 256-2 = 254 hosts en c/u

10010110 11010110 00000111 00000110

150 . 214 . 7 . 6

16.384 redes 65.536-2 =65.534 hosts en cada red

10010110 11010110 00000111 00000110

150 . 214 . 7 . 6

10010110 11010110 00000111 00000110

10010110 11010110 00000111 00000110

150 . 214 . 7 . 6

16.384 redes 65.536-2 =65.534 hosts en cada red

00101100 11101100 00001100 00000011

44 . 236 . 12 . ₃

127 redes 16.777.216-2 =16.777.214 hosts en cada red

00101100 11101100 00001100 00000011

44 . 236 . 12 . ₃

127 redes 16.777.216-2 =16.777.214 hosts en cada red

00101100 11101100 00001100 00000011

44 . 236 . 12 . ₃

00101100 11101100 00001100 00000011

00101100 11101100 00001100 00000011

44 . 236 . 12 . ₃

Direcciones IP. Subnetting (definicion)

HECHO: Algunas instituciones podrían tener varias LAN con conectividad IP. PROBLEMA: Si tengo ya una clase asignada, ¿cómo hago el direccionamiento? SOLUCIÓN: Dividir una clase en varias subredes (RFC917 y RC950)

Estas dos subredes no se pueden usar, 0..0 y 1..1 en la parte de host tiene significado propio. No se sabría qué es 150.214.255.255.

“Nunca” se puede usar la primera ni la última subred al hacer subnetting.

El subnetting siempre desperdicia 2 hosts por cada subred y la primera y última subred completas (en este caso paso de tener 65534 a tener 64516.

16 bits (parte de host), pido prestados 8 bits

Se propone “tomar prestados” varios bits de la parte de host y anexionarlos a la parte de red.

1 red con 65.534 nodos 254 redes con 254 nodos 150.214.0.1-150.214.0.254 150.214.1.1-150.214.1.254 150.214.254.1-150.214.254.254 150.214.255.1-150.214.255.254

Un nodo externo, no ve el subnetting, desde fuera sólo se ve la clase B número 150.214 (150.214.0.0/16).

…

 Es necesario un nuevo parámetro de red: Máscara de red, que indica ( con 1) qué bits son la “parte de red (+subred)”. Ej: 255.255.255.0 o bien /24

Direcciones IP. Subnetting (ejemplo)

Ejemplo: Dividir la clase A 10.0.0.0 para obtener, al menos, 4 redes.

Solución: Con 2 bits prestados sólo consigo 2 redes, así que necesito 3 bits para conseguir 8-2=6 redes.

Red Dirección de la red Dirección de

broadcast Notación estándar Nodos en la red

10. 000 00000. 0. 0 10.0.0.0 10.31.255.255 10.0.0.0/11 IMPOSIBLE 10. 001 00000. 0. 0 10.32.0.0 10.63.255.255 10.32.0.0/11 2.097.150 10. 010 00000. 0. 0 10.64.0.0 10.95.255.255 10.64.0.0/11 2.097.150 10. 011 00000. 0. 0 10.96.0.0 10.127.255.255 10.96.0.0/11 2.097.150 10. 100 00000. 0. 0 10.128.0.0 10.159.255.255 10.128.0.0/11 2.097.150 10. 101 00000. 0. 0 10.160.0.0 10.191.255.255 10.160.0.0/11 2.097.150 10. 110 00000. 0. 0 10.192.0.0 10.223.255.255 10.192.0.0/11 2.097.150 10. 111 00000. 0. 0 10.224.0.0 10.255.255.255 10.224.0.0/11 IMPOSIBLE

Antes (clase A):16.777.214 nodos.

Ahora (subnetting): 6 redes con 2.097.150 nodos = 12.582.900 nodos

Se pierde el 25% del direccionamiento 10.0.0.0 es 00001010 00000000 00000000 00000000

Direcciones IP.

Subnetting (uso de máscara de red)

Problema: ¿Cómo sabe un host si debe usar el router (i.e. cómo sabe un nodo si otro está en su misma red/subred)?

Dir. IP: 10.35.5.3 Máscara: 255.224.0.0

Ejemplo A) Dst: 10.60.0.0 10.60.0.0 <AND> 255.224.0.0 = 10.32.0.0

Ejemplo B) Dst: 10.65.0.0 10.65.0.0 <AND> 255.224.0.0 = 10.64.0.0

Coincide con mi red: Está en mi red

NO coincide con mi red: NO está en mi red

Sin subnetting, la respuesta está clara, todo lo que sea 10.x.x.x está en mi red …

… pero si me dan una máscara la cosa cambia dado que la red ya no es 10.0.0.0 sino: IP <AND> Mask: 10.32.0.0

Además la máscara no termina en un byte, con lo que saber si un destino está en mi red o no ya no es tan obvio.

150.214.1.0/24

Direccionamiento IP.

Classfull

150.214.141.0/24

• Los protocolos de enrutamiento (classfull), a través de las máscaras, conocen la subdivisión en redes. • Pero, al anunciar las redes, no informan de la máscara.

• Todo funciona si la subdivisión es homogénea. PROBLEMA a b c d e • (a), (b), (c) y (d) tendrán el mismo tamaño, se use o no. • En los routers internos habrá hasta 254 entradas adicionales. • (e) es un desperdicio

Problemas históricos.

Advenimiento de CIDR

• En 1992 se plantea (RFC 1338, 1380) varios problemas serios:

– En dos años se preveía la asignación de todas las clases B (aunque se usen con “poca densidad”) …

– … haciendo necesario el uso de las clases C (2Mill de redes)… – … lo cual provocaría una “explosión” en las tablas de rutas.

– Además, a ese ritmo, nos quedaríamos sin direcciones IP, no tanto por que hubiera demasiados “host” sino porque hay demasiadas “redes”.

• Se propone:

– Eliminar el concepto de clase en las direcciones IP, creando Classless InterDomain Routing (CIDR). Requiere que los protocolos de routing soporten esa modificación: <dir_ip>/<mask>.

• Para:

– No estar atado al concepto de clase.

Ejemplo de Agregación (Supernetting)

Ejemplo: RedIRIS, quiere direccionamiento para unos 250.000 nodos, ¿de qué forma CIDR y las técnicas de supernetting son de ayuda?

I) Si usara 1024 clases C, se podrían asignar (1024*254 > 250.000), pero necesitaría 1024 “líneas” en la tabla de rutas (algo costoso).

II) Escojamos lo siguiente: Desde 193.144.0.0 a 193.147.255.255 son 1024 clases C (antigüas clases C, para ser exactos)

11000001 10010000 00000000 00000000

Byte 1 Byte 2 Byte 3

11000001 10010011 11111111 11111111

En binario, “las fronteras” de esas clases C son estas

Parte común en las 1024 redes (14 bits)

Esta parte varía red a red, igual que sucede con la parte host de una red cualquiera.

Propuesta: Hacer lo contrario que en subnetting.

Supernetting: Pedir prestados bits de la parte de red, que se asimilan a

la parte de host.

Agrupo o agrego esas 1024 redes y las publico como una única ruta

¿Cómo?

Usando máscaras de red:

193.144.0.0/14

 Desde fuera, se ve como una red única (sin clase).

Dentro, puedo organizarlo como quiera (dividir un subredes del tamaño que quiera).

 Necesita modificar los protocolos de routing al eliminarse las clases (CIDR).

 OJO: A partir de ahora, con CIDR, el concepto de clase desaparece.

Gestión del direccionamiento actualmente (I)

IANA

(Internet Assigned Numbers Authority)

AfriNIC (África) APNIC (Asia/Pacífico) ARIN (NorteAmérica) LACNIC (Latino América y partes del Caribe)

RIPE NCC

(Europa, Oriente Medio y Asia Central)

IANA tenía, históricamente, el control de todo el direccionamiento

Los RIR (Registros Regionales) se encargan cada un de su zona geográfica, IANA les asigna a cada uno las direcciones (bloques /8, RFC4632) que los RIR

pueden, a su vez, asignar.

Los RIR son “intermediarios” de IANA

Gestión del direccionamiento actualmente (y II)

Se procura montar una estructura en la que se aplica subnetting y supernetting según sea preciso. Por ejemplo:

• U. Sevilla:193.147.160.0 – 193.147.179.255: 193.147.160.0/20; 193.147.176.0/22 • Fund. H. Alcorcón: 193.147.180.0 – 193.147.183.255: 193.147.180/22 • U. Rey Juan C.: 193.147.184.0 – 193.147.184.255: 193.147.184.0/24 • U. Pablo de O. 193.147.185.0 – 193.147.191.255: 193.147.185.0/24; 193.147.186.0/23; 193.147.188.0/22 RedIRIS (AS766) RIPE NCC IANA IANA, cede 193/8; 194/8 y 195/8 a RIPE RIPE cede 193.144.0.0/14 a RedIRIS Rediris es un Sistema Autónomo a publica la red

193.144/14 como un todo. RedIRIS delega la gestión de determinadas redes a las Instituciones afiliadas. La información de estas redes es interna al AS766 TDE (AS3352) RIPE cede 195.57.0.0/16 a TDE Telefónica gestiona esa “clase B” a discreción. TDE es un Sistema Autónomo a publica la red

195.57/16 como un todo.

Pero, aunque los dos AS sean Europeos, las rutas pueden ser muy distintas

RESUMEN

•Actualmente se utiliza masivamente CIDR para routing. Aunque se sigue usando el concepto de “clase”

(especialmente C).

• Las clases A y B o bien se han dividido o agregado. • Es necesario un protocolo de rutado “sin clase”: RIPv2,OSPF…

Tablas de rutas en IP

• Todas las tablas de rutas se representan mediante la IP de la red, la máscara y el siguiente salto. Pero la forma de “ver” esto varía de sistema operativo en sistema operativo.

Destination Mask Gateway Device […] 192.168.128.0 255.255.255.0 192.168.128.1 hme2 150.214.6.0 255.255.254.0 150.214.7.10 hme1 224.0.0.0 240.0.0.0 150.214.7.10 hme1 default 0.0.0.0 150.214.7.1 127.0.0.1 255.255.255.255 127.0.0.1 lo0 Solaris: “netstat –nrv” 150.214.231.246 192.168.128.0/24 192.168.128.1 150.214.7.1 150.214.6.0/23 150.214.231.245 150.214.231.244/30 150.214.7.10 INTERNET

Gateway of last resort is 150.214.231.246 to network 0.0.0.0

C 150.214.6.0/23 is directly connected, FastEthernet1/0 C 150.214.231.244/30 is directly connected, FastEthernet0/0 S* 0.0.0.0/0 [1/0] via 150.214.231.246

CISCO: “show ip route”

Destination Gateway Genmask […] Iface 150.214.6.0 0.0.0.0 255.255.254.0 eth0 0.0.0.0 150.214.7.1 0.0.0.0 eth0

Linux: “netstat –nrv”

Destino de red Máscara de red Puerta de acceso Interfaz [...] 0.0.0.0 0.0.0.0 150.214.7.1 150.214.6.79 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 150.214.6.0 255.255.254.0 150.214.6.79 150.214.6.79 150.214.6.79 255.255.255.255 127.0.0.1 127.0.0.1 150.214.255.255 255.255.255.255 150.214.6.79 150.214.6.79 224.0.0.0 240.0.0.0 150.214.6.79 150.214.6.79 255.255.255.255 255.255.255.255 150.214.6.79 150.214.6.79 Puerta de enlace predeterminada: 150.214.7.1

Windows XP: “netstat –nrv”

En caso de duda, se selecciona la ruta en la que haya una mejor

Direcciones IP. Direcciones especiales

Dirección Significado RFC Usos

0.0.0.0/8 0.0.0.0/32

Un host en esta red / Este host en esta red. 1700 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 Direcciones privadas 1918 127.0.0.0/8 Interfaz de loopback 1700 169.254.0.0/16 Autoconfiguración 3927*

224.0.0.0/4 Multicast 3171 Conocida como clase D, se utilizan para multicast a nivel IP. 240.0.0.0/4 Reservado 1700 Conocida como clase E, su uso está reservado por IANA.

255.255.255.255 Broadcast

limitado 1700

SRC: 0.0.0.0

DST: 255.255.255.255 Se usa como dirección fuente si el

nodo no conoce su IP. P. ej. Peticiones DHCP. Red IP interna, usa libremente ese espacio de direcciones. Internet Estas direcciones nunca deben salir a Internet (deben filtrarse)

Se usan cuando quiero conectividad IP pero no

conexión directa a Internet. Por ejemplo, un router ADSL y una red local de una empresa

Ej: Dos ordenadores directamente conectados. Se usa cuando el nodo no tiene ni asignación manual

de IP ni hay servidor DHCP. No deben traspasar un router. (*): Proposed Standard

TCP / UDP IP1 Acceso al medio IP2 Cualquier IP en 127/8, vuelve al propio nodo que la origina, sin pasar por el medio físico.

Aplicación S: 10.3.4.10 _{D: 10.3.4.1}

El interfaz de loopback

permite usar IP sin acceder al medio físico. Jamás deben aparecer estas direcciones en una red pública o privada.

S: 127.0.0.1 D: 127.0.0.1 SRC: 150.214.7.8 DST: 255.255.255.255 Reenvío prohibido

Todos los nodos en la LAN aceptan esto:

Es una dirección de broadcast (destino) para “esta red”, no debe reenviarse nunca

Protocolo NAT

Principios generales

NAT (Network Address Translation): Definido en RFC3022, permite acceder a direcciones públicas desde direcciones privadas.

INTERNET (direccionamiento público) Dirección(es) pública(s) Direccionamiento privado (10.0.0.0/8)

• Las direcciones privadas a No pueden “salir” a Internet.

• NAT permite alterar el datagrama IP de forma que se utilicen (traducción) las direcciones públicas. • Modalidades:

• Básico: No se introducen cambios en los puertos, sólo se modifican las IP.

• Traducción de puertos (NAPT): Se introducen cambios en los puertos TCP/UDP en caso necesario.

• Estático: La traducción IPpriv <-> IPpub es siempre la misma.

• Dinámico: La traducción IPpriv <-> IPpub se hace “bajo demanda”.

1. 192.168.254.68 inicia una conexión a 150.214.7.5:25 (smtp) en TCP:

• Inicio de conexión, apertura activa: selección de puerto local: 1034. • Se envía un segmento con un socket origen basado en una IP privada. 2. El RT “frontera” detecta que la IP origen no es válida en Internet, debe cambiarla:

• Como se trata de una nueva conexión saliente (flags SYN en TCP)… • … apunta en una tabla la traducción que se va a realizar:

192.168.254.250 192.168.254.68 192.168.254.254 150.214.141.206 150.214.7.5 SRC: 192.168.254.68:1034 DST: 150.214.7.5:25 SRC: 150.214.141.206:1034 DST: 150.214.7.5:25

Protocolo NAT

Funcionamiento

NAPT (Network Adress Port Translation): Permite que muchos ordenadores accedan a Internet usando una única dirección pública (típico en ADSL/ Cable).

192.168.254.68:1034 150.214.141.206:1034

150.214.7.5:25

Socket origen (sin traducir) Socket origen (traducido)

Socket Destino

En el exterior se usa la IP pública del router.

Se almacena el socket original, para realizar la traducción de la respuesta.

No hace falta cambiarlo

1 2

3. 150.214.7.5 responde a la petición, desde SU punto de vista es 150.214.206 el ordenador que accede.

4. La respuesta llega al RT, es necesario realizar una traducción:

• Consulto en la tabla y busco: 150.214.7.5:25 (SRC) y 150.214.141.206:1034 (DST) 192.168.254.68 192.168.254.254 150.214.141.206 SRC: 150.214.7.5:25 DST: 150.214.141.206:1034 SRC: 150.214.7.5:25 DST: 192.168.254.68:1034

Protocolo NAT

Funcionamiento

Socket origen (sin traducir) Socket origen (traducido)

Socket Destino

SRC: 150.214.141.206:1034 DST: 150.214.7.5:25

150.214.7.5

Busco esto Traduzco a esto

• La traducción se hace modificando el campo DST, en este caso; antes era el campo SRC.. 3

NAT. Casos especiales

CASO 1: Coincidencia de puertos en el lado privado 192.168.254.250 192.168.254.68 192.168.254.254 150.214.141.206 150.214.7.5 192.168.254.68:1034 150.214.141.206:1034 150.214.7.5:25

Socket origen (sin traducir) Socket origen (traducido)

Socket Destino 150.214.7.5.25 150.214.141.206.1034 ESTABLISHED

192.168.254.68:1034 150.214.7.5:25 ESTABLISHED

¿Qué ocurre si se conecta a 150.214.7.5:25 y el s.o. elige como puerto local 1034?

El router NAT, deberá usar un puerto traducido que no esté en uso

150.214.7.5.25 150.214.141.206.1034 ESTABLISHED 150.214.7.5:25 150.214.141.206:1035 ESTABLISHED

Ve dos conexiones, desde puertos distintos pero desde la misma dirección

Se usa un puerto que (en el lado exterior) no esté en uso.

192.168.254.68:1034 150.214.141.206:1034

150.214.7.5:25

Socket origen (sin traducir) Socket origen (traducido)

Socket Destino 150.214.7.5:25 150.214.141.206:1035 192.168.254.250:1034 192.168.254.254 192.168.254.250 192.168.254.68 150.214.7.5 192.168.254.68:1034 150.214.7.5:25 ESTABLISHED 192.168.254.250:1034 150.214.7.5:25 ESTABLISHED

Es perfectamente posible que los dos ordenadores hayan elegido el mismo puerto local. 150.214.141.206

NAT. Casos especiales

CASO 2: Conexiones entrantes. NAPT estático.

192.168.254.250 192.168.254.68

192.168.254.254

150.214.141.206

Servidor web (apache), lo necesito visible desde el exterior.

DST:

150.214.141.206:80

Un usuario exterior (Internet) no sabe nada de la red interior, sólo conoce la IP pública.

Esa petición web va dirigida al router, no teniendo un servidor local instalado, debería rechazar (RST) la conexión.

Usar mapeo estático, determinadas peticiones entrantes se redirigen a un puerto y máquina internos

En 192.168.254.68:

• Apache (servidor web). Puerto 80/tcp

• Sendmail (servidor de correo). Puerto 25/tcp En 192.168.254.250:

• Programa P2P. Puerto 4662/tcp; 4665/udp

Socket local Socket destino Proto

150.214.141.206:80 192.168.254.68:80 TCP 150.214.141.206:25 192.168.254.68:25 TCP 150.214.141.206:4662 192.168.254.250:4662 TCP 150.214.141.206:4665 192.168.254.250:4665 UDP

Tabla de Mapeo estático

192.168.254.250 192.168.254.68 150.214.141.206 192.168.254.254 Para Internet, la dirección externa alberga todos estos servicios

• Las peticiones entrantes que estén en la tabla se redirigen a la IP y el puerto indicados.

• El resto se procesan localmente, considerando al router como el nodo final.

• Son estáticas: la traducción (en los dos sentidos) es directa (sin estados).

NAT. Consideraciones finales

Antes de hacer el reenvío es necesario: • Calcular checksum nuevo de IP.

• Calcular checksum nuevo de TCP (incluso si no cambio puertos).

Gestión de memoria • Abren cientos de conexiones TCP a Guardar el estado de todas.

• Efectúan muchas consultas UDP a No tienen estado, pero debo esperar respuesta por el mismo puerto.

• Con tantos nodos, es posible que el numero de conexiones mal cerradas sea significativo a Necesito que el router se olvide de ellas.

Los router NAT requieren memoria suficiente para este tipo de conexiones, más bien “explosivas”, se requiere limpiar las conexiones que no se han cerrado correctamente, liberar correctamente la memoria, etc

Deben funcionar 7x24 durante todo el año a Pequeños fallos

acabarán dando la cara.

Niveles superiores

ICMP ?

• No sabemos a quién

entregarlo, porque ICMP viaja directamente sobre IP

• La información relevante “viaja” en el campo de datos ICMP: Los primeros bytes del datagrama problemático

A veces es necesario acceder más allá de TCP/UDP. Ejemplo:ICMP

El router debe acceder a los datos ICMP para saber qué hacer con ese ICMP

Además: Es necesario regenerar totalmente los datos ICMP, dado que los datos que contiene no son válidos dentro de la red interna (contienen la IP externa del router).

Cualquier nivel superior que incluya datos de IP o puertos, debe ser revisado y traducido para que funcione con NAT. ICMP y FTP son los ejemplos más típicos.

Multicast

Transmisión de video unicast

• La transmisión de video supone un ancho de banda considerable.

• Usando técnicas unicast como la de la figura, el uso de red y recursos del servidor de video es proporcional al numero de clientes.

Multicast

Transmisión de video Multicast

• Con un sistema multicast la carga del servidor de video es la de un solo nodo.

• El video se transmite con un sistema de “multidestino” de forma que llegue a varios nodos a la vez.

Multicast. ¿Qué necesito?

• Direcciones multicast a nivel IP: 224.0.0.0 a 239.255.255.255

• Cada dirección se refiere a un propósito (~aplicación) y no a un nodo. • Cada dirección se registra (IANA) para un uso.

• Algunos rangos se reservan para su uso en una organización. • 224.0.0.0/24: Reservadas para usos concretos, no rutables.

• Un nodo debe poder indicar que quiere recibir tráfico multicast, y que quiere dejar de recibirlo (IGMP).

• Debe existir un protocolo de routing específico: • Distinto de IGMP (que lo usan los clientes).

• Específico y distinto de los protocolos de routing para trafico unicast. • Es necesario establecer una relación entre la dirección multicast IP y la dirección multicast de nivel 2.

Multicast.

Direcciones MAC e IP

• ¿Qué direcciones MAC uso? (Broadcast es malo). • ¿Cómo construyo las direcciones?

F ue nte : CCIE Rout ing an d S w itc hi ng O ff ic ial E x am Cer ti fi c ati on G ui de , S ec on d E di ti on

• Está reservado el OUI 01:00:5E para este proposito.

• El bit marcado como 3 siempre va a cero, los 23 bits restantes (24-1) se copian directamente de los 23 bits menos significativos de la dirección IP.

• Al generar tráfico multicast, con destino una IP multicast, se usa siempre la dirección MAC multicast que se obtiene.

Multicast

IGMPv2

Fuente: CCIE Routing and Switching Official Exam Certification Guide, Second Edition

• IGMP: Internet Group

Management Protocol (3376), mostramos 2236

•Se usa para que los nodos puedan “unirse a determinado tráfico”.

• Va sobre un datagrama IP con TTL=1.

• Membership query: Lo genera el router para preguntar si alguien quiere unirse a un grupo multicast (0.0.0.0) o a determinado grupo multicast (IP_Multicast). Se usa como IP destino 224.0.0.1 (luego todos los sistemas multicast deben escuchar aquí, a nivel MAC e IP). Se genera cada cierto tiempo (para saber si sigue siendo necesario enviar tráfico). En MRT se pone el tiempo máximo de respuesta.

• Membership report: Lo genera un nodo cuando recibe lo anterior o, por iniciativa

propia si desea unirse a determinado tráfico. En el campo grupo se pone la IP multicast deseada. Se usa la IP destino del grupo multicast al que se quiere asociar o al que se está asociado.

• Leave group: Indica (un nodo) que ya no desea recibir tráfico de ese grupo, se usa la dirección 224.0.0.2 (todos los router multicast). El RT comprobará (query) que no queda nadie antes de parar.

Multicast

Consideraciones finales

• IGMP no se usa entre routers, cada router debe gestinonar el tráfico

multicast de otra forma.

• Los switches tienen que implicarse:

– Deben soportar IGMP para hacer el reenvío sólo a través de los puertos que sea preciso.

– Si no lo hacen, o no funciona nada o desbordo la red al considerar el tráfico ese multicast de la misma forma que el broadcast.

IPv6. Introducción

• Surge de la escasez de direcciones IPv4.

• Se plantea como un nuevo protocolo que:

• Mejore el direccionamiento (128-bits).

• Configuración (de nodos) más sencilla.

• Rediseño de la cabecera (más simple que IPv4).

• Incluye prestaciones de QoS.

• Incluye seguridad (similar a IPsec de IPv4).

• Facilita la movilidad.

• Su desarrollo coincide con CIDR/VLSM/Agregación (1992-1993) y con

NAT (1994)

a

IPv4 está durando más de lo que se pensaba.

IPv6. Formato de la cabecera

Fuente: W. Stallings, Data and Computer Comunications, 7ed.

Version: Indica la versión del protocolo IP (en este caso 6). Mismo sitio que en IPv4.

DS: Tipo de tráfico, sirve para distinguir entre distintas prioridades de tráfico; una especie de QoS. En el RFC2460 este campo se llama “Traffic Class” con idéntico significado.

ECN: Explicit Congestion Notification, no es parte del RFC oficial, es una propuesta de notificación de congestión. En el último RFC de IPv6 este campo no existe (se anexiona a Flow label) sin significado propio. Flow Label: Permite etiquetar trafico para un tratamiento diferenciado, OJO que no es lo mismo que DS / Traffic Class.

Payload Length: Indica la longitud de campo de datos del datagrama, incluye las posibles cabeceras de extensión. Si es cero, tengo un Jumbograma.

Next Header: Indica la próxima cabecera, el funcionamiento se ve luego. Hop Limit: Número máximo de saltos (como el TTL de IPv4)

Source Address y Destination Address: Direcciones fuente y destino del datagrama (128bits).

La cabecera más pequeña es de 40 bytes (20 eran en Ipv4). Se busca un alineamiento de 64 bits para mejorar la eficiencia.

IP v6. Extensión de la cabecera

Cabecera básica de IPv6 (Sig. Cab= ext1)

Cabecera ext1 (Sig. Cab= ext2)

Cabecera ext n

(Sig. Cab= proto) DATOS

Payload Length

…

• Cada cabecera indica el identificador de la siguiente cabecera o bien el protocolo de nivel superior.

• Deben aparecer en un orden determinado:

1. Opciones salto a salto.

2. Opciones para el destinatario (*) 3. Encaminamiento

4. Fragmentación 5. Autentificación 6. Seguridad

7. Opciones para el destinatario (**) 8. Datos de nivel superior

Cabecera básica de

IPv6 (Sig. Cab= TCP) DATOS Ejemplo 1: Sólo se envían datos TCP:

Ejemplo 2: Se envían datos TCP y hay fragmentación: Cabecera frag

(Sig. Cab= TCP) Cabecera básica de

IPv6. Fragmentación (Header Id=44)

Next Header Reserved Fragment Offset Res MF

Identification

• Reserved: Se pone a cero en Tx (en ambos campos).

• Fragment Offset (13 bits): Posición (desde el comienzo de la siguiente cabecera) de este fragmento respecto del original (en bytes).

• MF (1 bit): Indica si hay (1) o no hay (0) más fragmentos detrás de este.

Parte no fragmentable Parte fragmentable Cabecera básica Cabeceras hasta encaminamiento Resto de cabeceras (no procesables en nodos intermedios) y datos Fragmento n

El next header de la última cabecera pasa a ser 44. Se añade la cabecera de fragmentación (una

por fragmento)

Se modifica Payload Length al valor del datagrama fragmentado

• El destino reensambla los fragmentos y elimina la cabecera de fragmentación. • Los nodos intermedios NO fragmentan.

IP v6. Direccionamiento

• Son direcciones de 128 bits y se representan de esta forma (en

hexadecimal, grupos de 16 bits, separados por “:”):

2001:0720:0c10:0009:0000:0000:0000:0004 (dns2.cica.es)

• Como puede ser tedioso su manejo, se puede:

a) Eliminar los ceros a la izquierda:

2001:720:c10:9:0:0:0:4

b) Eliminar uno o más grupos de 16-bits a cero y sustituirlos por “::” SÓLO UNA VEZ:

2001:720:c10:9::4

• La representación de redes: 2001:0600::/23 (Rango asignado a RIPE que llega hasta justo antes de 2001:0800::).

IP v6. Direcciones unicast globales

Interface ID Subnet ID

Global routing prefix

• Si la dirección NO empieza en “000” (3bits) a Interface ID es de 64bits. • RFC 3513 (4291): Define el prefijo binario “001” para Unicast global (la antigua IPv4 pública, para entendernos) a 2000::/3.

• Todas las direcciones unicast globales tienen, por tanto, una parte de Interface ID de 64 bits.

Ejemplos de asignación (IANA)

RIPE tiene: 2001:1A00::/23, 2001:1C00::/22, 2001:2000::/20, …

Curiosidad: 2001:DB8::/32 está asignada como “NON-ROUTABLE”. Es el rango que se debe usar al escribir documentación sobre IPv6.

IPv6.

Direcciones unicast de enlace

• Se denominan (RFC4291 y anteriores) Link-Local IPv6 Unicast Addresses y tienen este formato:

Interface ID (64 btis) 1111 1110 10 000…000

54 bits 10 bits

• Se activa “sóla” al arrancar el ordenador; se configura automáticamente. • Tiene significado local, no es “rutable”.

• Sirve para las peticiones de vecino y router. • Es la red: fe80::/10

IPv6.

Generando EUI64 desde una dirección MAC 802.3

• En RFC4291 aparece un ejemplo; permite convertir la dirección de 48-bits de 802.3 en un identificador de 64 bits (para usarlo como identificador de Interface). 00 13 8F 52 2D B0 Dirección MAC: 00 13 8F OUI: _{52 2D B0} FF FE Se añade siempre esto: 00000000 _{Cambio el} bit U/L 00000010 02 13 8F FF FE 52 2D B0 ID Interface:

IPv6

Unique Local IPv6 Unicast Address

• Su uso original está obsoleto (RFC3879 y 4291), se usaban para Intranets y se llamaban Unicast de sitio.

• En RFC4193 se definen las direcciones únicas unicast locales (o direcciones IPv6 locales).

• Son direcciones que:

– Probablemente son únicas.

– Prefijo conocido (filtros): FC00::/7.

– Permite unir dos redes de este tipo sin redireccionamientos. – Se tratan como si fueran globales.

– No causan conflictos con direcciones globales.

Se genera de forma aleatoria, con baja

probabilidad de colisión. Interface ID Global ID (40 bits) 7bits L Subnet ID (16 bits) 1 bit: por ahora se pone “1”.

Subred, para crear 64ki redes, una vez asignado

Direcciones especiales

• Dirección no especificada: 0:0:0:0:0:0:0:0 a :: • Dirección de loopback: 0:0:0:0:0:0:0:1 a ::1

• Dirección IPv4 mapeada a IPv6: 0:0:0:0:0:FFFF:w.x.y.z a ::FFFF:w.x.y.z • Direcciones Multicast: Group ID Flags (4 bits) FF Scope (4 bits) 0RPT

• Flags: T indica si es una dirección conocida (IANA) (0) o no (1).

• Scope (ámbito): 1 es interface; 2 es link-local; 5 es site-local y F es global. • Group ID: Identifica el grupo de destinatarios.

FF02::1 todos los nodos locales. FF05::1 todos los nodos del sitio. FF02::2 todos los routers locales. FF05::2 todos los routers del sitio

ICMPv6

• Se define en el RFC4443, como un mecanismo similar a

ICMPV4, viaja dentro de un datagrama IPv6 con NH=58.

• Los mensajes tipo <=127 son de error, el resto de

información. También tiene un campo de código.

• Son de error: Tipo=1 Destino no alcanzable; Tipo=2

Paquete muy grande; Tipo=3 Tiempo superado; Tipo=4

Problema parámetros.

• Tipos 128 y 129 son el echo-request y echo-reply

• En definitiva, hasta aquí es muy parecido al ICMP que

conocemos.

ICMPv6. Neighbor Discovery

• Definido en el RFC2461, realiza funciones similares a las de ARP. • Cada mensaje tiene un tipo (ICMPv6) mayor que 128.

•Usa direcciones multicast

• Permite obtener la dirección de N.E.D. de nodos y routers:

• Mediante el mensaje “Neighbor Solicitation” y “Neighbor Advertisement” • Permite obtener datos de la red: router y prefijo de red (los 128-64 primeros bits de la dirección).

IPv6. Misc

• IPv6 tiene un protocolo de autoconfiguración, basta con “enchufar y listo” pero también se puede usar DHCPv6.

• Existe el problema de la transición (RFC4038): • Las aplicaciones podrán ser IPv4 y/o IPv6. • Las pilas podrán ser simples o dobles.

• Casos especiales:

• Aplicaciones IPv4 en sistemas con pilas dobles. • Aplicaciones IPv6 en sistemas con pilas dobles.

• La evolución será lenta, con una pervivencia de ambos sistemas durante mucho tiempo.

• En los sitios donde ya se ha implementado IPv6, se usan traductores para conectarse con el mundo IPv4.