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?

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:

• Gastos generales administrativos que no solo cuestan tiempo y dinero, sino que también son propensos a errores y han provocado interrupciones.
• El gran uso de la capacidad de memoria de contenido direccionable (CAM) en los enrutadores troncales, que hace unos años condujo a una interrupción significativa en múltiples ISP cuando cruzó el límite de un modelo popular particular de enrutadores.

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.

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.

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.

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.

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.

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.

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.

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.

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)

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.