Implementaciones

Tabla de contenido

Problemas de investigación

Direcciones Anycast

El principio subyacente del direccionamiento anycast (llamado a veces difusión por proximidad) es relativamente simple: en vez de enviar un paquete a una interfaz determinada, el paquete es enviado a una dirección (anycast) que representa un conjunto de máquinas en un dominio específico. Una dirección anycast puede designar un servicio por una dirección bien conocida; de esta manera, no es necesario consultar un servidor para conocer la ubicación de un dispositivo.

Prefijo virtual

Existen dos métodos para utilizar el direccionamiento anycast. El primero consiste en definir un prefijo virtual, que es difundido a varios lugares en Internet. Este método ya se utiliza ampliamente en IPv4 para acceder a determinados servidores. Por ejemplo, varios servidores raíz del DNS (ver http://www.root-servers.org) comparten la misma dirección y por lo tanto el mismo prefijo. Este prefijo se anuncia por varias redes. Para el DNS, esto presenta varias ventajas:

• La resolución se hace lo más cerca posible (de acuerdo a la métrica del protocolo de enrutamiento utilizado) del usuario, lo que reduce el tiempo de respuesta;
• los ataques por denegación de servicio son más difíciles, pues es necesario que todos los ataques vengan de una zona; de lo contrario, se distribuyen sobre múltiples servidores;
• El número de direcciones que deben conocer los resolvedores, es limitado.

El mecanismo de transición 6to4 también utiliza esta técnica. El prefijo 192.88.99.0/24 , correspondiente a los extremos de los túneles ( 192.88.99.1 ) que da acceso a la Internet v6, es anunciado varios lugares en la red. Ello permite preconfigurar los dispositivos con esa dirección y ofrecer al usuario el extremo de túnel más cercano. En caso de que éste desaparezca, el mecanismo de enrutamiento de Internet apuntará automáticamente hacia otro túnel.

Este mecanismo funciona de la misma forma con las direcciones IPv6. El siguiente ejemplo ilustra las direcciones IPv6 de un servidor DNS. Visto desde Francia, en la red Renater, la ruta para alcancar este dispositivo es la siguiente:

%traceroute6 2001:500:2f::f
traceroute6 to 2001:500:2f::f (2001:500:2f::f) from 2001:660:7301:3103:223:6cff:fe97:679c, 30 hops max, 12 byte packets
 1  2001:660:7301:3103::1  4.774 ms  1.198 ms  2.764 ms
 2  2001:660:7301:3036::1  3.364 ms  2.215 ms  1.417 ms
 3  vl856-gi9-9-rennes-rtr-021.noc.renater.fr  2.892 ms  6.794 ms  2.195 ms
 4  te4-1-caen-rtr-021.noc.renater.fr  7.706 ms  5.1 ms  4.193 ms
 5  te4-1-rouen-rtr-021.noc.renater.fr  6.527 ms  6.296 ms  6.661 ms
 6  te0-0-0-1-paris1-rtr-001.noc.renater.fr  8.702 ms  10.26 ms  8.696 ms
 7  F-root-server.sfinx.tm.fr  8.495 ms  8.607 ms  8.664 ms
 8  f.root-servers.net  8.738 ms  9.171 ms  8.702 ms

Como lo indica este traceroute, la máquina se encuentra en sfinx, un nodo de intercambio de tráfico Internet ubicado en Francia.

Un traceroute al mismo destino desde una computadora ubicada en los Estados Unidos (Hawaii), proporciona el siguiente resultado:

traceroute6 to 2001:500:2f::f (2001:500:2f::f) from 2001:1888:0:1:2d0:b7ff:fe7d:bed6, 64 hops max,  12 byte packets
 1  apapane-fe0-0-1  1.169 ms  0.970 ms  0.947 ms
 2  r1.mdtnj.ipv6.att.net  121.159 ms  121.737 ms  121.378 ms
 3  bbr01-p1-0.nwrk01.occaid.net  130.468 ms  129.640 ms  130.845 ms
 4  bbr01-g1-0.asbn01.occaid.net  131.372 ms  131.596 ms  131.421 ms
 5  bbr01-g1-0.atln01.occaid.net  144.937 ms  144.550 ms  144.834 ms
 6  bbr01-p1-0.dlls01.occaid.net  166.709 ms  196.177 ms  165.983 ms
 7  dcr01-p1-5.lsan01.occaid.net  138.437 ms  138.690 ms  138.544 ms
 8  bbr01-g0-2.irvn01.occaid.net  138.552 ms  137.956 ms  137.649 ms
 9  dcr01-g1-2.psdn01.occaid.net  137.629 ms  138.030 ms  141.332 ms 
10  bbr01-f1-5.snfc02.occaid.net  138.501 ms  138.511 ms  137.483 ms
11  exit.sf-guest.sfo2.isc.org  147.941 ms  144.929 ms  145.956 ms
12  f.root-servers.net  139.063 ms  139.715 ms  142.571 ms

El servidor se encuentra en las instalaciones del ISC.

Direcciones anycast sobre un mismo enlace

El segundo tipo de direcciones anycast corresponde a la asignación de varias direcciones idénticas en el mismo enlace. Este método es más complejo de gestionar, ya que por lo general, Ipv6 verfica que una dirección no esté ya presente a través del mecanismo de detección de direcciones duplicadas (DDD). Como no hay forma de distinguir entre una dirección anycast y una dirección unicast, se debe desactivar la detección de direcciones duplicadas especificando que se trata de una dirección anycast al momento de asignar la dirección a la interfaz, como se muestra en el ejemplo siguiente:

# ifconfig en3
 en3: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	inet6 fe80::223:6cff:fe97:679c%en3 prefixlen 64 scopeid 0x5 
	inet 192.168.103.177 netmask 0xffffff00 broadcast 192.168.103.255
	inet6 2001:660:7301:3103:223:65ff:fe97:679c prefixlen 64 autoconf 
	ether 00:23:6c:97:67:9c 
	media: autoselect status: active
	supported media: autoselect
# ifconfig en3 inet6 2001:660:7301:3103:FF::FF anycast
# ifconfig
en3: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	inet6 fe80::223:6cff:fe97:679c%en3 prefixlen 64 scopeid 0x5 
	inet 192.168.103.177 netmask 0xffffff00 broadcast 192.168.103.255
	inet6 2001:660:7301:3103:223:65ff:fe97:679c prefixlen 64 autoconf 
	inet6 2001:660:7301:3103:ff::ff prefixlen 64 anycast 
	ether 00:23:6c:97:67:9c 
	media: autoselect status: active
	supported media: autoselect

Si bien el concepto de anycast es simple en principio, su implementación resulta complicada. Por otra parte, este concepto sigue siendo fundamentalmente un tema de investigación. Un argumento de escala justifica esta cautela: no se han tenido experiencias de gran envergadura, análogos al proyecto Mbone para la difusión restringida (multicast). Quizás las redes de sensores podrían facilitar un uso a mayor escala del mecanismo anycast. Por ejemplo, a la pregunta ¿cuál es la temperatura ambiente de la habitación?, el primer sensor capaz de atenderla enviaría la respuesta, mientras que los otros sensores permanecerían en silencio.

La figura Direcciones Anycast muestra la estructura de estas direcciones. Contiene un campo de prefijo y un identificador anycast. El campo de prefijo es el mismo que se utiliza para las direcciones unicast. A diferencia de las estructuras de direccionamiento vistas anteriormente, no se especifica la longitud del prefijo ya que una dirección anycast debe poder adaptarse tanto a los planes de direccionamiento existentes (en los que la longitud del prefijo es generalmente de 64 bits), como a planes futuros que pudieran tener tamaños diferentes.

Figure : Direcciones Anycast

Como las direcciones anycast se asignan en el mismo espacio de direccionamiento que las unicast, se crean mediante la asignación de una misma dirección unicast a distintos nodos. Cada uno de estos nodos debe ser configurado notificando que la dirección asignada es de tipo anycast; de lo contrario, habría duplicidad de una dirección unicast. La única forma de diferenciar una dirección anycast de una unicast, consiste en observar el campo identificador anycast, el cual difiere de un identificador de interfaz. La secuencia binaria formada por una cadena de 0 fue el primer valor seleccionado. Permite identificar enrutadores en el mismo enlace. El RFC 2526 define las reglas de construcción de otros identificadores anycast en el enlace, reservando los 128 identificadores de interfaz local de mayor peso (los más elevados). Con ello se busca evitar conflictos con la asignación de direcciones manuales, que suele iniciar asignando los identificadores menos significativos, hacia los de mayor peso. La tabla Asignación de identificadores Anycast muestra la asignación de los identificadores más utilizados.

Se puede observar que el uso de anycast no se ha generalizado, ya que a la fecha, únicamente se ha definido un valor, que corresponde con el agente de base (home agent) de IPv6 Móvil. Esto podría cambiar con la introducción de IPv6 en las redes de sensores. De hecho, uno de los intereses del direccionamiento anycast, es le de designar una función más que un dispositivo en particular. Con las redes de sensores, el interés se entra más en la información que en el dispositivo que permite obtenerla, como en el ejemplo de los sensores interrogados sobre la temperatura de una habitación: puede ser suficiente con el valor recibido por el primero en atender la solicitud.

Con las direcciones anycast, varios dispositivos en un enlace físico tienen la misma dirección IPv6. Sin embargo, no se trata de enviar la misma información a todos estos dispositivos como ocurre en multicast, sino de escoger sólo uno. Una posibilidad para elegir a cuál, es utilizar el mecanismo de descubrimiento de vecinos (ver Descubrimiento de vecinos) para encontrar la asociación entre la dirección IPv6 y la dirección MAC.

La figura Anycast sobre el enlace muestra este funcionamiento. La estación A envía un mensaje de solicitud de vecino para determinar la dirección MAC del dispositivo. Tres servidores reciben la solicitud y responden. La estación A tomará una de estas respuestas y dialogará punto a punto con el dispositivo seleccionado.

Figure : Anycast sobre el enlace

Restricciones de Anycast

Como el corresponsal puede variar, ya sea por modificaciones de enrutamiento o de la tabla de resolución de direcciones, no puede guardarse un estado (aunque ello pueda causar una desincronización). Por lo mismo, los protocolos de capa 4 orientados a conexión, como TCP, no pueden ser utilizados. Anycast debe limitarse a consultas simples del tipo pregunta/respuesta o la gestión de túneles.

Implementaciones

Tabla de contenido

Problemas de investigación