Problemas de TCP/IP

Jack C. Louis y Robert E. Lee de la empresa de seguridad Outpost24 informaron el dia 2 de este mes de un problema genérico del protocolo TCP.

El problema fue encontrado de casualidad cuando realizaban un test de vulnerabilidad a unas maquinas.

Por error, al programar su propia pila TCP/IP, y una vez habian establecido una conexión TCP “atacante” y “victima” (Despues de SYN, ACK y SYN/ACK), el atacante le mandaba un falso error de “Buffers llenos” asi que la victima espera a que el atacante libere sus buffers (cosa que no hará).

De esta manera es posible crear un ataque DoS sin apenas usar recursos creando muchas sesiones y manteniendo a la victima en espera, sin consumir recursos ya que realmente el error de buffer lleno es falso, para colapsar a la victima.

Por ahora este problema no tiene solución, salvo bloquear conexiones de una máquina atacante, pero aun así sigue siendo vulnerable a un ataque DDoS.

Enlace de referencia:
http://seguridaddescifrada.blogspot.com/2008/10/sockstress-dos-encontrado-en-la-pila-de.html

Enlaces de interes:
Ataque DoS: http://es.wikipedia.org/wiki/Ataque_de_denegaci%C3%B3n_de_servicio

Ataque DDoS: http://es.wikipedia.org/wiki/DDoS

AGOTAMIENTO DE DIRECCIONES IP PUBLICAS
Un problema típico que tiene IPv4 es que se están agotando las direcciones
IP públicas.

IMPLEMENTACION EN LA QUE SE PRODUCE
Al existir tantas máquinas conectadas a la red, se produce un agotamiento de
direcciones. Ordenadores de sobremesa, teléfonos móviles, dispositivos integrados, host virtuales…
Las direcciones IPv4 solamente disponen de 32 bits.

SOLUCIONES
Una solución es que varios ordenadores de una red de área local (LAN) puedan
compartir una única dirección IP pública en Internet (NAT)
Otra de las alternativas, aunque se está implantando muy lentamente, es el
IPv6.

VENTAJAS Y COMO SE CONSIGUEN
IPv6 está previsto que sea la solución a largo plazo para la escasez de direcciones IPv4.
IPv4 utiliza 32 bits, mientras que IPv6 utiliza para las direcciones 128 bits, lo cual
aumenta considerablemente las combinaciones.

http://es.wikipedia.org/wiki/Agotamiento_de_las_direcciones_IPv4

Cuando hablamos de vulnerabilidades del protocolo TCP/IPv4 debemos hablar de unas de las primeras conocidas (ya por la década de los 80 era discutida aunque solo de forma teórica): el IP Spoofing.
El IP Spoofing consiste en un atacante haciendo pasar por otra maquina que no es la suya realmente. Esto se consigue porque el protocolo TCP/IPv4 asume que la dirección IP recibida en el paquete, es la misma que la IP de la maquina que lo envía, no se realiza ningún tipo de autenticación, y por lo tanto el atacante puede falsear esa la IP de origen fácilmente. El error es más grave aún si tenemos en cuenta que muchos protocolos o aplicaciones de capas superiores hacen la misma suposición.
Por otra parte debemos tener en cuenta que este ataque por si solo únicamente conseguiría establecer una conexión unidireccional con el receptor, ya que éste enviaría la información a la dirección IP que ha sido falseada y no a la real del atacante, por lo tanto este ataque debe combinarse con otro si el objetivo del atacante es establecer comunicación completa con el host remoto.
Otro uso de este ataque muy extendido es el de denegación de servicio, ya que al utilizar las IP falseadas (las de los equipos de la red remota) se consigue complicar un poco más la defensa ante este tipo de ataques.
En Ipv4 no hay una solución nativa para este tipo de problema. La solución pasa por realizar la autenticación que el protocolo TCP/IPv4 no realiza y, afortunadamente, en el nuevo protocolo TCP/IPv6 si se ofrecerá una forma de autenticación estandarizada.

Referencias:
http://www.governmentsecurity.org/archive/t1753.html
http://www.linuxsecurity.com/resource_files/documentation/tcpip-security.html
http://www.securityfocus.com/infocus/1674
http://articles.techrepublic.com.com/5100-10878_11-1059598.html

Uno de los agujeros de seguridad más fascinantes fue el que por primera vez describió R.T. Morris de los Laboratorios AT&T Bell en el año 1985. Es conocido como “TCP Sequence Number Prediction”. Él usó una predicción del número de secuencia TCP para construir una secuencia de paquetes TCP sin nunca recibir respuestas por parte del servidor. Esto le permitió atacar a una máquina segura en una red local.

La secuencia de establecimiento de conexión TCP normal necesita de un saludo de 3 pasos. El cliente selecciona y transmite un número de secuencia inicial ISNc, después el servidor lo reconoce y envía su propio número de secuencia ISNs, y entonces el cliente lo reconoce. Después de estos 3 mensajes, la transmisión de datos puede tomar lugar. Supongamos que hubiera un intruso que predijera ISNs. En ese caso podría enviar una secuencia que le permitiera hacerse pasar por un determinado host. De esta manera el servidor envía los datos al intruso cuando en realidad piensa que los está enviando al host original. Si el intruso realiza este ataque en una conexión que permite ejecutar comandos, éste entonces puede enviar comandos maliciosos al servidor.

Morris describe formas de predecir el número aleatorio ISN dependiendo de la implementación de cada sistema, en especial de los sistemas Berkeley.

Defensas.

Obiamente, la clave de este ataque es el relativamente tosco ritmo de cambio del número de secuencia inicial en los sistemas Berkeley. La especificación TCP requiere que esta variable sea incrementada aproximadamente 250.000 veces por segundo, Berkeley está usando un ritmo mucho más lento. De todas maneras, el factor crítico es la granularidad, no el ritmo medio….
Una solución a los ataques clásicos de número se secuencia está descrito en la RFC 1948. Usa una función hash cryptográfica para crear un espacio de secuencias separadas para cada “conexión”, una conexión como está definida por RFC 791, una única 4-tupla .

Extraido de: R. T. Morris. A weakness in the 4.2BSD unix TCP/IP software.
Computing Science Technical Report 117, AT&T
Bell Laboratories, Murray Hill, NJ, February 1985.

Ip spoofing
Despues de escribir todo esto, me he dado cuenta que ya se ha hablado un post anterior, de todas manestas, la solucion propuesta k pongo es diferente, y sin necesisdad de utilizar el protocolo tcp/ipv6

El spoofing consiste en que los atacantes falsean el origne de los paquete engañando a la victima, haciendole creer que es un equipo de confianza o autorizado. Con ello se consigue saltarse los firewall, y total libertad para acceder recursos de la victima.

Como medida estandar de seguiradad, para evitar el spoofing es obligar a que todo el trafico de la red sea encriptado y /o autentificado.. Mediante el protocolo IPsec se puede evitar eso, para ello deberemos habiliar los servicios de IPSec a los equipos afectados. Con ello conseguiremos que ningun atacante consiga los numeros ISN y por consiguiente no podrá usurpar la identidad de la victima.

IPSec: http://www.bujarra.com/ProcedimientoIPSec.html
Spoofing: http://www.lcu.com.ar/spoofing/
http://es.wikipedia.org/wiki/Spoofing

Nombre: Ping of Death

Descripción: Conocido como ping de la muerte, este ataque se basa en enviar un paquete de ping (ICMP echo request) de un tamaño muy grande. Teniendo en cuenta que el tamaño máximo de paquete en TCP/IP es de 64 Kbytes (65535 bytes), la implementación de la pila TCP/IP asigna un buffer en memoria de este tamaño. En el caso de que la información sea mayor, el buffer puede desbordarse. El resultado obtenido en muchas ocasiones es que el sistema destino deja de proveer servicio al bloquearse, ya sea rearrancándose (reboot) o incluso apagándose (shutdown). Lo que sucede realmente es que el paquete emitido es fragmentado, a nivel IP, en las redes intermedias, los fragmentos van siendo encolados en el sistema destino hasta que se reciben los ultimos pedazos (un paquete de 65536 bytes es suficiente), que son los que desbordan el buffer, provocando un comportamiento anómalo. Hay que tener en cuenta que los SS.OO. actuales no permiten al cliente de ping enviarlo, obteniéndose respuestas como “ping:illegal packet size”. Para realizar éste ataque es necesario disponer de una herramienta que lo implemenmte o modificar el límite impuesto en el código fuente del cliente de ping, por ejemplo en Linux.

Solución: La solución generada por los fabricantes de las implementaciones se basó en la generación de modificaciones en la pila TCP/IP. En el caso de no disponer de un parche asociado al S.O., el ataque puede evitarse filtrando los paquetes ICMP en el firewall de entrada. Una solución aún más detallada es filtrar únicamente los paquetes ICMP fragmentados y no todos, ya que otros protocolos pueden emplear paquetes ICMP para otros propósitos.

Referencia:
http://www.rediris.es/cert/doc/segtcpip/Seguridad_en_TCP-IP_Ed1.pdf

Nombre: Sniffing.
Descripcion: Un ataque realmente efectivo, ya que permite la obtención de gran cantidad de información sensible enviada sin encriptar, como por ejemplo usuarios, direcciones de e-mail, claves, números de tarjetas de crédito…, es emplear sniffers u olfateadores en entornos de red basados en difusión, como por ejemplo ethernet (mediante el uso de concentradores o hubs). El análisis de la información trasmitida permite a su vez extraer relaciones y topologías de las redes y organizaciones.
Los sniffers operan activando una de las interfaces de red del sistema en modo promiscuo. En este modo de configuración, el sniffer almacenará en un log todo el tráfico que circule por la tarjeta de red, ya sea destinado o generado por el propio sistema o desde/hacia cualquiera de los sistemas existentes en el entorno de red compartido (segmento ethernet). Asimismo, pueden ser instalados tanto en sistemas como en dispositivos de red [SI-1] [SI-2].
La efectividad de esta técnica se basa en tener acceso (habitualmente es necesario además disponer de dicho acceso como administrador o root) a un sistema interno de la red; por tanto, no puede ser llevado a cabo desde el exterior. Antes de la instalación de un sniffer, normalmente se instalarán versiones
modificadas (trojanos) de comandos como “ps” o “netstat” (en entornos Unix), para evitar que las tareas ejecutadas con el sniffer sean descubiertas.
Cuando los sniffers se emplean para la obtención de passwords, en ocasiones éstos no son necesarios, ya que los administradores de sistemas descuidan los equipos dejándolos configurados con las passwords que por defecto proporcionan los fabricantes [PA-1].
Aparte de los programas independientes existentes para ésta tarea, los sistemas operativos poseen sniffers en las distribuciones comerciales, típicamente utilizados por el administrador de red para resolver problemas en las comunicaciones:
Software general:
– Network Associates Sniffer
– NetXray
– HP Internet Advisor (dispositivo hardware de escaneo)
Software incluido en múltiples sistemas operativos:
– Unix: ethereal
– HP-UX: nettl
– Solaris: snoop
– Linux: tcpdump
– Windows: Microsoft Network Monitor
– Cisco IOS: comandos debug

http://www.rediris.es/cert/doc/segtcpip/Seguridad_en_TCP-IP_Ed1.pdf

Las redes Ethernet presentan problemas de seguridad.
Entre otros, en el protocolo ICMP.

Imaginemos una red montada en switch.

A este switch tenemos conectado un router y tres ordenadores (A: ordenador confidencial, B y C). Evidentemente tanto A,B,C tienen asignado como puerta de enlace por defecto el router.

Por lo tanto, en principio no deberíamos poder capturar el tráfico que circula por la red desde los otros ordenadores hacia el router.

Nosotros estamos en el ordenador C.

Primero instalamos en el PC C un software especial que haga actuar nuestro ordenador como router.

A continuación, malintencionadamente, contruimos un paquete ICMP de tipo redirect (simulando que lo envía el router) y se lo enviamos al PC A, diciéndole que la ruta que está usando para llegar al router no es óptima, sino que los paquetes deberían pasar por nuestro ordenador (y nosotros los rebotamos al router).

Ahahà! Ya estamos capturando el tráfico saliente del PC A sin que este se entere!!!

No sé muy bien si de igual manera se podría hacer para engañar al router y capturar también el tráfico entrante al PC A.

Referencia: yo mismo

#17

Yo he reportado una vulnerabilidad del protocolo TCP/IP, pero no he hecho copy&paste, si es esto lo que hay que hacer lo haré a partir de ahora.

Vulnerabilidad: SYN FLOOD
Puede saturar/bloquear un equipo objetivo.
El funcionamiento es el siguiente:
El equipo atacante manda una petición de conexión, es decir,un paquete SYN con una IP modificada que no pertenece a ningun equipo. La victima enviará entonces un paquete SYN/ACK de replica a la dirección IP falsa. La petición de conexión queda en la pila a la espera de que se le responda con un paquete ACK. Como la dirección IP a la que se mando el paquete SYN/ACK no existe, la respuesta no llegará nunca. Si en vez de un paquete comenzamos a mandar miles de ellos por minuto, la victima puede llegar a bloquearse.
Posible solución: Limitar el numero de conexiones para una misma fuente. Se puede implementar una pila TCP/IP que espere menos tiempo a que se le responda tras un paquete SYN/ACK para que sea mas dificil saturarla.

http://en.wikipedia.org/wiki/SYN_flood (entre otras)

Un posible problema a plantear podría ser el MITM (Man in the Middle). No es un ataque como tal a la red sino que tiene más repercusión sobre temas criptográficos, aunque para realizarlo se deba hacer uso de una serie de subataques. El ataque en si consiste en que el atacante adquiere la capacidad para interceptar y modificar mensajes entre dos elementos, sin que ninguna de las dos partes sepa que el mensaje ha sido modificado. Respecto al conjunto de subataques que contempla esta tecnica, se pueden encontrar :

– Intercepción de la comunicación o eavesdropping, incluyendo análisis de tráfico y posiblemente un ataque a partir de textos planos conocidos.

– Ataques a textos cifrados escogidos, en función de lo que el receptor haga con el mensaje descifrado

– Ataques de sustitución

– Ataques de repetición

– Ataque por denegación de servicio (denial of service). El atacante podría, por ejemplo, bloquear las comunicaciones antes de atacar una de las partes. La defensa en ese caso pasa por el envío de periódico de mensajes de status autenticados.

MitM se emplea típicamente para referirse a manipulaciones activas de los mensajes, más que para denotar intercepción pasiva de la comunicación.

La posibilidad de un ataque de hombre-en-el-medio sigue siendo un problema potencial de seguridad serio, incluso para muchos criptosistemas basados en clave pública. Existen varios tipos de defensa contra estos ataques MitM que emplean técnicas de autenticación basadas en:

– Claves públicas
– Autenticación mutua fuerte
– Claves secretas (secretos con alta entropía)
– Passwords (secretos con baja entropía)
– Otros criterios, como el reconocimiento de voz u otras características biométricas

La integridad de las claves públicas debe asegurarse de alguna manera, pero éstas no exigen ser secretas, mientras que los passwords y las claves de secreto compartido tienen el requerimiento adicional de la confidencialidad. Las claves públicas pueden ser verificadas por una autoridad de certificación (CA), cuya clave pública sea distribuida a través de un canal seguro (por ejemplo, a través del explorador de Web o en la instalación del sistema operativo).

No se hasta que punto esto tiene que ver con la red en si, aunque no deja de ser un problema y creo conveniente apuntarlo. Aun así, con los subataques que incluyo, aunque no sea valido el comentario, si que doy pie a explorar nuevas cosas, jejejeje.

Un saludo

Referencias : http://es.wikipedia.org/wiki/Ataque_Man-in-the-middle

En primer lugar voy a nombrar los ataques DNS y de enrutamiento. La mayoría de los protocolos de enrutamiento como RIP (Routing Information Protocol) o BGP (Border Gateway Protocol) carecen de autenticación, o tienen una muy sencilla. Se trata por tanto de un escenario perfecto para que cualquier atacante pueda alterar las rutas correctas y, falsificando su IP origen, crear una condición DoS. Las víctimas de estos ataques verán como su tráfico se dirige por ejemplo hacia un agujero negro: a una red que no existe.

Los ataques DoS sobre servidores de nombres de dominios (DNS) son tan problemáticos como los anteriores. Estos ataques intentan convencer al servidor DNS, por ejemplo, para almacenar direcciones falsas: cuando un servidor DNS realiza una búsqueda el atacante puede redireccionar a su propio servidor o bien a un “agujero negro”. En los últimos años se han sufrido varias veces ataques a alguno de los servidores “root” DNS de Interne,t colapsando media red y con tiempos de normalización superiores a las 48 horas.
Es importante saber que es un ataque de Denegación de Servicio (DoS) es un ataque que trata de impedir a la víctima de ser capaces de utilizar la totalidad o parte de su conexión de red.
Ahora voy a enumerar los distintos ataques de Denegación de Servicio(DoS) más comunes que existen en la actualidad:
1. En primer lugar, el Ataque de Inundación, este fue el primer servicio de ataque de denegación que existió. El ataque simplemente envía más trafico que la víctima podía manejar. Esto requiere que el atacante tiene una conexión de red más rápida que la víctima. Esta es la más baja tecnología de los ataque de denegación de servicio, y también la más difícil de prevenir por completo.
2. En segundo lugar, el Ping de la Muerte este ataque se basó en un error en el Berkeley pila TCP/IP que también existe en la mayoría de los sistemas que copiar el código de la red de Berkeley. El ping de la muerte era simplemente el envío de los paquetes de ping de más de 65535 bytes a la víctima. Este ataque de denegación de servicio es tan simple como :
Ping-1 86600 victim.org
3. En tercer lugar, el ataque SYN. En el protocolo TCP, handshaking de las conexiones de red se hace con SYN y ACK mensajes. El sistema que desea comunicarse SYN envía un mensaje al sistema de destino. El sistema responde con un mensaje ACK. En un ataque SYN, el atacante inunda el objetivo con mensajes SYN falsa para aparentar ser inalcanzable de las direcciones de internet. Esta llena el espacio de amortiguación para SYN mensajes en la máquina objetivo, la prevención de otros sistemas en la red de comunicación con la máquina objetivo.
4. En cuarto lugar, el ataque Teardrop. Este utiliza la fragmentación del paquete, algoritmo para enviar paquetes dañados a la máquina víctima. Esto confunde a la máquina víctima, y que puede bloquearse.
5. En quinto lugar, el ataque Smuft. El atacante envía un ping a la solicitud una dirección de broadcast en una tercera parte de la red. Este ping solicitud es falsa a aparecer venir de las víctimas de direcciones de red. Cada sistema en la emisión de dominio de los de terceros entonces enviar ping respuestas a la víctima.
6. Y por último, Distributed Denial of Service(DDos), es un ataque de denegación de servicio que está montado de un gran número de lugares a través de la red. Son generalmente montados en un gran número de sistemas comprometidos. Estos sistemas pueden haber sido comprometida por un gusano o que podría haber sido comprometida por ser hackeado manualmente. Estos sistemas comprometidos son genralmente controlados con bastantes sofisticada pieza de cliente-servidor, tales como software Trinoo, trubu Flood Netword. Este tipo de ataque puede ser muy difícil de defender.
Referencia: http://www.tech-faq.com/lang/es/dos-denial-of-service-attack.shtml

Vulnirabilidad: Desincronización durante el establecimiento de conexión.

En esta forma de desincronización, el atacante reinicia una conexión durante el “three-way handshake”.Dspues que el host B manda el paquete SYN&ACK al host A, el atacante gnera un paquete desde el host B hasta el host A en la cual la conexión es, primero, terminada mediante el bit RST, y despues un nuevo “three-way handshake” es iniciado con A identico al original, pero con una secuencia de numeros diferente. El host B, ignora a partir de ese momento los mensajes de A, y A ignora los mensajes de B.

El atacante nunca mas responde con nuevos paquetes, con la secuencia de numeros correcta, mientras que A y B intentan comunicarse. Entre tanto, el atacante puede modificar los mensajes o incluso insertar los suyos propios.

Referencia: http://www.linuxsecurity.com/resource_files/documentation/tcpip-security.html

Siguiendo en la linea de ampliación de comentarios anteriores, voy a extenderme en una falla de vulnerabilidad sobre servidores DNS.

El problema reside en los servidores de DNS de cacheo. Estos pueden ser suplantados aprovechando las caracteristicas del protocolo UDP, con la finalidad de insertar una ruta “enemiga” hacia un ordenador no autorizado.

Los servidores DNS de cacheo son aquellos servidores de nombre de dominio que usamos en nuestra LAN y que preguntan a los servidores de zona para la resolución de una IP a partir de un nombre, y que posteriormente almacenan en memoria durante un tiempo estipulado para favorecer resoluciones más rápidas.

El mecanismo del ataque sigue los siguientes pasos:

1) Enviar la solicitud de resolución al servidor “víctima”.
2) Seguidamente se envían tramas UDP modificadas sobre dicho servidor, suplantando al servidor de zona.
3) Confirmar la respuesta del servidor.
4) El servidor víctima contestará con la IP “enemiga” sobre la resolución del nombre.

El ataque de esta vulnerabilidad se realiza a través del fishing, inyectando registros de actualización.

La solución inicial propuesta es la de randomizar el puerto de solicitud por el que se realiza al servidor dueño del dominio. Aunque esta solución es vulnerable con tiempo y ancho de banda.

Por lo tanto la solución sería la implementación de servidores de cacheo dentro de la LAN, desplazando el ataque a realizarlo dentro de la propia LAN para evitar la infección de un único servidor de cacheo del ISP, teniendo así que atacar a muchos más servidores y por consiguiente la necesidad de un gran ancho de banda.

http://www.volkanrivera.com/esp/?p=558
http://www.doxpara.com/?p=1237

Olvide poner la dirección es la siguiente:

http://www.scribd.com/doc/4605365/Mecanismos-para-la-deteccion-de-ataques-e-instrucciones

La versión 4 del protocolo ip, es decir, IPv4 tiene el problema de que utiliza direcciones ip’s de 32 bits esto ha hecho que se vayan agotando dichas direcciones debido a que cada vez hay más elementos en la red, con lo que esto es un problema a corto plazo ya que llegará el momento no muy lejano en que se agotarán las direcciones y no podremos acceder a la red. La solución a este problema es la versión 6 del protocolo ip, el IPv6 el cual trabajará con ip’s de 128 bits por lo que la cantidad de direcciones aumenta considerablemente. La principal ventaja de cara a la comunicación y a lo mejor no tanto en cuanto a seguridad será que al disponer de tantas direcciones ip se podrá acceder desde un pc a cualquier otro pc del mundo ya que no se trabajará con el modelo NAT actual donde todo pc que esté detrás de un dispositivo oculta su dirección. Esto hará la comunicación más rápida aunque quizás tendrán que implantar nuevos métodos de seguridad más fiables ya que de esta manera los pc’s estarán más accesibles a cualquier individuo.

Referencia:

http://blog.hispasec.com/laboratorio/94
http://www.idg.es/comunicaciones/articulo.asp?seccion=servicios&id=131858

Voy a comentar la versión 6 del protocolo TCP/IP. Esta nueva y última versión se hizo dando importancia al tema de la seguridad en internet, ya que la versión 4, no la tuvo mucha en cuenta.

Este cambio se produce básicamente debido a que el actual protocolo TCP/IPv4 se ha quedado obsoleto, y el increíble crecimiento del número de conexiones que se efectúan a Internet ha ocasionado que el número de direcciones IP disponibles esté llegando a su fin.
El nuevo protocolo añade un mayor número de direccionamientos IP pero además trae también consigo muchas ventajas de las que todos nos beneficiaremos.

Como todos sabéis cada usuario particular o empresa que se conecta a Internet debe tener una dirección IP pública única. Pues bien esas direcciones IP se están acabando. Esto sin duda supone un gran problema ya que la carencia de este tipo de indentificadores provocaría la falta de combinaciones para poder dar de alta nuevos servidores, cada día resultaría más difícil contratar nuevos accesos a Internet e imposibilitaría que nuevas empresas se incorporasen al mercado de las tecnologías de la información. La brecha digital existente se agrandaría, sobre todo en algunos países desfavorecidos.

El actual protocolo IPv4, por diseño, ofrece un rango de direcciones IP asignables de 4.294.967.296 Una cifra altísima, sobre todo si tenemos en cuenta que se diseñó en su día para dar acceso a una red restringida a unos pocos. El espectacular crecimiento de Internet ha hecho que esta cifra sea completamente insuficiente.

De echo llevamos ya algunos años “parcheando” el problema de la disponibilidad de direcciones IP. Por ejemplo está el, conocido por todos, uso de servicios NAT (Network Address Translator) que permite canalizar múltiples direcciones IP privadas a través de una única dirección IP pública. Este sistema hasta hace relativamente poco era usado sobre todo por empresas que tenían la necesidad de que todos sus ordenadores tuvieran salida a Internet. Pero de unos años a esta parte, con la extensión de los routers y la presencia de varios ordenadores en el entorno doméstico, el uso de esta posibilidad es una realidad de muchos hogares en todo el mundo. Pero esto no deja de ser una solución temporal que no soluciona el problema.

Según los expertos, de no haber implementado soluciones de este tipo las direcciones IP se habrían agotado en el año 2000. Estos parches que hemos ido aplicando han permitido ampliar en 10 años la necesidad de aplicar una solución más o menos definitiva.

Además de este problema de que los direccionamientos IP se estén terminando está el acuciante problema de la seguridad. Como todos sabemos Internet es un hervidero de amenazas y vulnerabilidades explotadas por unos pocos pero que nos afectan, en mayor o menor medida, a todos. Esto en gran parte se debe a que el actual protocolo IPv4 se diseñó sin tener demasiado en cuenta el tema de la seguridad ya que se pensaba en entornos más o menos reducidos.

http://www.rau.edu.uy/ipv6/queesipv6.htm
http://www.es.wikipedia.org/wiki/IPv6