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
110…B
10…A
0…C
110…B
10…A
0… 11000000 01100100 01100010 11110101 192 . 100 . 98 . 2452.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 . 3
127 redes 16.777.216-2 =16.777.214 hosts en cada red
00101100 11101100 00001100 00000011
44 . 236 . 12 . 3
127 redes 16.777.216-2 =16.777.214 hosts en cada red
00101100 11101100 00001100 00000011
44 . 236 . 12 . 3
00101100 11101100 00001100 00000011
00101100 11101100 00001100 00000011
44 . 236 . 12 . 3
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
192.168.254.68:1034 150.214.141.206:1034 150.214.7.5:25Socket 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
Aumento de latencia INTERNET (direccionamiento público) Proceso de traducciónAntes 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
1Mbps 1Mbps 1Mbps 1Mbps 2Mbps 1Mbps 3Mbps Servidor de videoTransmisió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
1Mbps 1Mbps 1Mbps 1Mbps 1Mbps 1Mbps 1Mbps Servidor de videoTransmisió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.