Tema 2. Direccionamiento IP y protocolos asociados

Transcripción

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

2 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). 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). A 0 B 10 C redes = hosts en cada red redes = hosts en cada red redes = 254 hosts en c/u

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) Se propone tomar prestados varios bits de la parte de host y anexionarlos a la parte de red. 16 bits (parte de host), pido prestados 8 bits 1 red con nodos 254 redes con 254 nodos 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 Nunca se puede usar la primera ni la última subred al hacer subnetting. Un nodo externo, no ve el subnetting, desde fuera sólo se ve la clase B número ( /16). El subnetting siempre desperdicia 2 hosts por cada subred y la primera y última subred completas (en este caso paso de tener a tener 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: o bien /24

4 Direcciones IP. Subnetting (ejemplo) Ejemplo: Dividir la clase A 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 es Si pedimos prestados 3 bits: Red Dirección de la red Dirección de broadcast Notación estándar Nodos en la red /11 IMPOSIBLE / / / / / / /11 IMPOSIBLE Antes (clase A): nodos. Ahora (subnetting): 6 redes con nodos = nodos Se pierde el 25% del direccionamiento

5 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: Máscara: 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 sino: IP <AND> Mask: 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. Ejemplo A) Dst: <AND> = Coincide con mi red: Está en mi red Ejemplo B) Dst: <AND> = NO coincide con mi red: NO está en mi red

6 Direccionamiento IP. Classfull /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) y (d) tendrán el mismo tamaño, se use o no. En los routers internos habrá hasta 254 entradas adicionales. a e /24 c d (e) es un desperdicio b

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

8 Ejemplo de Agregación (Supernetting) Ejemplo: RedIRIS, quiere direccionamiento para unos 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 > ), pero necesitaría 1024 líneas en la tabla de rutas (algo costoso). II) Escojamos lo siguiente: Desde a son 1024 clases C (antigüas clases C, para ser exactos) En binario, las fronteras de esas clases C son estas Byte 1 Byte 2 Byte Parte común en las 1024 redes (14 bits) 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 Usando máscaras de red: /14 Agrupo o agrego esas 1024 redes y las publico como una única ruta Esta parte varía red a red, igual que sucede con la parte host de una red cualquiera. Cómo? Propuesta: Hacer lo contrario que en subnetting. Supernetting: Pedir prestados bits de la parte de red, que se asimilan a la parte de host.

9 Gestión del direccionamiento actualmente (I) IANA (Internet Assigned Numbers Authority) IANA tenía, históricamente, el control de todo el direccionamiento IANA cede el control a los RIR AfriNIC (África) ARIN (NorteAmérica) APNIC (Asia/Pacífico) LACNIC (Latino América y partes del Caribe) RIPE NCC (Europa, Oriente Medio y Asia Central) 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

10 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: IANA, cede 193/8; 194/8 y 195/8 a RIPE RIPE cede /16 a TDE IANA RIPE NCC TDE (AS3352) Telefónica gestiona esa clase B a discreción. RIPE cede /14 a RedIRIS RedIRIS (AS766) Rediris es un Sistema Autónomo a publica la red /14 como un todo. TDE es un Sistema Autónomo a publica la red /16 como un todo. Pero, aunque los dos AS sean Europeos, las rutas pueden ser muy distintas RedIRIS delega la gestión de determinadas redes a las Instituciones afiliadas. La información de estas redes es interna al AS766 U. Sevilla: : /20; /22 Fund. H. Alcorcón: : /22 U. Rey Juan C.: : /24 U. Pablo de O : /24; /23; /22 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

11 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. Gateway of last resort is to network / / /24 C /23 is directly connected, FastEthernet1/0 C /30 is directly connected, FastEthernet0/0 INTERNET S* /0 [1/0] via CISCO: show ip route Destino de red Máscara de red Puerta de acceso Interfaz [...] Puerta de enlace predeterminada: Windows XP: netstat nrv Destination Gateway Genmask [ ] Iface eth eth0 Linux: netstat nrv Destination Mask Gateway Device [ ] hme hme hme1 default lo0 Solaris: netstat nrv En caso de duda, se selecciona la ruta en la que haya una mejor coincidencia de máscara (más unos).

12 Direcciones IP. Direcciones especiales Dirección Significado RFC Usos / /32 Un host en esta red / Este host en esta red Se usa como dirección fuente si el nodo no conoce su IP. P. ej. Peticiones DHCP. SRC: DST: / / /16 Direcciones privadas 1918 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 Internet Estas direcciones nunca deben salir a Internet (deben filtrarse) Red IP interna, usa libremente ese espacio de direcciones /8 Interfaz de loopback 1700 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: S: D: Aplicación D: IP1 TCP / UDP IP2 Acceso al medio Cualquier IP en 127/8, vuelve al propio nodo que la origina, sin pasar por el medio físico /16 Autoconfiguración 3927* Se usa cuando el nodo no tiene ni asignación manual de IP ni hay servidor DHCP. No deben traspasar un router. (*): Proposed Standard Ej: Dos ordenadores directamente conectados /4 Multicast 3171 Conocida como clase D, se utilizan para multicast a nivel IP /4 Reservado 1700 Conocida como clase E, su uso está reservado por IANA Broadcast limitado 1700 Es una dirección de broadcast (destino) para esta red, no debe reenviarse nunca Reenvío prohibido Todos los nodos en la LAN aceptan esto: SRC: DST: Esta tabla muestra algunas de las IP que tienen significado especial (a parte de las ya conocidas). RFC 3330

13 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 ( /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.

14 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) SRC: :1034 DST: : SRC: :1034 DST: : inicia una conexión a :25 (smtp) en TCP: Inicio de conexión, apertura activa: selección de puerto local: 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: No hace falta cambiarlo Socket Destino :25 Socket origen (traducido) Socket origen (sin traducir) : :1034 En el exterior se usa la IP pública del router. Se almacena el socket original, para realizar la traducción de la respuesta.

15 Protocolo NAT Funcionamiento SRC: : DST: : SRC: :25 DST: : SRC: :25 DST: : responde a la petición, desde SU punto de vista es el ordenador que accede. 4. La respuesta llega al RT, es necesario realizar una traducción: Consulto en la tabla y busco: :25 (SRC) y :1034 (DST) Busco esto Socket Destino :25 Socket origen (traducido) :1034 Socket origen (sin traducir) :1034 Traduzco a esto La traducción se hace modificando el campo DST, en este caso; antes era el campo SRC..

16 NAT. Casos especiales CASO 1: Coincidencia de puertos en el lado privado : :25 ESTABLISHED ESTABLISHED Socket Destino Socket origen (traducido) Socket origen (sin traducir) : : : Qué ocurre si se conecta a :25 y el s.o. elige como puerto local 1034? El router NAT, deberá usar un puerto traducido que no esté en uso Ve dos conexiones, desde puertos distintos pero desde la misma dirección ESTABLISHED : :1035 ESTABLISHED : :25 ESTABLISHED Es perfectamente posible que los dos ordenadores hayan elegido el mismo puerto local : :25 ESTABLISHED Socket Destino Socket origen (traducido) Socket origen (sin traducir) : : : : : :1034 Se usa un puerto que (en el lado exterior) no esté en uso.

17 NAT. Casos especiales CASO 2: Conexiones entrantes. NAPT estático. Un usuario exterior (Internet) no sabe nada de la red interior, sólo conoce la IP pública. DST: : Servidor web (apache), lo necesito visible desde el exterior. 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 Para Internet, la dirección externa alberga todos estos servicios En : Apache (servidor web). Puerto 80/tcp Sendmail (servidor de correo). Puerto 25/tcp En : Programa P2P. Puerto 4662/tcp; 4665/udp Socket local Socket destino Proto : :80 TCP : :25 TCP : :4662 TCP : :4665 UDP Tabla de Mapeo estático 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).

18 Aumento de latencia INTERNET (direccionamiento público) NAT. Consideraciones finales 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 A veces es necesario acceder más allá de TCP/UDP. Ejemplo: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 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.

19 Multicast 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. 3Mbps 1Mbps 1Mbps 1Mbps Servidor de video 2Mbps 1Mbps 1Mbps Transmisión de video unicast

20 Multicast 1Mbps 1Mbps 1Mbps 1Mbps Servidor de video 1Mbps 1Mbps 1Mbps 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.

21 Multicast. Qué necesito? Direcciones multicast a nivel IP: a 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 /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.

22 Fuente: CCIE Routing and Switching Official Exam Certification Guide, Second Edition Multicast. Direcciones MAC e IP Qué direcciones MAC uso? (Broadcast es malo). Cómo construyo las direcciones? 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.

23 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 ( ) o a determinado grupo multicast (IP_Multicast). Se usa como IP destino (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 (todos los router multicast). El RT comprobará (query) que no queda nadie antes de parar.

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

25 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 ( ) 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).

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

27 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 Ejemplo 1: Sólo se envían datos TCP: Cabecera básica de IPv6 (Sig. Cab= TCP) DATOS Ejemplo 2: Se envían datos TCP y hay fragmentación: Cabecera básica de IPv6 (Sig. Cab= 44) Cabecera frag (Sig. Cab= TCP) DATOS

28 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. Cabecera básica Cabeceras hasta encaminamiento Parte no fragmentable Fragmento n Se modifica Payload Length al valor del datagrama fragmentado El next header de la última cabecera pasa a ser 44. Se añade la cabecera de fragmentación (una por fragmento) Resto de cabeceras (no procesables en nodos intermedios) y datos Parte fragmentable El destino reensambla los fragmentos y elimina la cabecera de fragmentación. Los nodos intermedios NO fragmentan.

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

30 IP v6. Direcciones unicast globales Global routing prefix Subnet ID Interface ID 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.

31 IPv6. Direcciones unicast de enlace Se denominan (RFC4291 y anteriores) Link-Local IPv6 Unicast Addresses y tienen este formato: Interface ID (64 btis) 10 bits 54 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

32 IPv6. Generando EUI64 desde una dirección MAC En RFC4291 aparece un ejemplo; permite convertir la dirección de 48-bits de en un identificador de 64 bits (para usarlo como identificador de Interface). Dirección MAC: F 52 2D B0 OUI: F 52 2D B Cambio el bit U/L Se añade siempre esto: FF FE ID Interface: F FF FE 52 2D B0

33 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. 7bits L Global ID (40 bits) Subnet ID (16 bits) Interface ID 1 bit: por ahora se pone 1. Se genera de forma aleatoria, con baja probabilidad de colisión. Subred, para crear 64ki redes, una vez asignado el identificador global.

34 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: FF Flags (4 bits) Scope (4 bits) Group ID 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

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

36 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 primeros bits de la dirección). Mediante el mensaje Router Solicitation y Router Advertisement

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