Actividad 4 Evidencia 2

DIRECCIONES IPV6 Y DISPOSITIVOS DE RED ACTIVIDAD 4 – EVIDENCIA 2 Alumno: WILDER JEFRY GOMEZ RIVERA Profesor: ALEJANDRO

Views 295 Downloads 0 File size 79KB

Report DMCA / Copyright

DOWNLOAD FILE

Recommend stories

Citation preview

DIRECCIONES IPV6 Y DISPOSITIVOS DE RED ACTIVIDAD 4 – EVIDENCIA 2

Alumno: WILDER JEFRY GOMEZ RIVERA

Profesor: ALEJANDRO JOSE OROZCO NARANJO

SERVICIO NACIONAL DE APRENDIZAJE (SENA) CONFIGURACION DE DISPOSITIVOS ACTIVOS PARA SERVICIOS DE RED CON IPV6 BOGOTÁ D.C. 2019

1

Tabla de Contenido Ítem Actividades de transferencia de conocimiento....................................................3 1. Actividad 1.........................................................................................................3

2

Actividades de transferencia de conocimiento De acuerdo a los conocimientos aprendidos en el material de formación 2, el aprendiz estará en capacidad de dar respuesta y solución a los siguientes planteamientos: 1. Actividad 1 Investigue y explique con sus palabras ¿Cuál es la importancia del IPv6 en el internet de las cosas (IoT)? IMPORTANCIA DE IPV6 EN LA IOT (INTERNET-OF-THINGS O INTERNET DE LAS COSAS) Si analizamos detenidamente muchas de las soluciones IoT existentes actualmente, se concluye que, en sentido estricto, los dispositivos no son realmente parte de Internet. Por ejemplo, no tienen dirección IP. Además, los servicios WEB no se ofrecen desde los mismos dispositivos, sino desde pasarelas intermedias (gateways) o plataformas. Estas últimas son las que realmente están presentes en Internet y ofrecen los servicios a los usuarios. Por último, al no ser la comunicación entre los dispositivos y las pasarelas un estándar de Internet, han proliferado los protocolos y soluciones propietarias. No obstante, a medida que ha pasado el tiempo, las mejoras en la integración de componentes, consumo de energía y nuevos estándares ha evitado finalmente que abandonemos la idea que todos los dispositivos, incluyendo pequeños sensores a pilas, tengan dirección IP y ofrezcan sus propios servicios en la nueva WEB. Obviamente, para que haya direcciones suficientes no sirve IPv4, tiene que ser IPv6.

3

Así, recientemente, el IETF (Internet Engineering Task Force, la organización de estándares de protocolos de Internet) ha definido una alternativa en forma de estándar para que estos dispositivos estén realmente conectados a Internet, más concretamente a la Internet6. Se conoce con el nombre de “6LowPAN”, el IPv6 de las redes LowPAN (Low Power Area Networks). 6LowPAN se ha definido para trabajar sobre el estándar de redes radio IEEE 802.15.4. Este estándar permite topologías malladas (“Meshed networks”) inalámbricas. De esa manera, unos nodos pueden hacer uso de otros como repetidores o routers de sus mensajes para garantizar siempre la cobertura, y el envío y recepción de mensajes. En lo que respecta a la capa de servicios, lo lógico sería utilizar el omnipresente modelo de servicios REST, dado que existen muchas implementaciones, herramientas y experiencia por parte de los desarrolladores. Sin embargo, utilizar HTTP-REST en redes LowPAN presenta muchos inconvenientes, debido a que se emplea como transporte el protocolo TCP. El problema de TCP es que es un protocolo orientado a conexión y por tanto necesita mensajes de establecimiento y terminación (Three-wayhandshake). Además, al ser un protocolo de transporte fiable, realiza retransmisiones siempre que se pierde cualquiera de los datagramas en los que se ha divido la información que se va a transmitir. Por este motivo, el IETF ha definido CoAP, una nueva capa de servicio para entornos restringidos que conserva el modelo REST, pero utiliza UDP como capa de transporte. CoAP presenta una API idéntica a REST-http, es decir, el conjunto de operaciones CRUD (Create, Read, Update y Delete), pero el transporte se realiza sobre el

4

protocolo UDP, no orientado a conexión y no fiable.CoAP permite dos tipos de mensajes: confirmados y no confirmados. Los mensajes confirmados suponen una aceptación por parte del receptor (ACK), de tal manera que, si se pierden, se retransmiten un número limitado de veces. Los mensajes no confirmados se pueden emplear para aquellos casos en que es preferible perder la información periódica de algunos sensores, antes que saturar la red con retransmisiones, algo que no es posible con el modelo REST-HTTP. Con todo lo anterior hemos descrito la arquitectura completa de la “Web de las Cosas” para redes radio con topología mallada: 

IEEE802.15.4, para el nivel radio (capa física y de enlace, niveles 1 y 2 OSI).



6LowPAN, para el nivel de red (capa de red, nivel 3 OSI).



UDP: para el nivel de transporte.



CoAP: que ofrece una API REST y capacidades de reenvío para mensajes confirmados.

¿Se está posicionando la industria con implementaciones? Un ejemplo relevante es la bombilla controlable mediante smartphones Android anunciada por Google. Esta solución emplea tecnología 6LowPAN. En el siguiente diagrama se incluye un esquema de referencia de una bombilla similar publicado por el fabricante JennetIP. Otro conocido ejemplo es la bodega de vinos inteligente de Vinton Cerf (considerado padre de Internet) presentada en el CES de Las Vegas este mismo año y que se basa en dispositivos 6LowPAN.

5