Protocolo de Descubrimiento de vecinos - Revision history

Jincera: /* Ciclo de vida de una dirección */

2012-07-07T01:19:01Z

‎Ciclo de vida de una dirección

Jincera: /* Descubrimiento de MTU */

2012-07-07T01:17:14Z

‎Descubrimiento de MTU

Jincera: /* Descubrimiento de MTU */

2012-07-07T01:15:01Z

‎Descubrimiento de MTU

Jincera: /* Descubrimiento de MTU */

2012-07-07T01:12:54Z

‎Descubrimiento de MTU

Jincera at 01:10, 7 July 2012

2012-07-07T01:10:37Z

Jincera at 19:04, 5 July 2012

2012-07-05T19:04:13Z

Jincera: /* Caso de redes NBMA */

2012-07-05T18:57:03Z

‎Caso de redes NBMA

Jincera: /* Caso de redes NBMA */

2012-07-05T18:56:03Z

‎Caso de redes NBMA

Jincera: /* Caso de redes NBMA */

2012-07-05T18:55:11Z

‎Caso de redes NBMA

Jincera: /* Autoconfiguración sin estado */

2012-07-05T18:54:34Z

‎Autoconfiguración sin estado

← Older revision		Revision as of 01:19, 7 July 2012
Line 368:		Line 368:


−	==Ciclo de vida de una dirección==	+	==Ciclo de vida de una dirección==

	Al generalizar en IPv6 el plan de direccionamiento CIDR, los prefijos quedan, en todos los casos, siendo propiedad de los operadores. Ya no pueden otorgarse "a perpetuidad" a los dispositivos. Para facilitar la renumeración de una máquina, la asignación de una dirección a una interfaz es temporal, las direcciones IPv6 no se entregan, sino que se prestan. Se asocia un tiempo de vida a la dirección, que indica el tiempo durante el cual la dirección pertenece a la interfaz. Cuando el tiempo de vida se ha agotada, la dirección deja de ser válida, se suprime de la interfaz y queda potencialmente éste puede prolongarse indefinidamente. La dirección local al enlace tiene un tiempo de vida ilimitado.		Al generalizar en IPv6 el plan de direccionamiento CIDR, los prefijos quedan, en todos los casos, siendo propiedad de los operadores. Ya no pueden otorgarse "a perpetuidad" a los dispositivos. Para facilitar la renumeración de una máquina, la asignación de una dirección a una interfaz es temporal, las direcciones IPv6 no se entregan, sino que se prestan. Se asocia un tiempo de vida a la dirección, que indica el tiempo durante el cual la dirección pertenece a la interfaz. Cuando el tiempo de vida se ha agotada, la dirección deja de ser válida, se suprime de la interfaz y queda potencialmente éste puede prolongarse indefinidamente. La dirección local al enlace tiene un tiempo de vida ilimitado.

@@ Line 663: / Line 663: @@
 * si se utiliza un protocolo tipo UDP, la responsabilidad de la fragmentación recaerá en una capa superior, eventualmente en la aplicación.  Será necesario que ésta:
 ** (1) pueda informarse del valor de PMTU autorizado, aún si éste cambia posteriormente, y
-** (2) pueda fragmentar los datos en consecuencia.  Para que estas dos condiciones se cumplan, IPv6 ha retenido un mecanismo de fragmentación (ver [[IPv6_QO#Fragmentación|fragmentación]]).
+** (2) pueda fragmentar los datos en consecuencia.  Para que estas dos condiciones se cumplan, IPv6 ha retenido un mecanismo de fragmentación (ver [[eIPv6_QO#Fragmentación|fragmentación]]).
 <tikz title=" Descubrimiento de MTU tercera fase: Emisión de un paquete de tamaño adecuado">
@@ Line 694: / Line 694: @@
 </tikz>
-Hay otro aspecto relacionado con la identificación de caminos para poder asociarles la información de PMTU. El implementador cuenta con varias posibilidades. Por ejemplo, puede identificar un camino por la dirección destino o por el identificador de flujo si este campo se utiliz, o por la ruta seguida en el caso en que ésta sea impuesta (ver Las extensiones#enrutamiento|enrutamiento]]).
+Hay otro aspecto relacionado con la identificación de caminos para poder asociarles la información de PMTU. El implementador cuenta con varias posibilidades. Por ejemplo, puede identificar un camino por la dirección destino o por el identificador de flujo si este campo se utiliz, o por la ruta seguida en el caso en que ésta sea impuesta (ver [[Las extensiones#enrutamiento|enrutamiento]]).

@@ Line 618: / Line 618: @@
 Inicialmente, el dispositivo supone que el PMTU de una cierta trayectoria es igual al MTU del enlace al que está directamente conectado.  Si sucede que los paquetes enviados por ese camino exceden el tamaño máximo autorizado por un enlace intermedio, el enrutador correspondiente eliminará esos paquetes y enviará un mensaje de error ICMPv6 tipo “paquete demasiado grande” donde indicará el MTU aceptable. Con esa información, el dispositivo reducirá el PMTU apropiado para esa ruta.
-Es posible que se deban efectuar varias iteraciones antes de obtener el PMTU que permita que los paquetes lleguen a su destino sin exceder el MTU de cada enlace recorrido.  El protocolo IPv6 garantiza que el MTU de todos los enlaces no puede ser menor de 1,280 octetos, por lo que éste es el umbral mínimo para el MTU.  Dado que este protocolo puede sufrir pérdidas de paquetes, se deja a las capas superiores gestionar la fiabilidad de la comunicación y restransmitir  paquetes si es necesario (paquete 6 del ejemplo).
+Es posible que se deban efectuar varias iteraciones antes de obtener el PMTU que permita que los paquetes lleguen a su destino sin exceder el MTU de cada enlace recorrido.  El protocolo IPv6 garantiza que el MTU de todos los enlaces no puede ser menor de 1,280 octetos, por lo que éste es el umbral mínimo para el PMTU.  Dado que este protocolo puede sufrir pérdidas de paquetes, se deja a las capas superiores gestionar la fiabilidad de la comunicación y restransmitir  paquetes si es necesario (paquete 6 del ejemplo).
 <tikz title=" Descubrimiento de MTU segunda fase: recepción de un mensaje ICMPv6">

@@ Line 614: / Line 614: @@
 </tikz>
-Por razones de eficacia, generalmente es preferible que la información intercambiada entre dispositivos esté contenida en datagramas de tamaño máximo.  Este tamaño depende de la ruta seguida por los datagramas y es igual al tamaño más grande autorizada por el conjunto de enlaces recorridos.  Se le llama PMTU, ''Path Maximum Transmission Unit'' (Unidad de transferencia de tamaño máximo sobre la trayectoria).
+Por razones de eficacia, generalmente es preferible que la información intercambiada entre dispositivos esté contenida en datagramas de tamaño máximo.  Este tamaño depende de la ruta seguida por los datagramas y es igual al tamaño más grande autorizado por el conjunto de enlaces recorridos.  Se le llama PMTU, ''Path Maximum Transmission Unit'' (Unidad de transferencia de tamaño máximo sobre la trayectoria).
 Inicialmente, el dispositivo supone que el PMTU de una cierta trayectoria es igual al MTU del enlace al que está directamente conectado.  Si sucede que los paquetes enviados por ese camino exceden el tamaño máximo autorizado por un enlace intermedio, el enrutador correspondiente eliminará esos paquetes y enviará un mensaje de error ICMPv6 tipo “paquete demasiado grande” donde indicará el MTU aceptable. Con esa información, el dispositivo reducirá el PMTU apropiado para esa ruta.

← Older revision		Revision as of 01:10, 7 July 2012
Line 575:		Line 575:

	* Si la tecnología del enlace lo permite y si la política de gestión de red lo autoriza, el enrutador tiene la posibilidad de optimizar el tráfico, notificando al dispositivo la verdadera dirección del destinatario, emitiendo un mensaje de [[#IR\|indicación de redirección]] (''ICMP Redirect''). Los paquetes subsecuentes ya no pasarán por el enrutador.		* Si la tecnología del enlace lo permite y si la política de gestión de red lo autoriza, el enrutador tiene la posibilidad de optimizar el tráfico, notificando al dispositivo la verdadera dirección del destinatario, emitiendo un mensaje de [[#IR\|indicación de redirección]] (''ICMP Redirect''). Los paquetes subsecuentes ya no pasarán por el enrutador.
		+
		+	===Caso de redes móviles===
		+
		+	La detección de duplicación de direcciones es un proceso relativamente largo, pues un dispositivo que desea garantizar la unicidad de su dirección, debe emitir un mensaje NS y esperar que no haya respuesta. Además, dado que es posible que la red pierda los mensajes NS, el dispositivo podría intentar varias veces de resolver su propia dirección antes de garantizar su unicidad. Por último, el mismo proceso se repite para las direcciones de enlace local y unicast global. En consecuencia, se requiere de varios segundos antes de que un dispositivo pueda emitir paquetes hacia la red. Para equipos móviles, este retardo, que se suma a los de descubierta de vecinos y a la autentificación, puede conducir a interrupciones de conectividad (por ejemplo, para aplicaciones de voz sobre IP).
		+
		+	El RFC 4429 flexibiliza esta situación al permitir que un sitio utilice su dirección aún si no se ha garantizado su unicidad. Este comportamiento es llamado DAD optimista (''optimistic DAD''). El estado tentativo (ver [[#Ciclo de vida de una dirección\| Ciclo de vida de una dirección]] se remplaza por un estado ''optimista'' durante el cual la exclusividad de la dirección no está garantizada pero se permite su uso. Paralelamente, se emite un DAD clásico. Los mensajes NS se emiten con el bit <tt>O</tt> (''Override'') apagado para que los caches de ND no se actualicen en caso de que esa dirección ya existiera en la red.
		+
		+	==Descubrimiento de MTU==
		+
		+	<tikz title="Descubrimiento de MTU primera fase: envío de un paquete demasiado grande">
		+	\clip (0, 0) rectangle (11,8);
		+	%\draw[help lines] (0,0) grid (10,7 );
		+
		+	\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,2)--(9,2);
		+
		+	\pgfputat{\pgfxy(0.8,3)}{\pgfbox[left,base]{\pgfuseimage{router}}}
		+	\pgfputat{\pgfxy(7.5,3)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
		+
		+	\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,2)--(1.5,3);
		+	\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,2)--(8,3);
		+
		+	\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,4)--(1.5,5);
		+	\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,5)--(9,5);
		+	\draw[line width=0.15cm,color=red!30,cap=round,join=round] (5.5,5)--(5.5,6);
		+	\pgfputat{\pgfxy(5,6)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
		+	\draw (8, 3.6) node {\small{A}};
		+	\draw (5.5, 6.6) node {\small{B}};
		+	\draw (1.5, 3.6) node {\small{R}};
		+
		+	\draw (1.5,1.5) node {\small{MTU=1500}};
		+	\draw (1.5,5.5) node {\small{MTU=1280}};
		+
		+	\draw (9.5, 3.5) node {\tiny{PMTU(*)=1500}};
		+
		+
		+	\draw [<-] (1.7,3) -- (1.7, 2.2) -- node [above = 10pt] { \tiny{A-$>$ B Size=1500}} (7.8, 2.2) -- (7.8, 3);
		+	}
		+	</tikz>
		+
		+	Por razones de eficacia, generalmente es preferible que la información intercambiada entre dispositivos esté contenida en datagramas de tamaño máximo. Este tamaño depende de la ruta seguida por los datagramas y es igual al tamaño más grande autorizada por el conjunto de enlaces recorridos. Se le llama PMTU, ''Path Maximum Transmission Unit'' (Unidad de transferencia de tamaño máximo sobre la trayectoria).
		+
		+	Inicialmente, el dispositivo supone que el PMTU de una cierta trayectoria es igual al MTU del enlace al que está directamente conectado. Si sucede que los paquetes enviados por ese camino exceden el tamaño máximo autorizado por un enlace intermedio, el enrutador correspondiente eliminará esos paquetes y enviará un mensaje de error ICMPv6 tipo “paquete demasiado grande” donde indicará el MTU aceptable. Con esa información, el dispositivo reducirá el PMTU apropiado para esa ruta.
		+
		+	Es posible que se deban efectuar varias iteraciones antes de obtener el PMTU que permita que los paquetes lleguen a su destino sin exceder el MTU de cada enlace recorrido. El protocolo IPv6 garantiza que el MTU de todos los enlaces no puede ser menor de 1,280 octetos, por lo que éste es el umbral mínimo para el MTU. Dado que este protocolo puede sufrir pérdidas de paquetes, se deja a las capas superiores gestionar la fiabilidad de la comunicación y restransmitir paquetes si es necesario (paquete 6 del ejemplo).
		+
		+	<tikz title=" Descubrimiento de MTU segunda fase: recepción de un mensaje ICMPv6">
		+	\clip (0, 0) rectangle (11,8);
		+	%\draw[help lines] (0,0) grid (10,7 );
		+
		+	\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,2)--(9,2);
		+
		+	\pgfputat{\pgfxy(0.8,3)}{\pgfbox[left,base]{\pgfuseimage{router}}}
		+	\pgfputat{\pgfxy(7.5,3)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
		+
		+	\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,2)--(1.5,3);
		+	\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,2)--(8,3);
		+
		+	\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,4)--(1.5,5);
		+	\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,5)--(9,5);
		+	\draw[line width=0.15cm,color=red!30,cap=round,join=round] (5.5,5)--(5.5,6);
		+	\pgfputat{\pgfxy(5,6)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
		+	\draw (8, 3.6) node {\small{A}};
		+	\draw (5.5, 6.6) node {\small{B}};
		+	\draw (1.5, 3.6) node {\small{R}};
		+
		+	\draw (1.5,1.5) node {\small{MTU=1500}};
		+	\draw (1.5,5.5) node {\small{MTU=1280}};
		+
		+	\draw (9.5, 3.5) node {\tiny{PMTU(*)=1500}};
		+
		+
		+
		+	\draw [->] (1.7,3) -- (1.7, 2.2) -- node [above = 10pt] { \tiny{R-$>$ A ICMP6 Error: Packet too big}} node [above] {\tiny{MTU=1280}} (7.8, 2.2) -- (7.8, 3);
		+	\draw (9.5, 3) node {\alert{\tiny{PMTU(B)=1280}}};
		+
		+	</tikz>
		+
		+	Si bien la determinación del PMTU se hace esencialmente durante los primeros intercambios entre los dispositivos comunicantes, es posible que pueda reactivarse durante una comunicación activa si, debido a un cambio de ruta, se debe recorrer un enlace con mayores restricciones de tamaño.
		+
		+	El emisor verifica también que el PMTU no ha aumentado enviando esporádicamente un paquete más grande. Si éste cruza la red sin problemas, el valor del PMTU se incrementará.
		+
		+	Cabe señalar que el algoritmo de descubrimiento de PMTU funciona igual para las comunicaciones punto a punto, o multipunto. En este último caso, el PMTU será el mínimo permitido para el conjunto de caminos hacia cada sitio destinatario del grupo de difusión.
		+
		+	La información de PMTU se utiliza de distintas formas dependiendo del ambiente en el que los datos a transmitir se segmentan:
		+
		+	* si se utiliza un protocolo tipo TCP, éste realizará la fragmentación de forma transparente a las aplicaciones en función de la información de PMTU que le comunique la capa IPv6.
		+	* si se utiliza un protocolo tipo UDP, la responsabilidad de la fragmentación recaerá en una capa superior, eventualmente en la aplicación. Será necesario que ésta:
		+	** (1) pueda informarse del valor de PMTU autorizado, aún si éste cambia posteriormente, y
		+	** (2) pueda fragmentar los datos en consecuencia. Para que estas dos condiciones se cumplan, IPv6 ha retenido un mecanismo de fragmentación (ver [[IPv6_QO#Fragmentación\|fragmentación]]).
		+
		+	<tikz title=" Descubrimiento de MTU tercera fase: Emisión de un paquete de tamaño adecuado">
		+	\clip (0, 0) rectangle (11,8);
		+	%\draw[help lines] (0,0) grid (10,7 );
		+
		+	\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,2)--(9,2);
		+
		+	\pgfputat{\pgfxy(0.8,3)}{\pgfbox[left,base]{\pgfuseimage{router}}}
		+	\pgfputat{\pgfxy(7.5,3)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
		+
		+	\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,2)--(1.5,3);
		+	\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,2)--(8,3);
		+
		+	\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,4)--(1.5,5);
		+	\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,5)--(9,5);
		+	\draw[line width=0.15cm,color=red!30,cap=round,join=round] (5.5,5)--(5.5,6);
		+	\pgfputat{\pgfxy(5,6)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
		+	\draw (8, 3.6) node {\small{A}};
		+	\draw (5.5, 6.6) node {\small{B}};
		+	\draw (1.5, 3.6) node {\small{R}};
		+
		+	\draw (1.5,1.5) node {\small{MTU=1500}};
		+	\draw (1.5,5.5) node {\small{MTU=1280}};
		+
		+	\draw (9.5, 3.5) node {\tiny{PMTU(*)=1500}};
		+	\draw (9.5, 3) node {\alert{\tiny{PMTU(B)=1280}}};
		+	\draw [<-] (1.7,3) -- (1.7, 2.2) -- node [above = 10pt] { \tiny{A-$>$ B Size=1280}} (7.8, 2.2) -- (7.8, 3);
		+	\draw [->] (1.7,4) -- (1.7, 4.8) -- (5.3, 4.8) -- (5.3, 6);
		+	</tikz>
		+
		+	Hay otro aspecto relacionado con la identificación de caminos para poder asociarles la información de PMTU. El implementador cuenta con varias posibilidades. Por ejemplo, puede identificar un camino por la dirección destino o por el identificador de flujo si este campo se utiliz, o por la ruta seguida en el caso en que ésta sea impuesta (ver Las extensiones#enrutamiento\|enrutamiento]]).
		+
		+
		+	Por último, se bien se recomienda encarecidamente que cada dispositivo implemente el mecanismo de detección de PMTU, éste no es obligatorio. Por lo tanto, un equipo que no cuente con él (por ejemplo, una ROM de arranque) deberá restringir el tamaño de los paquetes al mínimo permitido, es decir, 1,280 octetos.

	{{eSuivi\|Tabla de contenido\|Incio del capítulo\|DHCPv6\|DHCPv6}}		{{eSuivi\|Tabla de contenido\|Incio del capítulo\|DHCPv6\|DHCPv6}}

@@ Line 20: / Line 20: @@
 * Indicación de redirección. Este mensaje se utiliza cuando un enrutador conoce una trayectoria mejor (medida en número de saltos) para alcanzar un destino.
 :En IPv4 una indicación de redireccionamiento sólo puede servir para corregir la dirección del enrutador utilizado para acceder a una máquina fuera de la red local. Los dispositivos deben conocer todas las direcciones correspondientes a equipos conectados en su propia red local.
-:EnIPv6, la correspondencia entre prefijo y red local es menos rígida.  Es de esperar que un dispositivo no conozca todos los prefijos de su red local (si ésta es compartida por varios prefijos), o que un prefijo se comparta entre varios enlaces (lo que corresponde a una generalización del modelo de redes lógicas IP sobre ATM).  Bajo algunas configuraciones, la máquina emitirá sus paquetes al enrutador aún si el destinatario se encuentra en el mismo segmento que el emisor.  En este caso, el enrutador emitirá un mensaje de redirección para que la continuación del diálogo entre ellos haga de manera directa (véanse los ejemplos [[#IR|Indicación redirección]]).
+:EnIPv6, la correspondencia entre prefijo y red local es menos rígida.  Es de esperar que un dispositivo no conozca todos los prefijos de su red local (si ésta es compartida por varios prefijos), o que un prefijo se comparta entre varios enlaces (lo que corresponde a una generalización del modelo de redes lógicas IP sobre ATM).  Bajo algunas configuraciones, la máquina emitirá sus paquetes al enrutador aún si el destinatario se encuentra en el mismo segmento que el emisor.  En este caso, el enrutador emitirá un mensaje de redirección para que la continuación del diálogo entre ellos haga de manera directa (véanse los ejemplos [[#IR|Indicación de redirección]]).
 :En el caso más extremo, podría imaginarse en IPv6 que un dispositivo puede ser configurado para comunicarse únicamente con su enrutador por omisión. ICMPv6 ''redirect'' puede utilizarse entonces, para informar al dispositivo de destinatarios ubicados en el mismo enlace.

@@ Line 549: / Line 549: @@
 Para estos casos, el protocolo de descubrimiento de vecinos cuenta con un modo NBMA llamado también ''OffLink'', el cual solamente autoriza el diálogo con un enrutador.  Los intercambios comienzan de la misma forma:
-* El dispositivo que desea insertarse en la red, emite un mensaje RS (''Router Sollicitation”) utilizando la dirección destino FF02::2 (todos los enrutadores sobre el enlace. La red NBMA deberá enviar este mensaje hacia un enrutador.
+* El dispositivo que desea insertarse en la red, emite un mensaje RS (''Router Sollicitation'') utilizando la dirección destino FF02::2 (todos los enrutadores sobre el enlace. La red NBMA deberá enviar este mensaje hacia un enrutador.
 * El enrutador responde poniendo el bit <tt>L</tt> (OffLink) a 1 en la opción [[#información|Información sobre el prefijo]], indicando que todos los intercambios deben pasar por él.
 * El dispositivo construye su dirección global concatenando el prefijo a su identificador de interfaz.

@@ Line 574: / Line 574: @@
 </tikz>
-* Si la tecnología de enlace lo permite y si la política de gestión de red lo autoriza, el enrutador tiene la posibilidad de optimizar el tráfico, notificando al dispositivo la verdadera dirección del destinatario, emitiendo un mensaje de [[#IR|indicación de redirección]] (''ICMP Redirect'').  Los paquetes subsecuentes ya no pasarán por el enrutador.
+* Si la tecnología del enlace lo permite y si la política de gestión de red lo autoriza, el enrutador tiene la posibilidad de optimizar el tráfico, notificando al dispositivo la verdadera dirección del destinatario, emitiendo un mensaje de [[#IR|indicación de redirección]] (''ICMP Redirect'').  Los paquetes subsecuentes ya no pasarán por el enrutador.
 {{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

← Older revision		Revision as of 18:54, 5 July 2012
Line 476:		Line 476:

	</tikz>		</tikz>
−
−

	La configuración automática sin estado (RFC 2462) no requiere de ninguna configuración manual de los dispositivos, una configuración mínima para los enrutadores, y tampoco necesita de servidores adicionales. Se sirve del protocolo ICMPv6 y puede operar aún sin la presencia de enrutadores. En cambio, sí requiere de una subred con soporte a la difusión de paquetes. Este método sólo aplica para los dispositivos; no puede ser utilizada para configurar enrutadores. El principio básico de este mecanismo consiste en que una máquina genera su dirección IPv6 a partir de información local y de la proporcionada por un enrutador. El enrutador proporciona información sobre la subred asociada al enlace; anuncia el prefijo.		La configuración automática sin estado (RFC 2462) no requiere de ninguna configuración manual de los dispositivos, una configuración mínima para los enrutadores, y tampoco necesita de servidores adicionales. Se sirve del protocolo ICMPv6 y puede operar aún sin la presencia de enrutadores. En cambio, sí requiere de una subred con soporte a la difusión de paquetes. Este método sólo aplica para los dispositivos; no puede ser utilizada para configurar enrutadores. El principio básico de este mecanismo consiste en que una máquina genera su dirección IPv6 a partir de información local y de la proporcionada por un enrutador. El enrutador proporciona información sobre la subred asociada al enlace; anuncia el prefijo.