Ir al contenido

Difusión por proximidad

De Wikipedia, la enciclopedia libre
Esta es una versión antigua de esta página, editada a las 18:04 21 jun 2024 por 189.201.7.231 (discusión). La dirección URL es un enlace permanente a esta versión, que puede ser diferente de la versión actual.

Anycast o alguna difusión es una forma de direccionamiento, encaminamiento 3324493820 enrutamiento en la que la información es encaminada o enrutada al mejor destino desde el punto de vista de la topología de la red. En la red internet, una dirección IP 3324493820 se puede anunciar desde varios puntos diferentes. Los routers intermedios encaminan el paquete hasta el destino más cercano. Por ejemplo un08:F4:58:AF:56:0C ::identificador anycast de un teléfono 3324493820 . Un paquete enviado a una dirección anycast es entregado a la máquina más próxima desde el punto de vista del tiempo de latencia.

El origen del término viene del inglés y su similitud con unicast, broadcast y multicast:

  • En unicast, cada dirección destino se corresponde con un único destino.
  • En broadcast y multicast se asocia una dirección destino a propio finales.
  • En anycast también hay una asociación de una dirección destino propia máquina La diferencia está en que se selecciona una de estas máquinas para ser la destinataria de la información.

En Internet se suele implementar anycast usando BGP, anunciando el mismo rango IP desde diferentes lugares. El resultado es que los routers eligen la ruta más cercana de entre todos los anuncios que reciben y enrutan toda la información hacia el destino más cercano.

Anycast se suele usar con protocolos no orientados a la conexión (como UDP en internet), dado que los protocolos orientados a la conexión (como TCP) necesitan mantener información del estado de la comunicación y en anycast, la máquina destino puede variar sin previo aviso. Para protocolos en los que se requiere que la sesión completa use el mismo servidor se pueden usar sistemas como GeoDNS. Por ello, anycast se suele usar para dar alta disponibilidad y equilibrado de carga en protocolos sin gestión del estado, como por ejemplo, en el acceso a información replicada.

Aplicaciones

Para mejorar DNS

Algunos servidores raíz del sistema DNS están distribuidos geográficamente para repartir la carga y evitar que la caída de un servidor afecte ostensiblemente a la navegación por internet.[1]​ En concreto, los servidores C, F, I, J, K y M existen en muchas ciudades de continentes diferentes y usan anycast para dar un servicio descentralizado. Como consecuencia de ello, la mayor parte de los servidores DNS están fuera de los Estados Unidos, aunque su nombre indique lo contrario. Asimismo, un servicio complementario, que responde negativamente consultas de direcciones privadas (RFC 1918), también está configurado con anycast y se reporta a través del AS112.[2]

Para ayudar a la transición a IPv6

Hay una puerta de enlace predeterminada para el protocolo de transición 6to4 que usa la dirección IP anycast 192.88.99.1.[3]​ Esto permite que existan muchos proveedores que implementen puertas de enlace 6to4 sin que sea necesario que los hosts sepan cuál es la puerta de enlace específica de su proveedor. Usando esta dirección, los paquetes siempre irán a la puerta de enlace más cercana, generalmente la de nuestro proveedor.

Ataques distribuidos y anycast

El uso de anycast en Internet ayuda a contener un ataque distribuido de denegación de servicio y reducir su efectividad. Es una de las razones por las que se propuso el uso de anycast en DNS. Dado que el tráfico es enrutado al nodo más cercano y el atacante usualmente no puede controlar esto, se distribuye el ataque entre los servidores cercanos. Esto a menudo supone que no todos los servidores sufren el ataque y es una razón importante para usar anycast.

Seguridad

Anycast permite redirigir paquetes que van a una determinada IP a otra máquina si la información de ruta que mandamos es aceptada por los routers intermedios. Aunque esto parece inseguro a primera vista, es lo mismo que ocurre con el resto de informaciones de ruta en IP. Como ocurría con el enrutado IP convencional, hay que filtrar cuidadosamente a quien se permite propagar anuncios de ruta para prevenir ataques man-in-the-middle y ataque de descarte de paquetes.

Fiabilidad

Anycast proporciona una alta fiabilidad, dado que permite la recuperación automática ante fallos de las máquinas. Cuando se usa anycast, se suelen monitorizar las funciones del servidor con un mecanismo llamado "heartbeat" (latido de corazón). En caso de que un servidor falle y deje de mandar esos "latidos", se asume que el servidor ha dejado de funcionar y la ruta se reemplaza. En ocasiones, esto lo hacen los propios servidores, anunciando el prefijo anycast al router externo usando OSPF o cualquier otro protocolo Interior Gateway Protocol (IGP). Si el servidor se cae, el router externo dejará de anunciar la ruta y el resto de enrutadores actualizarán sus tablas en consecuencia. Esta funcionalidad es muy importante, porque si se sigue anunciando un servidor que ya no funciona, aparecerá un "agujero negro" para los clientes cercanos. Esta manera de fallar es lo peor que le puede ocurrir a un sistema anycast. En cualquier caso, solamente afecta a los clientes cercanos, y nunca a la totalidad de los usuarios.

Local contra Global

En algunos despliegues anycast en Internet hay diferencias entre los nodos locales y globales. Los nodos locales se suelen usar para mejorar el acceso de un grupo de usuarios locales. Estos nodos se suelen anunciar usando la opción no-export de BGP para evitar que la ruta se propague por internet, es decir, el anuncio se restringe al área local. Cuando se implementan nodos locales y globales, los anuncios de nodos globales se anuncian como AS (sistemas autónomos), de manera que un anuncio de nodo local se prefiere a uno de un nodo global.

Los servidores de nombres raíz F y K usan nodos locales y globales.

Referencias

  1. Cómo se explica en el RFC 3258 (www.ietf.org/rfc/rfc3258.txt).
  2. IANA (15 de diciembre de 2011). «Abuse Issues and IP Addresses» (en inglés). Consultado el 11 de mayo de 2012. 
  3. Cómo se explica en el RFC 3068 (www.ietf.org/rfc/rfc3068.txt).

Véase también

Enlaces externos