Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

NDP - Caso Microsoft & GNU/Linux

Explicación del mecanismo de una red con equipos variados con S.O. GNU/Linux y S.O. de Microsoft
by

Raul Fuentes

on 8 April 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of NDP - Caso Microsoft & GNU/Linux

Ing. Raúl Armando Fuentes Samaniego ( @RFuentess)
NDP - Caso Microsoft & GNU/Linux
photo (cc) Malte Sörensen @ flickr
SLAAC (oficial)
Elementos claves
Link-Local (FE80::/10 )
EUI-64 | Pseudo-aleatorio
DAD
Router Discovery (R & S)
Neighbor Socicitation (R & S)
Stateless Adress Autonconfiguration
0. Habilitar interfaz (primera vez)
1. Auto-Configuración (FE80::/10) y (DAD)
2. Router Discovery
3. Router Adverstiment
4. Default Router Neighbor Discovery (Request)
5. Default Router Neighbor Discovery (Reply)
6. DAD para cada dirección no local.
NDP del RFC 4861
Paso 0 y 1
Solo la primera vez que se activa
la computadora
El paso 2 lo realizan todos pero no tendrán
respuesta.
Al no existir ningún enrutador solo el ultimo paso se realiza si hay configuración estática.
Para comunicarse entre ellos deberán primero enviar un "Neighbor Request" previo, aún si es ICMP
Los tipos de mensaje que utiliza son:
Unicast (Punto-a-Punto)
Multicast ( FF02::2 )
Non-Broadcast Multiple Access (NMBA)
(2005)
SLAAC (Microsoft)
Estados de una dirección en Windows
Pasos de Auto-configuración
En proceso de validar que sea única (DAD).
Validada y totalmente funcional
Funcional pero ya en deshuso.
Ya no responde el nodo ante esta dirección
Los mensajes de "Router Advertisement" controlan estos tiempos.
Dirección tentativa basado en la FE80::/64
DAD para validarla.
Si falla el DAD se asume que la dirección es valida y unica. Se genera y registra el SNMB.
El host envía un "Router Solicitation"
Si el mensaje de "Router Advertsiment" se recibe se toman los datos.
Se usan los 64 bits ya conocidos en cada prefijo recibido y se aplica un DAD.
Lo mismo pero con otras técnicas...
Ligas de interés
Ligas en formato QR
ICMPV6
Web interactiva que proporciona los RFC en los que se ven involucrado cada elemento de ICMPv6.
La dirección tentativa se hace de trasfondo
El primer mensaje enviado es uno del tipo "ICMPv6 Multicast Listener Report Message V2"
El segundo enviado es del tipo LLMNR
Una vez enviado el LLMNR puede recibir los mensajes del tipo "ICMPv6 Neighbor Solicitation/Adverstiment"
Paralelo (por diseño de Microsoft) se envía el mensaje "ICMPv6 Router Solicitation"
Microsoft utiliza el protocolo LLNMR para los primeros pasos de NDP asumiendo que no se topara con duplicados (En términos de ellos "ahorramos tiempo con este método").
Tipos de mensajes
Unicast (Punto-a-Punto)
Multicast All-Routers ( FF02::2 )
Multicast DNS& LLMNR (FF02::1:3)
Multicast All-MLDv2-routers (FF02:1:16)
Non-Broadcast Multiple Access (NMBA)
Direcciones Multicast
Web de la IANA donde están registradas las direcciones multicast actuales con sus respectivos RFC.
En realidad esto viene como un intento de protegerse contra "sweeping" (Escaneos) de fuerza bruta" al crear dos direcciones.
¿Por que darle tiempo de vida?
Microsoft también utiliza LLMNR para los demás servicios que ofrece. (WPAD, ISATAP, queries de dominios)
Paralelamente a SLAAC se ejecutan también las solicitudes de DHCPv6. (Con dirección origen de SLAAC)
Por lo mismo, realiza los 6 pasos de NDP simultáneamente...
Paso a pasito...
SLAAC Microsoft
1
2
Conectamos la primera PC
DAD (la auto-asignación es invisible)
Envio de Neighb Solc Origen invalido (::)
Multicast list Report V2 ( FF02::16) de forma períodica.
Mensajes LLMNR ( FF02::1:3 )
Mensajes DHCPv6 ( FF02::1:2 )
Conectamos la segunda PC
Se comporta exactamente igual que la primera.
PC1 sabe de la existencia de PC2 por el primer mensaje .
Ambas computadoras se quedan enviando los mensajes de LLMNR & DHCPv6.
Ping de PC1 a PC2
Previo al ping la tabla de vecino de PC2 esta incompleta, no ha habido ningún mensaje de "Neighbor Solicitation/Adverstiment" por parte de PC1.
Previo al ping PC1 confirma la existencia de PC2 con un mensaje.
Posterior al ping PC2 conoce a PC1 .
NOTA (Mensajes Unicast)
Antes de enviar cualquier mensaje IPv6 (inclusive ICMPv6) se confirma la existencia del nodo destino.
3
Y ahora la tercera computadora...
La situación es exactamente igual...
PC1 y PC2 conocerán de la existencia de PC3 ...
PC3 no conoce a nadie
Juguemos con los pings...
PC3 a PC2: PC3 descubre la existencia de PC2(igual que antes)
PC1 a PC2: PC3 descubre la existencia de PC1
Neighbor Adverstiment:
MULTICAST
4
Conectemos el enrutador...
Cisco-Router se identifica como vecino.
A continuación envia el famor "Router Adverstiment"
PC1, PC2 y PC3 configuran su Gateway
En S.O.s Microsoft inician dos eventos...
Direcciones de privacidad y de prefijos
PC1, PC2, PC3 se asignan las direcciones por prefijo repitiendo los casos anteriores y el DAD.
Además se asignan direcciones de privacidad (Temporales) tanto en sus FE80 como nuevas.
Durante este proceso probablemente todos se auto-descubren pues ven sus mensajes de DAD entre ellos.
Servidores DNS (FEC10::/8 )
Estos 3 servidores han estado desde el inicio de este ejemplo, pero no es hasta que esta el gateway que se intentan resolver nombres de dominio.
NOTA
La tabla de vecino es con FE80::/10 no con otros prefijos.
Genera demasiado tráfico basura
Redes con HUB no soportan este tráfico.
Elemento legacy del draft.
5
Conectamos PC4 a una red bien configurada...
DAD (la auto-asignación es invisible)
Envío de Neighb Solc Origen invalido (::)
Envío de Router advertsiment
Recibo de respuesta del router
DAD por cada prefijo (y direcciones de privacidad).
Por lo anterior PC4 descubrirá lentamente a sus vecinos.
2003 -2005 (?)
SLAAC ( GNU/Linux )
USAGI
Los S.O. basados en Linux utilizan la implementación del proyecto USAGI ( UniverSAl playGround for Ipv6 )
Al igual que el caso Microsoft no utilizan per-se los pasos de NDP (misma razón de fechas).
Unicast (Punto-a-Punto)
Multicast All-Routers ( FF02::2 )
Multicast All-MLDv2-routers (FF02:1:16)
Non-Broadcast Multiple Access (NMBA)
Solicited Node Multicast Address (SNMA)
Tipos de mensajes
Pasos de Auto-configuración
Dirección tentativa basado en la FE80::/64 (EUI-64)
DAD para validarla.
Si falla el DAD se asume que la dirección es valida y única. Se genera y registra el SNMA (después de cierto tiempo).
El host envía un "Router Solicitation"
Si el mensaje de "Router Advertsiment" se recibe se toman los datos.
Se usan los 64 bits ya conocidos en cada prefijo recibido y se aplica un DAD.
Diferencias claves
No implementa DHCPv6 por defecto.
No implementa servidores DNS (FEC0::/8).
Los vecinos se mantienen por un tiempo muy corto en la tabla de vecino de cada nodo.
Implementa EUI-64 para enlaces locales y crea direcciones de privacidad (o temporales) para los prefijos globales
Paso a pasito...
SLAAC GNU/Linux
1
2
Conectamos la primera PC
DAD (la auto-asignación es invisible)
Multicast list Report V2 ( FF02::16) de forma periódica.
Envio de "Neighbor Solicitude" con origen valido y destino all-nodes (FF02::2).
Envío de "Router Solicitation"
Conectamos PC2 y PC3
Se comporta exactamente igual que la primera.
PC1 no guardara registros de PC2 (es eliminado de su tabla rápidamente)
Ambas computadoras se quedan enviando los mensajes de LLMNR.
Ping de PC1 a PC2
Un elemento clave de la implementación de USAGI es la corta vida de nodos descubiertos mediante Multicasting.
Los nodos que se descubren por mensajes unicast prácticamente solo estarán en la tabla mientras dure la comunicación.
NOTA (Mensajes Unicast)
Antes de enviar cualquier mensaje IPv6 (inclusive ICMPv6) se confirma la existencia del nodo destino.
3
Conectemos el enrutador...
Cisco-Router se identifica como vecino.
A continuación envia el famor "Router Adverstiment"
PC1, PC2 y PC3 configuran su Gateway
En S.O.s utilizando USAGI ocurre solo un evento:
Direcciones de privacidad y de prefijos
PC1, PC2, PC3 se asignan las direcciones por prefijo repitiendo los casos anteriores y el DAD.
Además se asignan direcciones de privacidad (Temporales) en los prefijos globales.
NOTA
La tabla de vecino es con FE80::/10 no con otros prefijos.
NOTA:
4
Conectamos PC4 a una red bien configurada...
DAD (la auto-asignación es invisible)
Envío de Neighb Solc Origen invalido (::)
Envío de Router advertsiment
Recibo de respuesta del router
DAD por cada prefijo (y direcciones de privacidad).
PC4 conocerá a sus vecinos cuando tenga que dirigirse a ellos.
Solo el gateway es el único nodo que nunca
es borrado de la tabla de vecinos.
Algunos derechos reservados
Fin
El material gráfico fue tomado de distintos sitios de la Web.
Los pasos ejemplos de los casos Microsoft y GNU/Linux fueron realizados mediante capturas de paquetes con los S.O. Windows 7 y Ubuntu 11.02
Este trabajo está licenciado bajo Creative Commons Attribution-ShareAlike 3.0 Unported Unported. Para ver una copia de esta licencia, visita: http://creativecommons.org/licenses/by-sa/3.0/.
Link-Local Mulsticast Name Resolution
(FF02::1:3)
¿Que pasaría si hubiesen una dirección duplicada?
Full transcript