A menudo se ha dicho que IPv6 e Internet de las cosas están fuertemente alineados, en la medida en que se afirman que son mutuamente dependientes. Un Internet de las cosas necesita el espacio de direcciones de protocolo expandido masivamente que solo IPv6 puede proporcionar, mientras que IPv6 necesita identificar un caso de uso convincente para proporcionar una base sustantiva para justificar los gastos adicionales asociados con un despliegue generalizado de este nuevo protocolo que solo Internet Las cosas pueden proporcionar. Un buen ejemplo de esta línea circular de argumento de dependencia mutua se encuentra en este informe ZDNet de la nueva “aplicación asesina” de IPv6.
Sin embargo, la evidencia que tenemos hasta ahora con pequeñas implementaciones de dispositivos autogestionados no proporciona una justificación convincente de este caso. Las implementaciones existentes de redes de sensores, dispositivos de autómatas y varias otras formas de microware no se están acumulando exactamente en Internet por miles de millones. Algunas implementaciones de dispositivos a gran escala utilizan las redes de datos celulares móviles y comúnmente encuentran IPv4 como un protocolo de superposición conveniente, generalmente disponible. Otros hacen uso de WiFi o una tecnología de campo cercano como Bluetooth, y a menudo es el caso una vez más, que IPv4 es un protocolo de comunicaciones de capa superior generalmente utilizado simplemente debido a su ubicuidad. Estos dispositivos a menudo se construyen e implementan dentro de un presupuesto de costo unitario final limitado, por lo que usar IPv4 es a menudo una simple opción pragmática de usar lo que está disponible a un costo unitario muy bajo.
La pregunta aquí es: ¿Internet de las cosas requiere IPv6 como una condición previa esencial, o vamos a continuar desplegando una población cada vez mayor de microdispositivos dentro del marco actual de compartir direcciones cada vez mayor en IPv4?
- 5 mbps es rápido en mi país. Pero luego leí que los estadounidenses tienen un promedio de 25 mbps, a veces llegando a miles. ¿Por qué es tan fuerte internet estadounidense?
- Cómo obtener la velocidad de Internet completa solo en mi aplicación VB .NET
- ¿Cómo se puede corregir la velocidad inconsistente de Internet?
- ¿Cuál es la velocidad de descarga de Internet en NIT Allahabad?
- ¿Puede xfinity aumentar la velocidad de mi internet?
¿Cuál es la foto de hoy? Las estimaciones varían enormemente, pero hay un cierto nivel de consenso detrás de una cifra de 10 a 15 mil millones de dispositivos conectados a Internet en 2016 que se encuentran en Internet IPv4. En este momento, Internet enruta unos 2.800 millones de direcciones IPv4 únicas, por lo que es una conclusión lógica que la mayoría de estos dispositivos conectados se encuentran detrás de unidades convencionales de traducción de direcciones de red (NAT), que permiten compartir una dirección en varios dispositivos simultáneamente. Es evidente que las cosas actuales en Internet de hoy no dependen de una red IPv6.
Pero eso puede no ser siempre el caso. ¿Qué otros factores son relevantes para la elección del protocolo para las cosas?
Pull vs Push
Parte del debate sobre esta pregunta se relaciona con la naturaleza de la Cosa incrustada y la forma en que se comunica dentro de su entorno externo.
Un modelo es un “modelo sondeado”, donde el dispositivo recopila datos y los retiene en alguna memoria local, y los devuelve a un controlador cuando se sondea (extrae). Este modelo encuestado de recopilación de datos requiere que el dispositivo sea el objetivo de las solicitudes de conexión del entorno externo más amplio. Este modelo de comunicación requeriría convencionalmente que cada cosa encuestada use su propia dirección IP pública asignada de forma única, ya que la cosa es objeto de un proceso de encuentro, en lugar del iniciador. Dados los considerables volúmenes de dispositivos que se contemplan en un Internet de las cosas, este modelo de operación encuestado parece requerir la familia de direcciones más grande proporcionada por IPv6, ya que los requisitos de direccionamiento simplemente no pueden sostenerse en IPv4.
Cuando consideramos modelos de sensores continuos, como las transmisiones de video de cámaras web o sensores ambientales de flujo continuo de datos, y también consideramos formas de recopilación de datos oportunistas “justo a tiempo”, entonces la capacidad de sondear los sensores cuando sea necesario se convierte en una importante activo para la función del sensor. Sin embargo, exponer un micro dispositivo desatendido a sondeos desde Internet tiene sus problemas relacionados con la seguridad y el abuso. Nuestra experiencia con tales dispositivos, particularmente cuando se utilizan modelos de acceso abierto, ha puesto de manifiesto el riesgo de que dichos dispositivos direccionables se vean obligados a participar en diversas formas de ataques DoS distribuidos. Si bien cada dispositivo solo puede integrarse para entregar un pequeño flujo de datos, la posibilidad de orquestar millones de tales vulnerabilidades en un ejército de ataque puede transformar dichos flujos a pequeña escala en ataques que pueden alcanzar cientos de gigabits. La cuestión de si el mayor espacio de direcciones de IPv6 previene efectivamente el descubrimiento oportunista de dispositivos sensores, o si la prudencia operativa requiere que tales sensores expuestos estén equipados con seguridad sólida y monitoreo y mantenimiento continuo, es actualmente un tema abierto para la industria de sensores. Pero tal vez no sea realmente una dicotomía justa en cualquier caso. Un consejo prudente indicaría que puede ejecutar, pero simplemente no puede ocultarse, incluso si está intentando ocultarse dentro del vasto espacio del identificador de interfaz de 64 bits. Se requiere seguridad robusta en el dispositivo en cualquier caso.
Entonces, si una cosa es una encuesta, y si la encuesta es oportunista, entonces el dispositivo necesitará su propia dirección pública, y en este caso, IPv4 es claramente incapaz de atender a dicho modelo. Si este es el paradigma para el Internet de las cosas, entonces está claro que solo podemos mantener ese entorno dentro de un grupo de direcciones masivo, y es aquí donde IPv6 tiene una ventaja indudable sobre IPv4.
Un modelo de informe de sensor alternativo es un modelo de “informe a base”, donde el dispositivo recopila datos e inicia periódicamente una conexión a su controlador y devuelve los datos recopilados a un controlador (push). Este segundo modelo funciona adecuadamente tanto en IPv6 como en un entorno de IPv4 y NAT, ya que el dispositivo inicia las solicitudes de conexión. En el caso de IPv4 y NAT, se le asigna el uso de una dirección pública solo por la duración de cada conexión push. Al mismo tiempo, este segundo modelo esencialmente “oculta” el dispositivo sensor de Internet externo, ya que no tiene ningún requisito para responder a solicitudes de conexión no solicitadas. Los NAT están bien alineados con este modelo, ya que la función NAT evita que agentes externos inicien cualquier forma de comunicación con el dispositivo.
Gran parte del trabajo realizado hasta la fecha en redes de sensores y entornos de aplicaciones similares para dispositivos automatizados integrados utiliza este modelo de conexión de “informe a base”, que permite que los dispositivos se ubiquen detrás de NAT y usen la red IPv4 existente y, como tal, estos los dispositivos no se suman al impulso para una implementación amplia de IPv6.
Cuantas direcciones
Para responder a esta pregunta, primero debemos responder la pregunta push vs pull. En un modelo pull, donde las cosas se analizan en un modelo esencialmente abierto (piense en un dispositivo en el mismo modo que un servidor web, donde cualquiera puede consultar el servidor), entonces hay un caso sólido de que necesitaremos una dirección IP única para cada cosa Obviamente, eso no funcionará en IPv4 para los 10 mil millones de cosas que creemos que ya están disponibles, y ciertamente tampoco funcionará para los próximos cien mil millones de dispositivos. Entonces, si se trata de un uso general de un modelo abierto de acceso de dispositivo, entonces es IPv6, claramente.
Sin embargo, la gran mayoría de las cosas en la red actual no utilizan pull. Es empujar. Y es empujar a través de NAT. Una forma de ver los NAT es que generan tokens de dirección únicos al tomar prestados campos de encabezado de paquete adicionales para ampliar el tamaño efectivo de la dirección. Al utilizar un campo de puerto TCP y UDP de 16 bits, se pueden generar hasta 65535 combinaciones únicas de dirección + puerto para cada dirección IP. En otras palabras, este enfoque puede expandir el espacio único de 32 a un máximo teórico de 48 bits. Actualmente utilizamos estos 48 bits para permitir que 10 mil millones de dispositivos se comuniquen. Eso es 48 bits para abarcar 34 bits de dispositivos.
No es posible usar los 48 bits del espacio, ya que los NAT no están asociados con todas las direcciones IPv4, pero claramente hemos podido recuperar 2 bits adicionales de espacio de direcciones. Los NAT se pueden hacer significativamente más eficientes utilizando la tupla completa de 4 direcciones y puertos como clave de búsqueda. Esto crea un espacio de búsqueda de 96 bits, y puede ser factible contemplar una red de 100 mil millones de dispositivos conectados (37 bits) en dicho entorno.
Por lo tanto, mientras el entorno esté dispuesto a seguir tolerando los NAT, y mientras los dispositivos tiendan a usar el modelo push para comunicarse a través de Internet externo, la escala de números que veremos en los próximos años para Internet de las cosas es No hay ninguna causa particular de alarma. Si la industria elige aplastarlos en NAT de 5 tuplas sobre IPv4, entonces probablemente sea factible hacerlo. Por supuesto, probablemente sería más fácil usar IPv6, pero esta no es la única consideración al pensar en protocolos IP en este contexto.
¿Qué otros factores influyen en la decisión sobre la selección del protocolo para tales dispositivos?
Plug and play – configuración automática
Otra parte del debate radica en la división de roles entre fabricación y despliegue. Del mismo modo que las direcciones MAC se cargan en un dispositivo Ethernet en el punto de fabricación del dispositivo, es tentador encontrar un mecanismo que cargue una configuración funcional en un dispositivo. El dispositivo se envía desde la fábrica en un estado completamente funcional, y en el campo, es un caso simple de solo proporcionar energía.
IP no admite fácilmente dicho modo de operación preconfigurada. La dirección IP de un dispositivo es en efecto una dirección de ubicación que permite que el sistema de enrutamiento de Internet comprenda la ubicación del dispositivo de dirección en relación con sí mismo. Todo lo que se puede colocar en el dispositivo en el punto de fabricación es un componente de identidad único, y el dispositivo debe “posicionarse” en su entorno y recopilar una dirección IP de su entorno local una vez que se enciende. Este es el caso independientemente del protocolo IP. Tanto IPv4 como IPv6 requieren ese paso de configuración local para la dirección IP.
Si bien el requisito es el mismo, los dos protocolos tienen un enfoque bastante diferente de cómo lograr el resultado requerido.
En el entorno IPv4, el mecanismo de arranque predeterminado es el Protocolo de configuración dinámica de host (DHCP), un resultado del protocolo BOOTP anterior. Es un protocolo simple y fácil de describir. Un dispositivo recién conectado envía una consulta de difusión en la red conectada localmente para un servicio DHCP. Los servidores DHCP en la red responden al cliente con una oferta de DHCP, que incluye los detalles de una dirección IP ofrecida y, por lo general, la dirección del enrutador de la subred, el sufijo de nombre de dominio local y los servidores de nombre de dominio, y su propio identificador. El cliente responderá con una solicitud de difusión de DHCP, indicando qué oferta de servidor ha sido aceptada. Cualquier servidor DHCP que también haya hecho una oferta al dispositivo ahora puede retirar su oferta y devolver la dirección IP a su grupo disponible. El procedimiento de configuración se completa con el servidor respondiendo con un reconocimiento de DHCP. Este intercambio simple de cuatro vías de DHCP se usa ampliamente en Internet como el medio predeterminado para la configuración del dispositivo de encendido. La ventaja de este enfoque es que un cliente recibe su dirección, máscara de subred, dirección IP de enrutador predeterminada, sufijo de nombre de dominio de subred y servidores de nombre de dominio en una sola transacción DHCP. La desventaja de este enfoque es que es un intercambio de paquetes no autenticado, y es susceptible a intrusos servidores DHCP intrusos en la red. La naturaleza de transmisión del intercambio de DHCP expone cualquier intento de entrometerse en la red, por lo que es un desafío realizar tal subversión en un modo sigiloso.
El entorno de configuración automática de IPv6 es diferente y existen varios mecanismos de arranque. La Configuración automática de direcciones sin estado IPv6 (SLAAC) parece una opción obvia, ya que involucra a los enrutadores locales en una red que anuncian periódicamente su dirección en una dirección de multidifusión IPv6 dedicada como un Anuncio de enrutamiento (RA), parte del Descubrimiento de vecinos IPv4 (ND) marco de referencia. Un nodo SLAAC escucha en esta dirección de multidifusión, y cuando ve un RA toma su identificador de interfaz local único y lo combina con el prefijo de 64 bits de la dirección IPv6 anunciada del enrutador en el RA para formar una dirección IPv6 local para esta interfaz de red .
La experiencia ha identificado algunas debilidades aquí. En primer lugar, está el problema de los RA no autorizados, en los que una red grande abierta o semiabierta, como los sistemas WiFi, puede incluir una serie de enrutadores rouge que proporcionan RA falsos. Por supuesto, uno podría usar Secure Neighbor Discovery (SEND) para intentar mejorar esta situación, pero si bien SEND puede evitar la manipulación, la pregunta original de autenticidad de la RA aún permanece. En segundo lugar, mientras que el sistema SLAAC permite que un enrutador genere sus direcciones de red locales e instale una ruta predeterminada de forma semiautónoma simplemente escuchando los anuncios del enrutador, el sistema no necesariamente incluye datos de configuración de nombre de dominio, y eso aún puede necesitar un paso de configuración por separado . Entonces esto introduce el tercer problema: elección. Hay una variedad de formas de realizar la configuración completa en IPv6. El primero es completar la configuración automática sin estado con dos opciones adicionales en IPv6 Neighbor Discovery (ND). Esto permitiría a un cliente descubrir tanto un enrutador como la configuración de DNS en los RA periódicos. La autenticidad sigue siendo un problema aquí, y las opciones adicionales realmente no ayudan a la pregunta básica de si una RA observada es auténtica o no. Otro enfoque es complementar SLAAC con un paso de configuración separado usando DHCP sin estado para IPv6, usando el paso DHCPv6 para cargar los parámetros DNS (sufijo de nombre de dominio local predeterminado y solucionadores recursivos locales). El cambio en DHCP aquí es cambiar del modelo de difusión IPv4 a un modelo de multidifusión IPv6 para solicitar un servidor DHCPv6 para responder con la información solicitada. Otra opción es evitar SLAAC y usar DHCPv6 para la totalidad del proceso de configuración automática, usando DHCPv6 de una manera que sea más directamente análoga a DHCP en IPv4 proporcionando tanto un arrendamiento de direcciones IPv6 como datos DNS.
Otra pregunta es si esta cosa que está intentando configurarse automáticamente es un dispositivo unitario o es en sí misma una pequeña red de cosas. Por ejemplo, un automóvil moderno evidentemente tiene unos pocos cientos de sistemas de procesador, y probablemente sea mejor pensar en el automóvil como una LAN móvil aspirante o incluso una colección de LAN discretas en lugar de un dispositivo móvil autopropulsado unitario en términos de red. Si ese es el caso, entonces podría tener sentido usar DHCPv6 en modo de Delegación de prefijo y asignar un prefijo IPv6 completo al dispositivo solicitante y luego permitir que el dispositivo controle sus propias subredes locales. Y, por supuesto, existen las posibilidades de utilizar un entorno de doble pila y complementar el prefijo IPv6 y la configuración de enrutamiento de SLAAC con un contexto DNS proporcionado por DHCP en IPv4.
La historia de las LAN discretas es relevante para la historia del análisis de vulnerabilidad de dispositivos tan complejos. Se informó que el sistema de entretenimiento se utilizó con éxito para penetrar en los sistemas de control de conducción de un vehículo. La respuesta lógica es considerar un vehículo como una colección de dominios de seguridad distintos, lo que a su vez puede conducir a la visión del vehículo como un conjunto de redes distintas.
Por lo tanto, hay una opción de opciones de configuración en IPv6, y no hay un mecanismo único disponible con seguridad. El problema aquí es solo eso: elección. En IPv4 es DHCP. En IPv6 es … complicado (tomar prestado un término de Facebook). La combinación de SLAAC y DHCPv6 sin estado para DNS tiene algún sentido, pero no puede estar seguro de que eso es lo que siempre obtendrá en el campo. Un dispositivo IPv6 debe ser flexible en el uso de modos de configuración automática y ser capaz de interoperar con SLAAC y ND, SEND, Stateless DHCPv6 o DHCPv6 PD. Es complicado.
Seguridad
Los modelos de seguridad para los dos protocolos probablemente no sean diferentes. Claro, un dispositivo IPv4 probablemente se encuentra detrás de un NAT y no puede ser sondeado y sondeado fácilmente por la avalancha de escáneres de direcciones IPv4. Pero estar detrás de un NAT no significa que deba confiar en las intenciones benignas de sus vecinos en la red privada local. Un host comprometido es una fuente potencial de ataque, y esto se cumple si el dispositivo está detrás de un NAT o no. Una suposición mucho más segura es que todas las interfaces externas son una fuente de ataque, independientemente de si el transporte utilizado en el ataque es IPv4 o IPv6. Por lo tanto, los NAT realmente no hacen la vida más fácil a este respecto, ni más difícil para el caso.
Para IPv6, esconderse detrás de la ley de números muy grandes no es defensa para otra cosa que no sea la criptografía (¡e incluso entonces no está claro que podamos escondernos allí para siempre)! Está claro que los escáneres eficientes de todo el espacio de direcciones no pueden funcionar en IPv6 de la misma manera que operan en el espacio de direcciones IPv4, y el descubrimiento oportunista de un dispositivo a través de su dirección IPv6 pública es estadísticamente improbable, pero las direcciones se filtra en una miríada de formas, y cada dispositivo debe asumir que recibirá tráfico hostil de sus interfaces de red.
Hay algunos principios básicos de operación segura para las cosas que pueblan el Internet de las cosas que son algo independientes del protocolo.
Todos estos dispositivos no administrados necesitan una forma de llamar a casa, y lo hacen de manera confiable y confiable. “Home” debe ser capaz de actualizar el dispositivo de manera totalmente desatendida, o en el caso final, debe poder apagar el dispositivo o cerrarlo en un estado seguro.
Todos los dispositivos deben ser paranoicos. La confianza es el resultado de la negociación, y la oscuridad es un mal sustituto de un marco de seguridad efectivo. Ya sea que el dispositivo esté conectado en IPv4 o IPv6, o en ambos, debe suponer que recibirá tráfico hostil o malicioso, y debe ser capaz de distinguir entre amigos y enemigos. Solo deben responder a transacciones que puedan autenticar, y responder de manera que no se pueda pervertir o deformar en un vector de ataque en otros.
El hecho triste es que la red de hoy está gravemente comprometida, y en el corazón de muchos de los ataques más viciosos de hoy hay millones de “cosas”. Al poblar Internet con más de ellos, este problema no desaparecerá. Todo lo contrario. Existe un riesgo claro de que creemos una red que sea insosteniblemente tóxica.
¿Qué necesitan las cosas? IPv4 o IPv6?
Millones de años de evolución biológica nos enseñan una gran lección aquí: la clave para la sostenibilidad de los sistemas complejos parece incluir flexibilidad y adaptabilidad. Las cosas deben ser capaces de sentir y adaptarse a su entorno y cumplir su función prevista utilizando los medios que están disponibles para ellos.
En muchos sentidos, este ya ha sido el camino de la informática en las últimas décadas. Los modelos originales de computación eran rígidos y orientados hacia una interfaz que combinaba con los sistemas simples de la computadora. Si alguien todavía recuerda el JCL de IBM, está bastante claro que JCL obligó al usuario a adaptarse a las limitaciones del sistema. La evolución posterior del medio ambiente ha producido sistemas que tienen una interfaz natural y elástica para los humanos. En estos días es posible dirigir un sistema a través de una ceja levantada, si eso es lo que realmente quieres. Esta evolución no solo aumenta la elasticidad y la adaptabilidad en la interfaz de usuario, sino que también agrega elasticidad y adaptabilidad a las interfaces de computadora y red que debemos utilizar.
¿Qué significa esto para Internet de las cosas?
No tiene sentido esperar a que un sustrato IPv6 ubicuo respalde sus necesidades.
Igualmente, no tiene sentido implementar algo que solo está equipado con IPv4 en estos días.
Por el momento, la respuesta más pragmática a la pregunta de qué protocolo IP cargar en una cosa es: ¡ambos!
