¿Qué tan malo es realmente el agotamiento de la dirección IPv4?

163

Durante años, la prensa ha estado escribiendo sobre el problema de que ahora hay muy pocas direcciones IPv4 disponibles. Pero, por otro lado, estoy usando una empresa de alojamiento de servidores que con gusto entrega direcciones IPv4 públicas por una pequeña cantidad de dinero. Y mi conexión a internet privada viene con una dirección IPv4 pública.

¿Cómo es eso posible? ¿Es el problema tan malo como la prensa quiere que creamos?

oz1cz
fuente
23
Algunas compañías todavía tienen muchas direcciones IPv4 disponibles. Otros tienen muy poco. Tengo que pensar muy cuidadosamente sobre el uso de una dirección IPv4; Como resultado, tengo bastantes máquinas con solo IPv6.
Michael Hampton
21
También le da una perspectiva de la cantidad de dolor que los ISP están dispuestos a causar a otras personas solo para evitar tener que implementar IPv6.
immibis
22
No lo llamaría malvado , pero ciertamente es un dolor. Dicho esto, a la mayoría de los consumidores probablemente no les importaría estar detrás de un nat, suponiendo que Facebook y WhatsApp funcionen.
Journeyman Geek
8
@JourneymanGeek Bueno, a los consumidores promedio realmente no les importa nada que no entiendan. Hay ideas para las redes sociales distribuidas, por ejemplo (porque eso hace que sea muy difícil censurarlas), pero a nadie le importan esas cosas hasta después de que despeguen, lo que no pueden debido a NAT. Me atrevo a decir que NAT es una de las razones por las que hemos terminado con una Web centralizada, porque es básicamente imposible alojar su propio sitio web sin pagarle a alguien.
immibis
15
Como señaló @Azendale, el alojamiento de servidores de juegos es grande. ¿Por qué no puedo simplemente ejecutar minecraft_server.exe y darles a mis amigos mi dirección? Por NAT. Los "consumidores" ciertamente quieren ejecutar servidores de juegos a veces.
immibis

Respuestas:

176

Es muy malo. Aquí hay una lista de ejemplos de lo que tengo experiencia de primera mano con los ISP de los consumidores para combatir la escasez de direcciones IPv4:

  • Repasar repetidamente los bloques de IPv4 entre ciudades causando breves interrupciones y restablecimientos de conexión para los clientes.
  • Acortar los tiempos de arrendamiento de DHCP de días a minutos.
  • Permita que los usuarios elijan si desean la traducción de direcciones de red (NAT) en el Equipo de la premisa del cliente (CPE) o no, y luego actívela retroactivamente para todos de todos modos.
  • Habilitación de NAT en CPE para clientes que ya utilizaron la oportunidad de optar por no participar en NAT.
  • Reducir el límite en el número de direcciones de control de acceso a medios (MAC) activas concurrentemente impuestas por CPE.
  • Implementación de NAT de nivel de operador (CGN) para clientes que tenían una dirección IP real cuando se suscribieron al servicio.

Todo esto reduce la calidad del producto que el ISP está vendiendo a sus clientes. La única explicación sensata de por qué harían esto a sus clientes es la escasez de direcciones IPv4.

La escasez de direcciones IPv4 ha llevado a la fragmentación del espacio de direcciones que tiene múltiples deficiencias:

Sin NAT no hay forma de que podamos sobrevivir hoy con los 3700 millones de direcciones IPv4 enrutables. Pero NAT es una solución frágil que le brinda una conectividad menos confiable y problemas que son difíciles de depurar. Cuantas más capas de NAT, peor será. Dos décadas de arduo trabajo han hecho que una sola capa de NAT funcione principalmente, pero ya hemos cruzado el punto en el que una sola capa de NAT era suficiente para evitar la escasez de direcciones IPv4.

kasperd
fuente
57
Una cosa para agregar es que NAT también conduce a usuarios malintencionados que impactan a los usuarios normales y generalmente hace que la IP no sea confiable como un mecanismo de diferenciación del usuario. Por ejemplo, Wikipedia bloquea a casi todos los usuarios de Qatar debido al vandalismo de uno o algunos usuarios.
IllusiveBrian
99
@IllusiveBrian hace un punto válido. Heredé el software de orientación de anuncios que usaba direcciones IP como identificador principal. Esto no es suficiente en la actualidad y ha tenido que modificarse ampliamente para que sea confiable. India y Grecia parecen ser dos de los países más afectados. Puedo ver que un anuncio recibe más de 100 veces al día desde el mismo IPv4, pero cada golpe puede ser un usuario diferente, determinado por otros métodos de seguimiento
Darren H
15
@DmitriySintsov no más de lo que lo haría un simple firewall con estado. Si un dispositivo perimetral puede hacer NAT, puede hacer firewalls con estado.
mfinni
15
@DarrenH "software de orientación de anuncios que utilizaba direcciones IP como identificador principal ... y ha tenido que modificarse ampliamente para que sea confiable". Bueno, esa sola razón es suficiente para mantener NAT.
Andy
66
@DarrenH Es solo un comentario acerca de que no te gusta el software publicitario, sin importar el tono que sientas en tu cabeza.
Andy
132

Antes de comenzar a quedarnos sin direcciones IPv4, no utilizamos (ampliamente) NAT. Cada computadora conectada a Internet tendría su propia dirección global única. Cuando se introdujo NAT por primera vez, fue pasar de dar a los clientes de ISP 1 dirección real por dispositivo que el cliente usó / poseyó para dar a 1 cliente 1 dirección real. Eso solucionó el problema por un tiempo (años) mientras se suponía que íbamos a cambiar a IPv6. En lugar de cambiar a IPv6, (en su mayoría) todos esperaron a que todos cambiaran y, por lo tanto, (en su mayoría) nadie lanzó IPv6. Ahora estamos enfrentando el mismo problema nuevamente, pero esta vez, se está implementando una segunda capa de NAT (CGN) para que los ISP puedan compartir 1 dirección real entre múltiples clientes.

El agotamiento de la dirección IP no es un gran problema si NAT no es terrible, incluso en el caso en que el usuario final no tiene control sobre él (Carrier Grade NAT o CGN).

Pero yo diría que NAT es terrible, especialmente en el caso en que el usuario final no tiene control sobre él. Y (como una persona cuyo trabajo es ingeniería / administración de redes pero tiene un título en ingeniería de software), diría que al implementar NAT en lugar de IPv6, los administradores de red han trasladado el peso de resolver el agotamiento de la dirección de su campo a los usuarios finales. y desarrolladores de aplicaciones.

Entonces (en mi opinión), ¿por qué NAT es algo terrible y malvado que debería evitarse?

Veamos si puedo hacerle justicia al explicar lo que rompe (y qué problemas causa que nos hayamos acostumbrado tanto que ni siquiera nos damos cuenta de que podría ser mejor):

  • Independencia de la capa de red
  • Conexiones de igual a igual
  • Nomenclatura constante y ubicación de recursos
  • Enrutamiento óptimo del tráfico, los hosts conocen su dirección real
  • Seguimiento de la fuente del tráfico malicioso
  • Protocolos de red que separan datos y control en conexiones separadas

Veamos si puedo explicar cada uno de esos elementos.

Independencia de la capa de red

Se supone que los ISP simplemente pasan paquetes de capa 3 y no les importa lo que hay en las capas superiores. Ya sea que esté pasando por TCP, UDP o algo mejor / más exótico (¿SCTP tal vez? cuidado; se supone que todo debe parecerles datos.

Pero no es así, no cuando están implementando la "segunda ola" de NAT, "Carrier Grade" NAT. Luego, necesariamente tienen que mirar y apoyar los protocolos de capa 4 que desea usar. En este momento, eso prácticamente significa que solo puede usar TCP y UDP. Otros protocolos simplemente serían bloqueados / descartados (la gran mayoría de los casos en mi experiencia) o simplemente reenviados al último host "dentro" del NAT que usó ese protocolo (he visto 1 implementación que hace esto). Incluso reenviar al último host que usó ese protocolo no es una solución real: tan pronto como lo usan dos hosts, se rompe.

Me imagino que hay algunos protocolos de reemplazo para TCP y UDP que actualmente no se han probado ni utilizado solo por este problema. No me malinterpreten, TCP y UDP fueron impresionantemente bien diseñados y es sorprendente cómo ambos han podido ampliar la forma en que usamos Internet hoy. ¿Pero quién sabe lo que nos hemos perdido? He leído sobre SCTP y suena bien, pero nunca lo usé porque no era práctico debido a NAT.

Conexiones de igual a igual

Este es un grande. En realidad, el más grande en mi opinión. Si tiene dos usuarios finales, ambos detrás de su propio NAT, sin importar cuál intente conectarse primero, el NAT del otro usuario descartará su paquete y la conexión no tendrá éxito.

Esto afecta los juegos, el chat de voz / video (como Skype), el alojamiento de sus propios servidores, etc.

Hay soluciones alternativas. El problema es que esas soluciones cuestan tiempo de desarrollador, tiempo e inconvenientes para el usuario final o costos de infraestructura de servicio. Y no son infalibles y a veces se rompen. (Vea los comentarios de otros usuarios sobre la interrupción que sufrió Skype).

Una solución alternativa es el reenvío de puertos, donde se programa el dispositivo NAT para reenviar un puerto entrante específico a una computadora específica detrás del dispositivo NAT. Hay sitios web completos dedicados a cómo hacer esto para todos los diferentes dispositivos NAT que existen. Ver https://portforward.com/ . Esto generalmente le cuesta tiempo y frustración al usuario final.

Otra solución es agregar soporte para cosas como perforar agujeros en las aplicaciones y mantener la infraestructura del servidor que no está detrás de un NAT para introducir dos clientes NAT. Por lo general, esto cuesta tiempo de desarrollo y coloca a los desarrolladores en una posición de mantenimiento potencial de la infraestructura del servidor donde no habría sido requerida previamente.

(¿Recuerda lo que dije sobre la implementación de NAT en lugar de que IPv6 transfiriera el peso del problema de los administradores de red a los usuarios finales y desarrolladores de aplicaciones?)

Nomenclatura / ubicación constante de los recursos de la red

Debido a que se usa un espacio de direcciones diferente en el interior de un NAT y luego en el exterior, cualquier servicio ofrecido por un dispositivo dentro de un NAT tiene múltiples direcciones para llegar a él, y el correcto para usar depende de dónde esté accediendo el cliente desde él. . (Esto sigue siendo un problema incluso después de que funcione el reenvío de puertos).

Si tiene un servidor web dentro de un NAT, digamos en el puerto 192.168.0.23 puerto 80, y su dispositivo NAT (enrutador / puerta de enlace) tiene una dirección externa de 35.72.216.228, y configura el reenvío de puertos para el puerto TCP 80, ahora su Se puede acceder al servidor web utilizando 192.168.0.23 puerto 80 O 35.72.216.228 puerto 80. El que debe usar depende de si está dentro o fuera del NAT. Si está fuera de NAT y usa la dirección 192.168.0.23, no llegará a donde esperaba. Si está dentro de NAT y usa la dirección externa 35.72.216.228, puede llegar a donde quiera, si su implementación de NAT es avanzada y admite horquilla, pero el servidor web que atiende su solicitud verá que la solicitud proviene de su dispositivo NAT. Esto significa que todo el tráfico debe pasar por el dispositivo NAT, incluso si hay una ruta más corta en la red detrás de NAT, y significa que los registros en el servidor web se vuelven mucho menos útiles porque todos enumeran el dispositivo NAT como la fuente de la conexión. Si su implementación NAT no es compatible, entonces no llegará a donde esperaba ir.

Y este problema empeora tan pronto como usa DNS. De repente, si desea que todo funcione correctamente para algo alojado detrás de NAT, tendrá que dar diferentes respuestas sobre la dirección del servicio alojado dentro de un NAT, en función de quién pregunta (también conocido como DNS de horizonte dividido, IIRC). Yuck

Y eso es todo suponiendo que tenga a alguien con conocimientos sobre el reenvío de puertos y la NAT de horquilla y DNS de horizonte dividido. ¿Qué pasa con los usuarios finales? ¿Cuáles son sus posibilidades de configurar todo esto correctamente cuando compran un enrutador de consumo y alguna cámara de seguridad IP y quieren que "funcione"?

Y eso me lleva a:

Enrutamiento óptimo del tráfico, los hosts conocen su dirección real

Como hemos visto, incluso con el tráfico avanzado de NAT no siempre fluye a través de la ruta óptima. Eso es incluso en el caso en que un administrador experto configura un servidor y tiene una horquilla NAT. (Por supuesto, el DNS de horizonte dividido puede conducir a un enrutamiento óptimo del tráfico interno en manos de un administrador de red).

¿Qué sucede cuando un desarrollador de aplicaciones crea un programa como Dropbox y lo distribuye a usuarios finales que no se especializan en la configuración de equipos de red? Específicamente, ¿qué sucede cuando pongo un archivo de 4GB en mi archivo compartido y luego trato de acceder en la próxima computadora? ¿Se transfiere directamente entre las máquinas o tengo que esperar a que se cargue en un servidor en la nube a través de una conexión WAN lenta y luego esperar una segunda vez para que se descargue a través de la misma conexión WAN lenta?

Para una implementación ingenua, se cargaría y luego se descargaría, utilizando la infraestructura del servidor de Dropbox que no está detrás de un NAT como mediador. Pero si las dos máquinas solo pudieran darse cuenta de que están en la misma red, entonces podrían transferir directamente el archivo mucho más rápido. Entonces, para nuestro primer intento de implementación menos ingenuo, podríamos preguntarle al sistema operativo qué direcciones IP (v4) tiene la máquina, y luego verificar eso con otras máquinas registradas en la misma cuenta de Dropbox. Si está en el mismo rango que nosotros, simplemente transfiera el archivo directamente. Eso podría funcionar en muchos casos. Pero incluso entonces hay un problema: NAT solo funciona porque podemos reutilizar direcciones. Entonces, ¿qué pasa si la dirección 192.168.0.23 y la 192.168.0. 42 direcciones registradas en la misma cuenta de Dropbox en realidad están en diferentes redes (como su red doméstica y su red de trabajo)? Ahora debe volver a utilizar la infraestructura del servidor de Dropbox para mediar. (Al final, Dropbox intentó resolver el problema haciendo que cada cliente de Dropbox transmitiera en la red local con la esperanza de encontrar otros clientes. Pero esas transmisiones no cruzan ningún enrutador que pueda tener detrás del NAT, lo que significa que no es una solución completa ,especialmente en el caso de CGN .)

IP estáticas

Además, dado que la primera escasez (y la ola de NAT) sucedió cuando muchas conexiones de consumidores no siempre estaban en conexiones (como el acceso telefónico), los ISP podrían hacer un mejor uso de sus direcciones asignando solo direcciones IP públicas / externas cuando estaba realmente conectado. Eso significaba que cuando te conectabas, obtenías cualquier dirección disponible, en lugar de obtener siempre la misma. Eso hace que la ejecución de su propio servidor sea mucho más difícil, y hace que el desarrollo de aplicaciones punto a punto sea más difícil porque necesitan tratar con pares que se mueven en lugar de estar en direcciones fijas.

Ofuscación de la fuente del tráfico malicioso

Debido a que NAT reescribe las conexiones salientes para que provengan del propio dispositivo NAT, todo el comportamiento, bueno o malo, se incluye en una dirección IP externa. No he visto ningún dispositivo NAT que registre cada conexión saliente de forma predeterminada. Esto significa que, de manera predeterminada, la fuente del tráfico malicioso anterior solo se puede rastrear hasta el dispositivo NAT por el que pasó. Si bien se pueden configurar más equipos de clase empresarial o de operador para registrar cada conexión saliente, no he visto ningún enrutador de consumidor que lo haga. Ciertamente creo que será interesante ver si (y durante cuánto tiempo) los ISP mantendrán un registro de todas las conexiones TCP y UDP realizadas a través de CGN a medida que las implementen. Dichos registros serían necesarios para tratar las quejas de abuso y las quejas de la DMCA.

Algunas personas piensan que NAT aumenta la seguridad. Si lo hace, lo hace a través de la oscuridad. La caída predeterminada del tráfico entrante que NAT hace obligatorio es lo mismo que tener un firewall con estado. Tengo entendido que cualquier hardware capaz de hacer el seguimiento de conexión necesario para NAT debería poder ejecutar un firewall con estado, por lo que NAT realmente no merece ningún punto allí.

Protocolos que usan una segunda conexión

Los protocolos como FTP y SIP (VoIP) tienden a usar conexiones separadas para el control y el contenido de datos real. Cada protocolo que hace esto debe tener un software auxiliar llamado ALG (puerta de enlace de capa de aplicación) en cada dispositivo NAT que atraviesa, o solucionar el problema con algún tipo de mediador o perforación. En mi experiencia, los ALG rara vez se actualizan o alguna vez han sido la causa de al menos un par de problemas que he tratado con SIP. Cada vez que escucho a alguien informar que VoIP no funcionó para ellos porque el audio solo funcionó de una manera, instantáneamente sospecho que en algún lugar, hay una puerta de enlace NAT que deja caer paquetes UDP con los que no puede averiguar qué hacer.

En resumen, NAT tiende a romperse:

  • protocolos alternativos a TCP o UDP
  • sistemas de igual a igual
  • acceder a algo alojado detrás de NAT
  • cosas como SIP y FTP. Los ALG para evitar esto todavía causan problemas aleatorios y extraños hoy, especialmente con SIP.

En esencia, el enfoque por capas que adopta la pila de red es relativamente simple y elegante. Trate de explicárselo a alguien nuevo en las redes, e inevitablemente asumen que su red doméstica es probablemente una red buena y simple para tratar de entender. En un par de casos, he visto esto conducir a algunas ideas bastante interesantes (excesivamente complicadas) sobre cómo funciona el enrutamiento debido a la confusión entre las direcciones externas e internas.

Sospecho que sin NAT, VoIP sería omnipresente e integrado con la PSTN, y que realizar llamadas desde un teléfono celular o computadora sería gratis (a excepción de Internet que ya pagó). Después de todo, ¿por qué pagaría el teléfono cuando usted y yo podemos abrir una transmisión VoIP de 64K y funciona tan bien como la PSTN? Parece que hoy, el problema número 1 con la implementación de VoIP está pasando por dispositivos NAT.

Sospecho que generalmente no nos damos cuenta de lo simples que podrían ser muchas cosas si tuviéramos la conectividad de extremo a extremo que NAT rompió. La gente todavía envía sus propios correos electrónicos (o Dropbox) porque es el problema principal de necesitar un mediador para cuando dos clientes están detrás de NAT.

Azendale
fuente
3
Las direcciones IPv6 de @supercat son globalmente únicas, pero no planas (para admitir el enrutamiento, que debe ser jerárquico). Me parece que si queremos que dos hosts conectados a Internet puedan comunicarse teóricamente, son necesarias direcciones globalmente únicas de alguna forma.
Jakob
99
@supercat Desafortunadamente, es un mito persistente que IPv6 todavía no tiene suficiente espacio para todos. Podrías dar un / 48 a todos en la tierra y aún queda una gran cantidad de espacio sobrante. Para agotar la asignación actual, 2000::/3¡debería repetir ese ejercicio más de 4.000 veces! o dar a todos un / 34. Pero un / 48 es lo suficientemente bueno para prácticamente todos, y aquellos que necesitan más pueden obtenerlo fácilmente. Incluso si esto no fuera suficiente, todavía hay 4000::/3, 6000::/3etc., disponibles. Tenemos MUCHO espacio; Es hora de usarlo. Ver también RFC 6177 .
Michael Hampton
77
@immibis Parece que te has perdido algo. Las organizaciones no se limitan a obtener un / 48 o un / 32. Pueden obtener bloques de prácticamente cualquier tamaño. Podría ser un / 44 o un / 40 o / 39 o / 47 o lo que sea. También debe leer RFC 6177.
Michael Hampton
44
Desafortunadamente, muchas personas han comenzado a usar NAT como una forma de seguridad deficiente y muchos dispositivos como Chromecasts y dispositivos IoT asumen que cualquier dispositivo que pueda conectarse a él es un dispositivo confiable, por lo que cada enrutador de consumidor que he visto dejará caer las conexiones entrantes a dispositivos ipv6 y algunos que he visto no tienen forma de desactivar esto, solo el reenvío de puertos normal.
Qwertie
14
... Ok, ahora odio a NAT; ¿Cómo me cambio a IPv6?
Adam Barnes
20

Un gran síntoma de agotamiento de IPv4 que no vi mencionado en otras respuestas es que algunos proveedores de servicios móviles comenzaron a usar IPv6 solo hace varios años. Existe la posibilidad de que haya estado usando IPv6 durante años y ni siquiera lo supiera. Los proveedores de servicios móviles son más nuevos en el juego de Internet y no necesariamente tienen enormes asignaciones de IPv4 preexistentes para aprovechar. También requieren más direcciones que cable / DSL / fibra, porque su teléfono no puede compartir una dirección IP pública con otros miembros de su hogar.

Supongo que los proveedores de IaaS y PaaS serán los siguientes, debido a su crecimiento que no está vinculado a las direcciones físicas de los clientes. No me sorprendería ver que los proveedores de IaaS ofrecen solo IPv6 con un descuento pronto.

Karl Bielefeldt
fuente
10
Ya he visto algunos proveedores pequeños que ofrecen máquinas virtuales solo IPv6 y cobran una prima por IPv4.
Michael Hampton
14

Los principales RIR se quedaron sin espacio para asignaciones normales hace un tiempo. Por lo tanto, para la mayoría de los proveedores, las únicas fuentes de direcciones IPv4 son sus propias existencias y los mercados.

Hay escenarios en los que es preferible tener una IP IPv4 pública dedicada, pero no es absolutamente esencial. También hay un montón de direcciones IPv4 públicas que están asignadas pero que actualmente no están en uso en Internet público (pueden estar en uso en redes privadas o pueden no estar en uso). Finalmente, hay redes más antiguas con direcciones asignadas mucho más libremente de lo necesario.

Los tres RIR más grandes ahora permiten que se vendan direcciones tanto entre sus miembros como entre los miembros. Por lo tanto, tenemos un mercado entre organizaciones que tienen direcciones que no están usando o que tienen direcciones que podrían liberarse por un lado y organizaciones que realmente necesitan más direcciones IP por el otro.

Lo que es difícil de predecir es cuánta oferta y demanda habrá en cada punto de precio y, por lo tanto, qué hará el precio de mercado en el futuro. Hasta ahora, el precio por IP parece haberse mantenido sorprendentemente bajo.

Peter Green
fuente
AfriNIC tiene todavía menos de un / 8 de direcciones disponibles, y he visto muchos ejemplos de organizaciones fuera de África que las están tomando.
Michael Hampton
7

Idealmente, cada host en Internet debería poder obtener una dirección IP de alcance global, sin embargo, el agotamiento de la dirección IPv4 es real, de hecho ARIN ya se ha quedado sin dirección en su grupo gratuito .

La razón por la que todos todavía pueden acceder a los servicios de Internet es gracias a las técnicas de traducción de direcciones de red (NAT) que permiten que varios hosts compartan direcciones IP públicas. Sin embargo, esto no viene sin problemas.

Torin
fuente
18
No quiero saber cuántas horas, recursos y millones de hombres se han desperdiciado entre Napster, Gnutella, Gossip, Kazaa, BitTorrent, Kademlia, FastTrack, eDonkey, Freenet, Grokster, Skype, Threema, Spotify, etc. , desarrollando técnicas de perforación NAT.
Jörg W Mittag
@ JörgWMittag Sin mencionar lo espectacular que falló para Skype en diciembre de 2010.
kasperd
44
Y el hecho de que tienes que usar técnicas de perforación NAT en primer lugar. Si la máquina X y la máquina Y están en conexiones normales, no pueden comunicarse entre sí sin un mediador. Molesto para cosas como tareas de sincronización de archivos.
Loren Pechtel
@kasperd ¿Podría dar más detalles sobre este "error para Skype en diciembre de 2010"? Podría encontrar que una gran cantidad de supernodos fallaron a la vez, por alguna razón no especificada . Y no veo cómo eso es relevante para el agotamiento de la dirección IPv4.
ivan_pozdeev
55
@ivan_pozdeev Supernodes es una solución para los problemas causados ​​por NAT. NAT en sí es una solución para la escasez de direcciones IPv4. Por lo tanto, la necesidad de que Skype use supernodos en primer lugar se debió completamente a la escasez de direcciones IPv4. Si Internet se hubiera actualizado a IPv6 a un ritmo más razonable, Skype no habría necesitado supernodos, y esa interrupción en particular no habría ocurrido.
kasperd
5

Los ISP solían distribuir bloques de 256 direcciones IP a las empresas. Ahora, los ISP son tacaños y le brindan a usted (una compañía) como 5. En el pasado (2003), cada PC y dispositivo conectado en su hogar tenía su propia dirección IP de Internet. Ahora, el enrutador de cable / DSN / Fios tiene una dirección IP y entrega direcciones IP 10.0.0.x a todas las PC de su hogar. Resumen: los ISP solían desperdiciar direcciones IP y ahora ya no las están desperdiciando.

Russell Hankins
fuente
55
" En el pasado (2003), cada PC y dispositivo conectado en su hogar tenía su propia dirección IP de Internet " . Solo si pagó por el 2 °, 3 °, 4 °, etc.
RonJohn
2
RonJohn está en lo correcto. Fui uno de los primeros en adoptar la banda ancha cuando el Internet por cable llegó a mi área en 1997. Pagué $ 50 (US) por mes por ello, y recuerdo claramente que ofrecían una segunda dirección IP por $ 20 adicionales por mes. Aunque quería uno, no estaba dispuesto a pagarlo. Al año siguiente, mi problema se resolvió cuando descubrí dispositivos NAT. No tenían muchas características (como el reenvío de puertos para las conexiones entrantes), pero la que obtuve resolvió mi necesidad inmediata.
Charles Burge
@CharlesBurge También recuerdo eso. Y ahora vemos que algunos proveedores también intentan hacer lo mismo con IPv6.
Kevin Keane
@CharlesBurge: Esto dependía de su ISP. Tenía un amigo por cable en Phoenix, AZ casi al mismo tiempo, y él obtuvo una subred completamente enrutada, un bloque / 29, con 8 direcciones, 5 utilizables. Ejecutamos un servidor Linux con compuerta (por accidente de nuestra parte), y la red de cable en realidad compartió información completa de enrutamiento BGP con él. Eso y las personas que pusieron sus PC e impresoras con Windows con recursos compartidos totalmente abiertos en la red hicieron la vida interesante.
Zan Lynx
Oh sí, recuerdo la visibilidad de la red. Todos los demás en mi bucle eran visibles en "Entorno de red", y podía examinar cualquier recurso compartido que tuvieran.
Charles Burge
5

Ya obtuvo muchas respuestas excelentes, pero me gustaría agregar algo que aún no se ha mencionado.

Sí, el agotamiento de la dirección IPv4 es malo, dependiendo de cómo lo mida. Algunas compañías aún tienen un gran suministro de direcciones IPv4, pero estamos comenzando a ver soluciones alternativas como NAT de nivel de operador.

Pero muchas de las respuestas son incorrectas cuando se desvían a IPv6.

Aquí hay una lista de tecnologías que pueden ayudar a lidiar con la escasez de direcciones IPv4. Cada uno tiene sus propias ventajas y desventajas.

  • IPv6

    • Ventaja: estandarizada y disponible en la mayoría de los sistemas operativos.
    • Inconveniente: a pesar de las frecuentes declaraciones en contrario, graves problemas de seguridad. Ya en 2005, US CERT advirtió sobre problemas de seguridad causados ​​por el direccionamiento global de IPv6. IPv6 se puede proteger correctamente, pero dado el estado de los enrutadores de consumo, puede que no suceda.
    • Inconveniente: la migración requiere tiempo, dinero y experiencia.
    • Inconveniente: muchos dispositivos de grado de consumo tienen fallas graves. Por ejemplo, varios enrutadores D-Link admiten IPv6 simplemente reenviando todo el tráfico sin ofrecer ningún firewall.

Otra consideración: incluso si IPv6 se aplicara por completo hoy en día, aún tomaría otros 20 años más o menos eliminar gradualmente IPv4, debido al equipo heredado que la gente usará durante mucho tiempo (todavía veo servidores Windows 2003 y estaciones de trabajo Windows XP ocasionalmente! Sin mencionar todas las impresoras y cámaras y dispositivos IoT que no son compatibles con IPv6).

  • CGNat:
    • Ventaja: funciona sin cambios en las instalaciones del cliente.
    • Inconveniente: solo admite conexiones salientes.
    • Inconveniente: puede no ser compatible con algunos protocolos.

Eventualmente, CGNat no será suficiente. Tal vez IPv6 se ponga al día, pero también es bastante posible que terminemos viendo NAT de grado país, o algo por el estilo.

Actualmente, como consultor, a menudo tengo que señalar a mis clientes que están expuestos a IPv6 (a menudo gracias a Teredo). La siguiente pregunta será invariablemente: "¿Cuánto cuesta arreglar eso?" y luego "¿Cuánto cuesta bloquearlo? ¿Qué perdemos si lo apagamos?" Adivina cuál será la decisión cada vez.

En pocas palabras: para responder a su pregunta, sí, el agotamiento de IPv4 es real. Y veremos bastantes mecanismos para hacerle frente. IPv6 puede o no terminar siendo la ecuación.

Para ser claros: no digo que me guste esta situación. Me gustaría que IPv6 tuviera éxito (y me gustaría ver una serie de mejoras en IPv6). Solo estoy mirando la situación en este momento.

Kevin Keane
fuente
2
CGN, como cualquier NAT, solo funciona con TCP, UDP e ICMP, y no con otros protocolos de transporte. También rompe muchos protocolos de capa de aplicación. NAT es una solución fea para tratar de extender IPv4, y realmente ha dejado de ser útil.
Ron Maupin
3
@supercat, los paquetes IP no tienen nombres DNS. Ese sería un protocolo diferente. Solo los protocolos de transporte TCP, UDP e ICMP funcionan con NAPT, otros no. Muchas aplicaciones y protocolos de capa de aplicación no funcionan con NAPT, y requieren hacks feos además del hack NAPT feo. La premisa de IP es que cada dispositivo final tiene una dirección única, y muchos protocolos se diseñaron en torno a eso. IPv6 resuelve ese problema, así como algunas deficiencias de IPv4.
Ron Maupin
3
@supercat, si realmente es así de simple, no habría razón para que la enorme base instalada de redes IPX se convirtiera a IPv4. Podría hacer el mismo tipo de cosas entre IPX e IPv4, y se hizo por un tiempo, pero es solo un error.
Ron Maupin
1
@supercat: entonces, para admitir dicha red, ¿debemos abandonar los estándares existentes y reescribir todas las aplicaciones existentes que se conectan directamente a las direcciones? Eso no suena como un buen enfoque para mí.
Julio
2
@KevinKeane No estoy terriblemente sorprendido de que un antiguo enrutador de consumo de 2010 tenga problemas con IPv6. Un examen de 30 segundos de los resultados de búsqueda de Google indica que resolvieron ese problema hace años.
Michael Hampton
-1

NAT es lo que sucedió cuando IPv6 era una idea, antes de que fuera realidad, y la asignación de direcciones IP se estaba convirtiendo en un problema real (¿alguien recuerda cuándo estaban entregando la Clase C básicamente por preguntar?) Y el mundo real necesitaba una solución mientras tanto .

NAT no es suficiente para IoT. Si IoT va a suceder, sucederá con IPv6. La naturaleza de IoT está más estrechamente alineada con el funcionamiento del mundo de acceso telefónico, excepto que habrá varios órdenes de magnitud más dispositivos conectados al mismo tiempo.

Javier
fuente
2
A partir de una búsqueda rápida, NAT parece haber sido originalmente definido por RFC 1631 en mayo de 1994. IPv6 se define en RFC 1883, publicado en diciembre de 1995 como un estándar propuesto (que está bastante lejos en la pista de estándares). No sé dónde trazas la línea entre "una idea" y "realidad", pero el código IPv6 que funcionaba casi siempre existía en los bancos de pruebas mucho antes de que se publicara RFC 1883. Compare esto con el RFC 1918 a menudo referenciado, que se publicó en febrero de 1996, unos meses después del RFC IPv6 inicial.
un CVn
2
Los estándares son inútiles sin la implementación, y una implementación por la cual los consumidores o las empresas están dispuestos a pagar. Los bancos de pruebas y las pruebas de concepto no cuentan en el mercado. Mi punto sobre NAT es que las implementaciones de trabajo llegaron al mercado (y por lo tanto ganaron tracción) porque el hardware existente (y había uno de ellos en ese momento) todos hablaban IPv4. Por lo tanto, era más una cuestión de "problema resuelto, vamos a trabajar en temas más urgentes ahora".
Xavier
2
@Xavier: 64K es un límite superior que un dispositivo NAT ni siquiera puede alcanzar. Por un lado, todos los puertos bajos por debajo de 1024 están restringidos. Y la mayoría de NAT se limita a un alto rango de puertos de aproximadamente 20K puertos. Y, por supuesto, está el problema de la memoria: incluso hoy tenemos enrutadores que se caen y se reinician porque alguien intentó abrir 10,000 conexiones TCP al mismo tiempo. Mirándote, Google Home.
Zan Lynx
1
@KevinKeane: porque parte del sorteo de IOT es poder conectarse a sus dispositivos desde el exterior. Por el momento, debido a que configurar NAT es una molestia que los fabricantes de dispositivos no quieren infligir a los consumidores, a menudo lo hacemos a través de servicios externos de "conexión" proporcionados por los fabricantes de dispositivos, pero esto no es sostenible a largo plazo . Todo lo que necesita es que un fabricante de alto perfil cierre el negocio y, de repente, todos desconfiarán de que sus dispositivos continúen funcionando. La única forma en que esto seguirá funcionando a largo plazo es si la mayoría de las personas tienen IPv6.
Julio
1
@supercat - tal vez, pero hasta ahora parece que es menos probable que eso suceda que la disponibilidad universal de IPv6 ...
Julio
-4

Todo el problema de la dirección IPv4 es bastante complicado. Puede encontrar cierto artículo que informa que está agotado, y otro que habla de un gran número de direcciones excedentes (nunca utilizadas) que se venden de una parte a otra. La pregunta sería ¿por qué estos no están disponibles para aquellos (regiones emergentes y áreas rurales de países desarrollados) por debajo de ellos?

A continuación se muestra el resultado de un estudio en el que nos aventuramos accidentalmente. No utiliza nada más que el protocolo original de IPv4 RFC791 y el bloque de direcciones 240/4 de larga reserva pero difícilmente utilizado para expandir el grupo de IPv4 por 256 millones de veces. Hemos presentado un proyecto de propuesta llamado EzIP (fonética para Easy IPv4) al IETF:

https://tools.ietf.org/html/draft-chen-ati-adaptive-ipv4-address-space-03

Básicamente, el enfoque EzIP no solo resolverá los problemas de escasez de direcciones IPv4, sino que también mitigará en gran medida la causa raíz de las vulnerabilidades de seguridad cibernética, además de abrir nuevas posibilidades para Internet, todo dentro de los límites del dominio IPv4. De hecho, este esquema puede implementarse "sigilosamente" para regiones aisladas donde sea necesario. Esto debería aliviar la urgencia de implementar el IPv6 durante un período de tiempo considerable e invalidar el mercado de comercio de las direcciones IPv4.

Cualquier pensamiento o comentario será muy apreciado.

Abe (15/07/2018 17:29)

Abraham Y. Chen
fuente
3
ServerFault no es un IETF WG.
womble
-5

Honestamente, creo que no es tan malo como la gente piensa. Sí, tal vez en algunos lugares, pero no tanto porque no hay suficientes direcciones. Es porque todos son de su propiedad. Tal vez sea mi ubicación o algo así, pero he trabajado en TI para un montón de pequeñas y medianas empresas en los últimos siete años más o menos, y todas las cosas de las que están hablando son generalmente configuraciones estándar. Bastante fácil a menos que tengas un dispositivo malo, o hay una configuración de mierda con la red en primer lugar que necesita ser resuelta.

Personalmente, estoy bien con NAT. Es una capa adicional de protección, en general. Al menos tienen que pasar por un dispositivo adicional o encontrar una manera indirecta de secuestrar mi conexión. En lo que respecta a la ejecución de servidores, esto generalmente se encuentra fuera y / o se considera un incumplimiento de contrato con su ISP a menos que pague por ello. Claro que puedes hacerlo, y probablemente no te molesten al respecto, pero podrían hacerlo.

Reenvío de puertos y todo eso no es exactamente complicado. Ahora, quizás algunos dispositivos no sean fáciles de configurar, pero eso no se debe a IPv4. Todavía ofrece la mayor compatibilidad simplemente porque es omnipresente.

En realidad, nadie necesita enviarse correos electrónicos, y enviar algo a Drop-box o Google Drive, o un millón de otros servicios similares no es exactamente ciencia espacial, ni lenta, en estos días. Me refiero a que todo se sincroniza. Lo dejas caer en una carpeta. A menos que seas nerd como yo, y hagas todo a través de ssh / sftp (está bien, no todo ). Y si tiene alguna razón por la que realmente desea ejecutar su propio servidor, el alojamiento en la nube es barato: tengo un servidor virtual dedicado que ejecuta Linux en un SSD. El ancho de banda es loco rápido. Arranca más rápido de lo que puedo escribir una flecha hacia arriba y presionar Enter. Y es escalable Toda la configuración cuesta entre 5 y 10 dólares al mes, con copias de seguridad gratuitas y sin factura de electricidad.

Realmente no necesito una solución de red de pares. Incluso la mayoría de los juegos multiusuario en estos días están configurados para interactuar a través de un servidor intermedio, todos configurados y preconfigurados. Por otro lado, si todo lo que estoy leyendo en esta publicación es cierto, estará abarrotado y barato si / cuando despegue IPv6. Incluso los teléfonos celulares se están acercando a las velocidades de fibra. O al menos cable.

Si ejecuta un servidor interno y necesita golpearlo con el mismo nombre de dominio dentro o fuera de su red, siempre puede falsificar su dirección utilizando un enrutador basado en Linux y dnsmasq o lo que sea y entradas personalizadas en los hosts archivo para redirigirlo a la dirección local si está en el interior.

Realmente, no creo que sea realmente deseable que cada dispositivo tenga su propia dirección abierta flotando en la red. Si alguien quiere ofuscarse mientras te ataca, sucederá de todos modos. Pero eres un pato sentado si solo estás sentado allí con la brisa abierta. No, tomaré mi IPv4 y mi NAT cualquier día. Pero es bueno que esté allí.

De todos modos, quedarte dormido ahora ... probablemente más que decir, pero lo comprobaré mañana por si me perdí algo. Estoy seguro de que hay más.

jdmayfield
fuente
12
Uhm, es realmente deseable debido a conexiones más estables, velocidades más rápidas, internet más barato (los ISP no tienen que mantener sus servidores NAT, las asignaciones de bloque de IP por región / ciudad y barajar las cosas para sobrevivir en horas pico específicas). ¿Sabes lo confuso que es para los WebSockets cuando un usuario en dispositivos móviles salta de una torre celular a otra y obtiene una nueva IP? Se necesita mucho código de compensación, esfuerzo y energía para mantenerlo en funcionamiento. Su respuesta dice: esta torre puede estar perdiendo su base, pero aún no se ha derrumbado, por lo que está bien.
Tschallacka
11
Tiene algunas ideas erróneas sobre NAT y la seguridad. Por favor lea RFC 4864 .
Karl Bielefeldt
44
A este ritmo, será más de una generación. IPv6 tiene 20 años este año.
Michael Hampton
44
El RFC 2460 se publicó en diciembre de 1998. Varias partes del mismo se habían publicado antes de este punto y se habían realizado varios bancos de pruebas. IPv6, aproximadamente en su forma actual, se propuso en RFC 1883, que data de diciembre de 1995. Por lo tanto, se podría decir que IPv6 es incluso mayor de 20 años. Pero todos consideran que RFC 2460 es el punto donde IPv6 era lo suficientemente maduro como para implementarlo.
Michael Hampton
66
Por cierto, mientras estoy en el tema, debes tener en cuenta que ya hay plataformas de juego solo IPv6, como Xbox One. Una Xbox One con conectividad IPv4 y no IPv6 configura su propio túnel Teredo para llegar a Internet IPv6 , lo que, por supuesto, conlleva una penalización en latencia y confiabilidad. IPv4 está en una forma bastante triste cuando un túnel de Teredo se considera menos confiable que una conexión IPv4 de consumidor típica.
Michael Hampton