Direccionamiento-Preguntas - Revision history

Jincera: /* Direcciones anycast sobre un mismo enlace */

2012-05-08T01:43:27Z

‎Direcciones anycast sobre un mismo enlace

Jincera: /* Direcciones anycast sobre un mismo enlace */

2012-05-08T01:42:30Z

‎Direcciones anycast sobre un mismo enlace

Jincera: /* Direcciones anycast sobre un mismo enlace */

2012-05-08T01:41:30Z

‎Direcciones anycast sobre un mismo enlace

Jincera at 01:39, 8 May 2012

2012-05-08T01:39:23Z

Jincera: New page: {{eSuivi|Direccionamiento-Implementacion|Implementación|Direccionamiento-Investigaciones|Problemas de investigación}} =Direcciones Anycast= El principio subyacente del direccionamiento...

2012-05-08T01:35:51Z

New page: {{eSuivi|Direccionamiento-Implementacion|Implementación|Direccionamiento-Investigaciones|Problemas de investigación}} =Direcciones Anycast= El principio subyacente del direccionamiento...

New page

{{eSuivi|Direccionamiento-Implementacion|Implementación|Direccionamiento-Investigaciones|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 <tt> 192.88.99.0/24 </tt>, correspondiente a los extremos de los túneles (<tt> 192.88.99.1 </tt>) 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.

<tikz title="Direcciones Anycast">
\clip (0, 0) rectangle (11,4);
% \draw[help lines] (0,0) grid (10,3);

% \draw (0, 3.6) node [right] {Unique Local IPv6 Unicast Addresses:};

\draw (0,2) node [right, draw, shade, top color = gray!50, minimum width=5.5cm, minimum height=1cm] {Prefix};
\draw (5.5,2) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {Interface ID};

\draw (2.7, 2.7) node {\tiny{64}};
\draw (8, 2.7) node {\tiny{64}};

</tikz>

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.

{|
|+'''''Asignación de identificadores Anycast'''''
!Descripción !! Valor(hexadecimal)
|-style="background:silver"
||Reservado || 0x7F
|-
||Dirección Anycast del agente madre (cf.[[Movilidad en IPv6]])|| 0x7E
|-style="background:silver"
|Reservado || 0x00 à 0x7D
|}

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.

<tikz title="Anycast sobre el enlace">

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,1)--(9,1);
\foreach \i/\j in {1/1, 3/2, 5/3 } {
\pgfputat{\pgfxy(\i,3)}{\pgfbox[left,base]{\pgfuseimage{compleftred}}}
\draw[line width=0.15cm,color=red!30,cap=round,join=round] ([xshift=0.4cm]\i,1)--([xshift=0.4cm]\i,3);
\draw ([xshift=0.5cm]\i,2.5) node {$\alpha$::\j};
\draw ([xshift=0.5cm]\i,2.1) node {$\alpha$::FFF1};
}

\draw (8, 2) node [right, color=blue]{\tiny{$\alpha$::FFF1 $\rightarrow$ MAC2}};

\draw [->, thick] (8.3, 3) -- (8.3, 0.8) -- ([xshift=0.9cm]3, 0.8) -- ([xshift=0.9cm]3, 3);

\pgfputat{\pgfxy(7.5,3)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,1)--(8,3);

</tikz>

==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.

{{eSuivi|Direccionamiento-Implementacion|Implementación|Direccionamiento-Investigaciones|Problemas de investigación}}

@@ Line 70: / Line 70: @@
   	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.
+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.

@@ Line 97: / Line 97: @@
 ||Reservado    || 0x7F
 |-
-||Dirección Anycast del agente madre (cf.[[Movilidad en IPv6]])|| 0x7E
+||Dirección Anycast del agente madre (''cf.'' [[Movilidad en IPv6]])|| 0x7E
 |-style="background:silver"
 |Reservado    || 0x00 à 0x7D

@@ Line 51: / Line 51: @@
 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'''
+ # '''ifconfig en3'''
- en3: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
+  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

@@ Line 7: / Line 7: @@
 ==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:
+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;
@@ Line 27: / Line 27: @@
   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.
+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:
+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
@@ Line 70: / Line 70: @@
   	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.
+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.
+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.
 <tikz title="Direcciones Anycast">
@@ Line 88: / Line 88: @@
 </tikz>
-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.
+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.
@@ Line 102: / Line 102: @@
 |}
-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.
+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.
+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.
 <tikz title="Anycast sobre el enlace">