Embed Size (px)
Citation preview
Tema 2. Direccionamiento IP y
protocolos asociados
Ingeniería de protocolos
Curso 2012/13
Jaime Benjumea Mondéjar
Dpto. Tecnología Electrónica
(Univ. de Sevilla)
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).
C110…
B10…
A0…
C110…
B10…
A0…
11000000 01100100 01100010 11110101
192 100 98 245. . .
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 0000011010010110 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 123. . .
127 redes 16.777.216-2 = 16.777.214 hosts en cada red
00101100 11101100 00001100 00000011
44 236 123. . .
127 redes 16.777.216-2 = 16.777.214 hosts en cada red
00101100 11101100 00001100 00000011
44 236 123. . .
00101100 11101100 00001100 0000001100101100 11101100 00001100 00000011
44 236 123. . .
127 redes 16.777.216-2 = 16.777.214 hosts en cada red
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
Si pedimos prestados 3 bits: 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.
– Permitir el uso de clases C sin “explosión de rutas” (agregación)
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.
Byte 4
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
IANA cede el control a los RIR
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
coincidencia de máscara (más unos).
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
Esta tabla muestra algunas de las IP que tienen significado especial (a parte de las ya conocidas). RFC 3330
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”.
SE ESTUDIARÁ EL ESQUEMA MÁS COMPLEJO: NAPT dinámico.
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:25
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
4
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ón
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
1Mbps 1Mbps
1Mbps
1Mbps
2Mbps
1Mbps 3Mbps
Servidor
de video
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
1Mbps 1Mbps
1Mbps
1Mbps
1Mbps
1Mbps 1Mbps
Servidor
de video
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.
• Se implementa multicast en IP y en el nivel 2.
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.
• Es necesario que los dispositivos de nivel 2 (switches) se impliquen.
Multicast.
Direcciones MAC e IP
• ¿Qué direcciones MAC uso? (Broadcast es malo).
• ¿Cómo construyo las direcciones?
Fuente
: C
CIE
Routing a
nd S
witchin
g
Off
icia
l E
xam
Cert
ific
ation G
uid
e,
Second E
ditio
n
• 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.
• Los nodos harán caso, o no, a determinado tráfico multicast de nivel MAC.
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.
• Su implementación es irregular (en algunos sitios más que en otros).
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 (Sig. Cab= 44) DATOS
IPv6. Fragmentación (Header Id=44)
Next Header Reserved Res Fragment Offset 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
• Ejemplo: fe80::213:8fff:fe52:2db0
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 B0 2D Dirección MAC:
00 13 8F OUI: 52 B0 2D
FF FE
Se añade
siempre esto: 00000000 Cambio el
bit U/L 00000010
02 13 8F FF FE 52 B0 2D 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
el identificador global.
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.
• Nuevas funcionalidades (MLD, ND, PMTU).
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).
• Mediante el mensaje “Router Solicitation” y “Router Advertisement”
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.
