Difference between revisions of "Protocolo de Descubrimiento de vecinos"
From Livre IPv6
(→Ciclo de vida de una dirección) |
|||
| (27 intermediate revisions by the same user not shown) | |||
| 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. | * 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. | :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 [[ | + | :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. | :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 26: | Line 26: | ||
* Autoconfiguración sin estado (''stateless autoconfiguration'', RFC 2462). Se utiliza cuando no es necesaria una gestión administrativa de las direcciones asignadas dentro de un sitio. Estos mecanismos se describen más adelante en este capítulo. | * Autoconfiguración sin estado (''stateless autoconfiguration'', RFC 2462). Se utiliza cuando no es necesaria una gestión administrativa de las direcciones asignadas dentro de un sitio. Estos mecanismos se describen más adelante en este capítulo. | ||
| − | * Autoconfiguración con estado (''statefull autoconfiguration''). Se utiliza cuando un sitio requiere de un control estricto de la asignación de direcciones (cf | + | * Autoconfiguración con estado (''statefull autoconfiguration''). Se utiliza cuando un sitio requiere de un control estricto de la asignación de direcciones (''cf'' [[Configuración con estado: DHCPv6 | DHCPv6]]). |
Sin embargo, el uso de DHCPv6 para obtener la dirección se controla mediante el protocolo de descubrimiento de vecinos. | Sin embargo, el uso de DHCPv6 para obtener la dirección se controla mediante el protocolo de descubrimiento de vecinos. | ||
| Line 103: | Line 103: | ||
* El bit <tt>R</tt>, indica, cuando vale 1, que el campo prefijo contiene la dirección global de un enrutador ''agente base''. Los bits de mayor peso aún pueden utilizarse para formar un prefijo. | * El bit <tt>R</tt>, indica, cuando vale 1, que el campo prefijo contiene la dirección global de un enrutador ''agente base''. Los bits de mayor peso aún pueden utilizarse para formar un prefijo. | ||
* El campo duración de validez indica, en segundos, la duración durante la cual el prefijo es válido. | * El campo duración de validez indica, en segundos, la duración durante la cual el prefijo es válido. | ||
| − | * El campo duración preferente indica la duración, en segundos, durante la cual una dirección formada con el protocolo de configuración sin estado se mantiene ''preferente'' (cf | + | * El campo duración preferente indica la duración, en segundos, durante la cual una dirección formada con el protocolo de configuración sin estado se mantiene ''preferente'' (''cf'' [[Planes de direccionamiento|Tiempo de vida de las direcciones]]). |
Para estos dos campos, un valor de <tt>0xffffffff</tt> representa una duración infinita. Estos campos pueden servir durante la fase de transición de un proveedor de acceso a otro; es decir, de un prefijo a otro. | Para estos dos campos, un valor de <tt>0xffffffff</tt> representa una duración infinita. Estos campos pueden servir durante la fase de transición de un proveedor de acceso a otro; es decir, de un prefijo a otro. | ||
| Line 128: | Line 128: | ||
Esta opción es utilizada por el mensaje de indicación de redirección. Permite encapsular los primeros octetos del paquete IPv6 que provocó la emisión de este mensaje, como ocurre con los mensajes de error de ICMPv6. | Esta opción es utilizada por el mensaje de indicación de redirección. Permite encapsular los primeros octetos del paquete IPv6 que provocó la emisión de este mensaje, como ocurre con los mensajes de error de ICMPv6. | ||
| − | El campo tipo tiene el valor 4. El tamaño de esta opción debe evitar que el paquete IPv6 rebase los 1280 octetos (cf | + | El campo tipo tiene el valor 4. El tamaño de esta opción debe evitar que el paquete IPv6 rebase los 1280 octetos (''cf'' figura ''Formato de la opción cabecera de redirección''). Sin embargo, el paquete debe contener la mayor cantidad de información posible. |
== <div id="MTU">MTU</div> == | == <div id="MTU">MTU</div> == | ||
| Line 193: | Line 193: | ||
</tikz> | </tikz> | ||
| − | El mensaje de solicitud de enrutador (cf | + | El mensaje de solicitud de enrutador (''cf'' figura Formato de los paquetes de solicitud de enrutador) es emitido al iniciar un dispositivo para recibir más rápidamente la información del enrutador. Este mensaje se envía a la dirección IPv6 multicast reservada a los enrutadores en el mismo enlace <tt>FF02::2</tt>. Si el dispositivo aún no conoce su dirección fuente, se utiliza la dirección no especificada. |
El campo opción normalmente contiene la dirección física del dispositivo. | El campo opción normalmente contiene la dirección física del dispositivo. | ||
| Line 228: | Line 228: | ||
</tikz> | </tikz> | ||
| − | Este mensaje (cf | + | Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de enrutador'') es emitido periódicamente por los enrutadores, o bien, en respuesta a un mensaje de solicitud de enrutador generado por un dispositivo. El campo dirección fuente contiene la dirección de enlace local del enrutador, mientras que el campo dirección destino contiene la dirección del dispositivo que generó la solicitud, o la dirección de todas las estaciones (<tt>ff02::01</tt>). |
| − | Cuando el campo de máximo número de saltos tiene un valor distinto de cero, muestra el valor que podría colocarse en el campo de número de saltos de los paquetes emitidos. El bit <tt>M</tt> indica que una dirección del dispositivo debe ser obtenida mediante un protocolo de configuración (cf | + | Cuando el campo de máximo número de saltos tiene un valor distinto de cero, muestra el valor que podría colocarse en el campo de número de saltos de los paquetes emitidos. El bit <tt>M</tt> indica que una dirección del dispositivo debe ser obtenida mediante un protocolo de configuración (''cf'' [[Configuración con estado:DHCPv6]]). El bit <tt>O</tt> también indica la presencia de un servicio de configuración para obtener información adicional a la dirección. Si no es posible obtener la dirección mediante un servidor, el dispositivo procede a realizar una configuración sin estado, concatenando su identificador de interfaz a los prefijos que conoce. El bit <tt>H</tt> indica que el enrutador puede ser utilizado como agente base por un nodo móvil (''cf'' [[Desplazamientos_de_móviles#Anuncio_del_agente_base |Anuncio del agente base]]). |
El campo tiempo de vida del enrutador indica el período (en segundos) durante el cual el equipo que emite el anuncio realizará funciones de enrutador por omisión. El valor máximo corresponde a 18 horas 12 minutos, pero como este mensaje se emite periódicamente, en la práctica no existe un límite para el tiempo de vida de un enrutador. Un valor de <tt>0</tt> indica que el dispositivo no cumple con las funciones de enrutador por omisión. Este tiempo de vida no se aplica a las opciones transportadas por este mensaje. | El campo tiempo de vida del enrutador indica el período (en segundos) durante el cual el equipo que emite el anuncio realizará funciones de enrutador por omisión. El valor máximo corresponde a 18 horas 12 minutos, pero como este mensaje se emite periódicamente, en la práctica no existe un límite para el tiempo de vida de un enrutador. Un valor de <tt>0</tt> indica que el dispositivo no cumple con las funciones de enrutador por omisión. Este tiempo de vida no se aplica a las opciones transportadas por este mensaje. | ||
| Line 267: | Line 267: | ||
| − | Este mensaje (cf | + | Este mensaje (''cf'' figura ''Formato de los paquetes de solicitud de un vecino'') permite obtener información a partir de un equipo vecino, es decir, localizado en el mismo enlace físico (o conectado a través de puentes). El mensaje puede ser emitido explícitamente a él, o enviado con una dirección de difusión. En el caso de determinación de la dirección física, éste corresponde a la solicitud de ARP en IPv4. |
| − | El campo dirección fuente del paquete IPv6 contiene ya sea la dirección local al enlace, una dirección global o la dirección no especificada. El campo destino puede contener la dirección de difusión múltiple solicitada correspondiente a la dirección buscada (cf | + | El campo dirección fuente del paquete IPv6 contiene ya sea la dirección local al enlace, una dirección global o la dirección no especificada. El campo destino puede contener la dirección de difusión múltiple solicitada correspondiente a la dirección buscada (''cf'' [[Direccionamiento_multicast#Identificador_de_grupo|Identificador de grupo]]) o la dirección del dispositivo (en el caso de una detección de inaccesibilidad de vecinos, ''NUD''). |
El campo dirección del destino contiene la dirección IPv6 del equipo buscado. El campo opción generalmente contiene la dirección física de la fuente. | El campo dirección del destino contiene la dirección IPv6 del equipo buscado. El campo opción generalmente contiene la dirección física de la fuente. | ||
| − | == <div Id="NA"> Anuncio de vecino</div> == | + | == <div Id="NA"> Anuncio de un vecino</div> == |
| − | <tikz title="Formato de los paquetes de anuncio de vecino"> | + | <tikz title="Formato de los paquetes de anuncio de un vecino"> |
\clip (0.2, 1.5) rectangle (11.1,7.1); | \clip (0.2, 1.5) rectangle (11.1,7.1); | ||
| Line 298: | Line 298: | ||
</tikz> | </tikz> | ||
| − | Este mensaje (cf | + | Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de un vecino'') se emite en respuesta a una solicitud, aunque también puede ser emitido de forma espontánea para propagar la información de cambio de dirección física, o del estado de "enrutador". Para el caso de la determinación de la dirección física, es equivalente a la respuesta ARP en IPv4. |
* El bit <tt> R </tt> se pone a 1 si el remitente es un enrutador. Este bit se utiliza para permitir la detección de un enrutador que se convierte en un equipo ordinario. | * El bit <tt> R </tt> se pone a 1 si el remitente es un enrutador. Este bit se utiliza para permitir la detección de un enrutador que se convierte en un equipo ordinario. | ||
| Line 331: | Line 331: | ||
</tikz> | </tikz> | ||
| − | La técnica de redirección es la misma que en IPv4. Un dispositivo sólo conoce los prefijos de las redes a las que está conectado directamente y la dirección de un enrutador por omisión. Si la ruta se puede optimizar, el enrutador por omisión envía un mensaje para indicar que existe un camino más corto. De hecho, como en IPv6 el enrutador por omisión se establece de forma automática, las rutas no necesariamente son las mejores ( | + | La técnica de redirección es la misma que en IPv4. Un dispositivo sólo conoce los prefijos de las redes a las que está conectado directamente y la dirección de un enrutador por omisión. Si la ruta se puede optimizar, el enrutador por omisión envía un mensaje para indicar que existe un camino más corto. De hecho, como en IPv6 el enrutador por omisión se establece de forma automática, las rutas no necesariamente son las mejores (''cf'' figura ''Enrutamiento por omisión no óptimo''). |
Otro caso particular en IPv6 ocurre con los dispositivos que se encuentran en el mismo enlace físico, pero tienen diferentes prefijos. La comunicación entre ellos pasa inicialmente a traves de enrutador por omisión hasta que éste notifica que existe una ruta directa entre ellos. | Otro caso particular en IPv6 ocurre con los dispositivos que se encuentran en el mismo enlace físico, pero tienen diferentes prefijos. La comunicación entre ellos pasa inicialmente a traves de enrutador por omisión hasta que éste notifica que existe una ruta directa entre ellos. | ||
| Line 347: | Line 347: | ||
IPv6 también utiliza este mensaje para optimizar la resolución fuera del enlace para el [[#Caso de redes NBMA |caso de redes NBMA]]. | IPv6 también utiliza este mensaje para optimizar la resolución fuera del enlace para el [[#Caso de redes NBMA |caso de redes NBMA]]. | ||
| + | |||
| + | |||
| + | = Configuración automática = | ||
| + | Tradicionalmente, la configuración de una interfaz de red de una máquina se hacía manualmente. Esto suele ser un trabajo lento y propenso a errores. Con IPv6, se automatiza el proceso de configuración y se introducen, al mismo tiempo, mecanismos de funcionamiento inmediato (''plug and play'') a la interfaz de red. La configuración automática significa que un dispositivo obtendrá toda la información necesaria para su conexión a una red local IP sin ninguna intervención humana. En el caso ideal, cualquier usuario desempaca su nuevo equipo, lo conecta a la red local y lo ve funcionar sin tener que introducir la información propia de "especialistas". Ahora vamos a discutir otro aspecto de la configuración automática de IPv6, la auto-configuración de direcciones, que tiene como objetivos: | ||
| + | |||
| + | * La adquisición de una dirección cuando un dispositivo está conectado a una red por primera vez; | ||
| + | * la posibilidad de asignar otros prefijos, o de renumerar un dispositivo. | ||
| + | |||
| + | El proceso de configuración automática de direcciones IPv6 incluye la creación de una dirección local al enlace, la agregación a grupos multicast solicitados, la verificación de la unicidad de la dirección local al enlace y la creación de direcciones unicast global. | ||
| + | |||
| + | La tarea del enrutador es importante en la configuración automática. Indica a la máquina, mediante los bits de la cabecera (''cf'' [[#RA|anuncio de enrutador]]), del mensaje de anuncio de los enrutadores, el método a conservar y eventualmente proporcionar la información necesaria para su configuración. El bit <tt> M </tt> (''configuración de dirección administrada'') puesto a 1 indica que el equipo no debe crear por sí mismo una dirección a partir de su identificador de interfaz y de los prefijos recibidos, sino que debe solicitarla explícitamente ante un servidor de direcciones. El bit O <tt> </tt> (''otra configuración de estado'') indica que el dispositivo debe consultar el servidor para obtener otros parámetros distintos de la dirección. El algoritmo para el proceso de configuración automática de direcciones se desglosa de la siguiente manera: | ||
| + | |||
| + | * La primera fase consiste en crear la dirección local al enlace. | ||
| + | * Una vez que la unicidad de esta dirección es verificada, el dispositivo está listo para comunicarse con otras máquinas en el enlace. | ||
| + | * El dispositivo debe tratar de adquirir un mensaje de anuncio de enrutadores para determinar el método de obtención de la dirección unicast global. | ||
| + | * Si hay un enrutador en el enlace, el dispositivo debe aplicar el método especificado por el mensaje de anuncio de enrutadores, a saber: | ||
| + | ** La configuración automática sin estado, | ||
| + | ** la configuración automática con estado. | ||
| + | * Si no hay ningún enrutador en el enlace, el dispositivo debe tratar de obtener la dirección unicast global por el método de configuración automática con estado. Si el intento falla, no hay más que hacer. Las comunicaciones sólo podrán hacerse sobre el enlace con la dirección local al enlace, pues el dispositivo no tendrá una dirección con la cobertura necesaria que le permita comunicarse con otras máquinas fuera del enlace. | ||
| + | |||
| + | |||
| + | ==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. | ||
| + | |||
| + | <tikz title="Estados sucesivos de una dirección en una interfaz"> | ||
| + | |||
| + | \draw [thick, ->] (0,2) -- (9.5,2); | ||
| + | |||
| + | \draw [->] (1,4) node [above=10pt] {\tiny{allocation}}-- (1,2); | ||
| + | \draw (1, 2) node [rectangle, minimum width=1cm, minimum height=1cm, fill, left color=black!10, right color=black!20, draw=black, above right] (tentative) {}; | ||
| + | \draw (tentative.south east) node [rectangle, minimum width=3cm, minimum height=1cm, fill, left color=green, right color=green!50, draw=black, above right] (preferred) {}; | ||
| + | \draw (preferred.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, left color=orange , right color=orange!50!red, draw=black, above right] (deprecated) {}; | ||
| + | \draw (deprecated.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, color=red, draw=black, above right] (novalid) {}; | ||
| + | |||
| + | |||
| + | \draw (tentative.text) node {\tiny{Tentative}}; | ||
| + | \draw (preferred.text) node {\tiny{Preferred}}; | ||
| + | \draw (deprecated.text) node {\tiny{Deprecated}}; | ||
| + | \draw (novalid.text) node {\tiny{Invalid}}; | ||
| + | |||
| + | \draw [dotted] (tentative.south west) -- +(0, -1); | ||
| + | \draw [dotted] (preferred.south west) -- +(0, -1); | ||
| + | \draw [dotted] (deprecated.south west) -- +(0, -1); | ||
| + | \draw [dotted] (novalid.south west) -- +(0, -1); | ||
| + | |||
| + | \draw [dashed, <->] ([yshift=-0.5cm]tentative.south west) -- node [above] {\tiny{DAD}} ([yshift=-0.5cm] preferred.south west) ; | ||
| + | |||
| + | \draw [dashed, <->] ([yshift=-0.5cm]preferred.south west) -- node [above] {\tiny{Valid}} ([yshift=-0.5cm] novalid.south west) ; | ||
| + | |||
| + | |||
| + | </tikz> | ||
| + | |||
| + | La renumeración de una interfaz consiste en pasar de una dirección a otra. Durante una renumeración, no es aconsejable cambiar repentinamente de dirección, de lo contrario, todas las comunicaciones TCP que la utilizan como identificador de conexión, se cortarían inmediatamente. Esto conllevaría importantes perturbaciones a nivel de las aplicaciones. | ||
| + | |||
| + | Por ello, para facilitar esta transición se implementó un mecanismo de obsolescencia que invalida gradualmente una dirección. Este mecanismo se sirve de la capacidad de asignación de varias direcciones válidas a una misma interfaz. Para elegir la dirección a utilizar, se le asocia un estado que indica en qué fase de su tiempo de vida se encuentra con respecto a la interfaz. El primero de esos estados se conoce como preferido: no hay ninguna restricción de uso. Poco antes de su invalidación, la dirección pasa a un estado de depreciado. En él se desaconseja el uso de la dirección, pero no está prohibido. Una dirección depreciada ya no debe ser utilizada como dirección fuente de nuevas comunicaciones (como el establecimiento de conexión TCP), pero todavía puede emplearse como dirección fuente de comunicaciones ya establecidas. Los paquetes recibidos a una dirección depreciada seguirán siendo entregados normalmente. El control de la duración de cada estad de una dirección válida se efectúa agregando un tiempo de vida al estado preferido. | ||
| + | La figura '''Estados sucesivos de una dirección en una interfaz''' representa los diferentes estados que toma una dirección cuando se asigna a una interfaz. | ||
| + | |||
| + | == Creación de la dirección local al enlace == | ||
| + | |||
| + | <tikz title=" Creación de la dirección local al enlace"> | ||
| + | \clip (0, 0) rectangle (10,7); | ||
| + | % \draw[help lines] (0,0) grid (10,7 ); | ||
| + | |||
| + | \draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3); | ||
| + | |||
| + | \pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}} | ||
| + | \pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}} | ||
| + | |||
| + | \draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5); | ||
| + | \draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5); | ||
| + | |||
| + | |||
| + | \draw (1.5,4.5) node {\small{FE80::IID1}}; | ||
| + | \draw (1.5,4) node {\small{$\alpha$::IID1/64}}; | ||
| + | |||
| + | \draw (8, 4.5) node {\small{FE80::IID2}}; | ||
| + | |||
| + | </tikz> | ||
| + | |||
| + | Durante la inicialización de la interfaz, el dispositivo construye un identificador de interfaz que debe ser único en el enlace. Este identificador se utiliza la dirección de [[ Identificador_de_interfaz#EUI-64 | EUI-64]]. El principio básico para crear la direcciónIPv6 consiste en unir un prefijo con el identificador. La dirección local al enlace se crea tomando el prefijo de Enlace_local (<tt>FE80::/64</tt>). La dirección creada de esa manera, todavía no puede ser utilizada; tiene un estado temporal pues el dispositivo debe comprobar la exclusividad de esta dirección en el enlace mediante el procedimiento de detección de direcciones duplicadas. Si se encuentra que la dirección local al enlace no es única, se suspende la autoconfiguración y será necesario proceder a una configuración manual. | ||
| + | |||
| + | Una vez que se ha asegurado la unicidad de la dirección local al enlace, ésta se considera una dirección válida para la interfaz, con lo que termina la prima fase del proceso de autoconfiguración. | ||
| + | |||
| + | ==<div id="DAD"> Detección de una dirección duplicada </div>== | ||
| + | |||
| + | <tikz title="Emisión de un NS en una detección de Dir. duplicada (DAD)"> | ||
| + | \clip (0, 0) rectangle (10,7); | ||
| + | % \draw[help lines] (0,0) grid (10,7 ); | ||
| + | |||
| + | \draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3); | ||
| + | |||
| + | \pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}} | ||
| + | \pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}} | ||
| + | |||
| + | \draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5); | ||
| + | \draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5); | ||
| + | |||
| + | \draw (7.8, 5) -- (7.8, 3.2); | ||
| + | \draw [<->] (1, 3.2) -- node [above] {\tiny{::/0 -$>$ solicited (FE80:IID2) : NS (who has FE80::IID2?)}}(9, 3.2) ; | ||
| + | |||
| + | </tikz> | ||
| + | |||
| + | Para comprobar la exclusividad de direcciones locales al enlace o de direcciones unicast, los dispositivos deben ejecutar un algoritmo de detección de direcciones duplicadas (DAD) antes poder utilizarlas. El algoritmo usa los mensajes ICMPv6 [[Protocolo_de_Descubrimiento_de_vecinos#NS|solicitud de un vecino]] y [[#NA|anuncio de un vecino.]] Si se detecta una dirección que ya está en uso, ésta no podrá ser asignada a la interfaz, la autoconfiguración automática debe suspenderse y será necesario proceder a una configuración manual. Durante la ejecución del algoritmo DAD, la dirección es considerada como "provisional" hasta tener la confirmación de su unicidad. Una dirección provisional se asigna a una interfaz únicamente para recibir los mensajes de solicitud y anuncio de un vecino. Otros mensajes recibidos, son ignorados. El algoritmo DAD consiste en enviar un mensaje de solicitud de un vecino colocando en el campo de dirección objetivo la dirección provisional. Para distinguir el algoritmo DAD del de Descubrimiento de vecinos, el paquete IPv6 que contiene un mensaje de solicitud de un vecino tiene como dirección fuente una dirección no determinada. Así se presentan tres casos: | ||
| + | |||
| + | * Se recibe un mensaje de anucio de un vecino: Significa que la dirección provisional está siendo utilizada como válida por otro dispositivo, por lo que ésta no es única y no puede ser retenida por el dispositivo. | ||
| + | * Se recibe un mensaje de solicitud de un vecino como parte del algoritmo DAD. La dirección provisional también es provisional para otra máquina. En este caso, la dirección provisional no puede ser utilizada por ninguna de ellas. | ||
| + | * No se recibe ningún mensaje durante un segundo (valor por omisión). La dirección provisional es única, por lo que su estado pasa de provisional a válida y se le asigna a la interfaz. | ||
| + | |||
| + | Obsérvese que este algoritmo no proporciona una fiabilidad absoluta, especialmente cuando el enlace está segmentado. | ||
| + | |||
| + | == Autoconfiguración sin estado == | ||
| + | |||
| + | <tikz title="Emisión de un RS"> | ||
| + | \clip (0, 0) rectangle (10,7); | ||
| + | % \draw[help lines] (0,0) grid (10,7 ); | ||
| + | |||
| + | \draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3); | ||
| + | |||
| + | \pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}} | ||
| + | \pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}} | ||
| + | |||
| + | \draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5); | ||
| + | \draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5); | ||
| + | |||
| + | \draw (7.8, 5) -- (7.8, 3.2); | ||
| + | \draw [<->] (1, 3.2) -- node [above] {\tiny{FE80::IID2 -$>$ FF02::2 : RS }} (9, 3.2) ; | ||
| + | |||
| + | </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. | ||
| + | |||
| + | <tikz title="Recepción de un RA"> | ||
| + | \clip (0, 0) rectangle (10,7); | ||
| + | % \draw[help lines] (0,0) grid (10,7 ); | ||
| + | |||
| + | \draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3); | ||
| + | |||
| + | \pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}} | ||
| + | \pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}} | ||
| + | |||
| + | \draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5); | ||
| + | \draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5); | ||
| + | |||
| + | \draw [->] (1.7,5) -- (1.7, 3.2) -- node [above = 10pt] {\tiny{FE80::IID1 -$>$ FE80::IID2}} node [above] {\tiny{RA ($\alpha$::/64, DHCPv6, MTU=1500, HL=64, {bit {\tt M=1}) }}} (7.8, 3.2) -- (7.8, 5); | ||
| + | |||
| + | </tikz> | ||
| + | |||
| + | Al igual que para la creación de la dirección de enlace local, la dirección unicast global se obtiene al concatenar el prefijo con el identificador de la interfaz. El prefijo se obtiene del mensaje de anuncio de enrutador, más concretamente, de la opción de ''información sobre el prefijo''. Si bien debe verificarse la unicidad de todas las direcciones unicast, en el caso de una dirección unicast obtenida mediante la configuración automática sin estado, esto no es obligatorio, pues la unicidad del identificador de la interfaz ya fue comprobada durante la configuración de la dirección local al enlace. Dado que el identificador es el mismo, no puede haber ambigüedad sobre la exclusividad de la dirección unicast global creada de esta forma. | ||
| + | |||
| + | La renumeración de los dispositivos en un enlace se realiza mediante enrutadores que transfieren las direcciones utilizadas a un estado depreciado y al mismo tiempo anuncian el nuevo prefijo con el que los dispositivos pueden re-crear una dirección preferida. | ||
| + | |||
| + | |||
| + | ===Caso de redes NBMA === | ||
| + | |||
| + | <tikz title="Off Link NDP: Primera etapa"> | ||
| + | \clip (0, 0) rectangle (11,7); | ||
| + | % \draw[help lines] (0,0) grid (10,7 ); | ||
| + | |||
| + | \pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}} | ||
| + | \pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}} | ||
| + | \pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}} | ||
| + | |||
| + | |||
| + | \draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [above, color=black] {\tiny{FE80::IID2 -$>$ FF02::2 : RS}} (5,5); | ||
| + | |||
| + | </tikz> | ||
| + | |||
| + | Las redes NBMA (''Non Broadcast Multiple Access'') se caracterizan por no contar con un mecanismo de difusión hacia todos los dispositivos. Esto conduce a dos situiaciones posibles: | ||
| + | * ausencia total de difusión, como en las redes públicas (telefónica, ATM, …) en las que un solo destinatario puede ser contactado a la vez | ||
| + | * posibilidad de difusión por un número limitado de equipos, como es el caso de las redes de radio tipo 3G, WiMAX, en las que la estación base tiene la posibilidad de difundir datos hacia todos los equipos, pero esto no es posible en el sentido inverso (desde un dispositivo). | ||
| + | |||
| + | <tikz title="Off Link NDP: Segunda etapa"> | ||
| + | \clip (0, 0) rectangle (11,7); | ||
| + | % \draw[help lines] (0,0) grid (10,7 ); | ||
| + | |||
| + | \pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}} | ||
| + | \pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}} | ||
| + | \pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}} | ||
| + | |||
| + | \draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5, 5)-- node [above, color=black] {\tiny{RA ($\alpha$::/64, DHCPv6, OffLink, MTU=1500, HL=64, {bit {\tt M=1}})}} (8,3); | ||
| + | |||
| + | </tikz> | ||
| + | |||
| + | Un comportamiento de redes NBMA también puede ser deseable para limitar las restricciones de consumo energético. Por ejemplo, en el caso de redes de sensores, la difusión, o la difusión restringida (multicast) son costosas en consumo de energía pues todos los dispositivos deben procesar el mensaje y algunos deberán retransmitirlo. | ||
| + | |||
| + | <tikz title="Off Link NDP: Tercera etapa"> | ||
| + | \clip (0, 0) rectangle (11,7); | ||
| + | % \draw[help lines] (0,0) grid (10,7 ); | ||
| + | |||
| + | \pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}} | ||
| + | \pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}} | ||
| + | \pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}} | ||
| + | |||
| + | |||
| + | \draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near start, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5); | ||
| + | |||
| + | \draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3); | ||
| + | |||
| + | </tikz> | ||
| + | |||
| + | 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 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. | ||
| + | * El dispositivo envía sistemáticamente todos los paquetes a la dirección física del enrutador. Éste, que tiene una visión global de la red, los reenvía hacia el destinatario apropiado. | ||
| + | |||
| + | <tikz title="Off Link NDP: Cuarta etapa (opcional)"> | ||
| + | \clip (0, 0) rectangle (11,7); | ||
| + | % \draw[help lines] (0,0) grid (10,7 ); | ||
| + | |||
| + | \pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}} | ||
| + | \pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}} | ||
| + | \pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}} | ||
| + | |||
| + | |||
| + | \draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near end, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5); | ||
| + | |||
| + | \draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3); | ||
| + | |||
| + | \draw[decorate,decoration={triangles}, color=black!60, ->, thick, ] (5,5) to [bend left] node [right, near start, color=black] {\tiny{REDIRECT $\alpha$::IID3 : MAC3}} (8,3); | ||
| + | |||
| + | \draw [color=black!60, ->, very thick, dotted] (8,3)-- node [above, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3); | ||
| + | |||
| + | |||
| + | </tikz> | ||
| + | |||
| + | * 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 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. | ||
| + | |||
| + | 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"> | ||
| + | \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 [[eIPv6_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}} | ||
Latest revision as of 02:19, 7 July 2012
| |
Incio del capítulo | Tabla de contenido | DHCPv6 | |
Contents
El protocolo de descubrimiento de vecinos (NDP, Neighbor Discovery Protocol) permite a un dispositivo integrarse en el ambiente local, es decir, el enlace sobre el cual se transmiten físicamente los paquetes IPv6. Permite establecer un diálogo con los equipos (estaciones y enrutadores) conectados sobre el mismo medio. No se pretende que un dispositivo conozca con exactitud la lista de todos los demás dispositivos conectados al enlace, sino de proveer un mecanismo para dialogar con quien necesite hacerlo.
El protocolo utiliza cinco tipos de mensajes ICMPv6 (ver Valores de los campos de tipo y código de ICMPv6). El campo número de saltos de la cabecera IPv6 contiene el valor 255. Este valor parece demasiado grande para datagramas que no debieran ser enrutados fuera del enlace físico. En realidad, si un equipo recibe un datagrama con un valor menor, significa que la información proviene de otra red y que ya ha atravesado al menos un enrutador. Por ello, los datagramas que tienen un valor diferente de 255 deben ser ignorados por el receptor.
| Tipo | Código | Significado |
|---|---|---|
| Gestión de los errores | ||
| 1 | Destino inaccesible : | |
| 0 | * ninguna ruta hacia el destino | |
| 1 | * la comunicación con el destino está prohibida administrativamente | |
| 2 | * fuera del alcance de la dirección fuente | |
| 3 | * la dirección es inaccessible | |
| 4 | * el número de puerto es inaccessible | |
| 5 | * la dirección fuente está filtrada por un firewall | |
| 6 | * la dirección destino es rechazada | |
| 2 | ||
| 3 | Temporizador agotado : | |
| 0 | * se alcanzó el límite en el número de saltos | |
| 1 | * temporizador para reensamblado agotado | |
| 4 | Error de parámetro : | |
| 0 | * campo de cabecera erróneo | |
| 1 | * campo de cabecera siguiente no reconocido | |
| 2 | * opción no reconocida | |
| Información | ||
| 128 | Solicitud de eco | |
| 129 | Respuesta de eco | |
| Gestión de grupos multicast (MLD, RFC 2710) | ||
| 130 | Soicitud de registro | |
| 131 | Reporte de registro | |
| 132 | Fin de registro | |
| Descubrimiento de vecinos (RFC 2461) | ||
| 133 | Solicitud de enrutador | |
| 134 | Anuncio de enrutador | |
| 135 | Solicitud de un vecino | |
| 136 | Anuncio de un vecino | |
| 137 | Redirección | |
| Renumeración de los enrutadores (experimental, RFC 2894) | ||
| 138 | Renumeración de los enrutadores :
| |
| 0 | * Comando | |
| 1 | * Resultado | |
| 255 | * Reinicio del número de secuencia | |
| Solicitud de información sobre un nodo (experimental) | ||
| 139 | Solicitud de información | |
| 140 | Respuesta | |
| Descubrimiento de vecinos inverso (RFC 3122) | ||
| 141 | Solicitud | |
| 142 | Anuncio | |
| Gestión de grupos multicast (MLDv2, RFC 3810) | ||
| 143 | Reporte registro MLDv2 | |
| Movilidad (RFC 3775) | ||
| 144 | Descubrimiento del agente base (solicitud) | |
| 145 | Descubrimiento del agente base (respuesta) | |
| 146 | Solicitud del prefijo móvil | |
| 147 | Anuncio del prefijo móvil | |
| Descubrimiento de vecinos asegurado (SEND, RFC 3971) | ||
| 148 | Solicitudo de trayectoria de certificación | |
| 149 | Anuncio de trayectoria de certificación | |
| Movilidad (experimental) | ||
| 150 | Protocolos experimentales de movilidad, como Seamoby | |
El protocolo realiza varias funciones:
- Resolución de direcciones. El principio es muy similar al del protocolo ARP de IPv4. La principal diferencia consiste en el uso de mensajes ICMPv6 estándar en lugar de definir otro protocolo de capa 3. Con esto se consigue una mayor flexibilidad de uso, especialmente en las redes que no soportan la difusión de mensajes. Al igual que en IPv4, el protocolo se encarga de construir tablas de correspondencia entre las direcciones IPv6 y las físicas.
- Detección de inaccesibilidad de vecinos (NUD, Neighbor Unreachability Detection). Esta función, que no existe en IPv4, permite eliminar de las tablas de configuración de un equipo, los vecinos que se han vuelto inaccesibles (por fallas, cambio de domicilio, ...). Si un enrutador deja de estar disponible, la tabla de enrutamiento puede ser modificada para considerar otra ruta.
- Configuración. La configuración automática de los dispositivos es uno de los principales atractivos de IPv6. Se implementan varias funcionalidades del protocolo de descubrimiento de vecinos:
- Descubrimiento de enrutadores. Este protocolo permite que los dispositivos identifiquen a los enrutadores que se encuentran en su enlace físico. En IPv4, esta función la proporciona el protocolo ICMP Router Discovery.
- Descubrimiento de prefijos. El dispositivo conoce el o los prefijos de red de acuerdo a los anuncios realizados por los enrutadores. Agregando su identificador de interfaz, el dispositivo construye su o sus direcciones IPv6. No hay un mecanismo equivalente para las direcciones IPv4 ya que son demasiado cortas para realizar la auto-configuración.
- Detección de direcciones duplicadas. Dado que las direcciones se configuran de forma automática, existen riesgos de error en caso de tener equipos con identificadores repetidos. Este protocolo verifica que ningún otro equipo en el enlace tiene la misma dirección IPv6. Esta función es una evolución del ARP gratuito en IPv4 emitido durante la inicialización de la interfaz.
- Descubrimiento de parámetros. Este protocolo permite que los dispositivos conozcan los distintos parámetros del enlace físico, por ejemplo, el tamaño de MTU, el número máximo de saltos permitido (valor original del campo número de saltos), si la configuración automática con estado (como DHCPv6) está activa, etc. No existe un equivalente de esta funcionalidad en IPv4.
- 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 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.
En IPv6 se especifican dos métodos de autoconfiguración para las direcciones unicast global:
- Autoconfiguración sin estado (stateless autoconfiguration, RFC 2462). Se utiliza cuando no es necesaria una gestión administrativa de las direcciones asignadas dentro de un sitio. Estos mecanismos se describen más adelante en este capítulo.
- Autoconfiguración con estado (statefull autoconfiguration). Se utiliza cuando un sitio requiere de un control estricto de la asignación de direcciones (cf DHCPv6).
Sin embargo, el uso de DHCPv6 para obtener la dirección se controla mediante el protocolo de descubrimiento de vecinos.
Datos transmitidos por los mensajes
La principal motivación detrás del Protocolo de Descubrimiento de vecinos es unificar varios protocolos existentes en IPv4. En particular, la mayor parte de los datos utiliza un formato de opciones común, lo que simplifica la implementación del protocolo. El formato contiene los campos: tipo, longitud (en palabras de 64 bits), y datos. La baja precisión de campo longitud, presentará un desperdicio de espacio, pero permite una alineación de las opciones en palabras de 64 bits, lo que permite un procesamiento optimizado.
| Tipo | Descripción | Mensaje |
|---|---|---|
| Opciones básicas de descubrimiento de vecinos [RFC 4861] | ||
| 1 | Source Link-layer Address (SLLAO) | RS/RA/NS |
| 2 | Target Link-layer Address | NA/Redirect |
| 3 | Prefix Information (PIO) | RA |
| 4 | Redirected Header | Redirect |
| 5 | MTU | RA |
| NBMA (no usado) [RFC 2491] | ||
| 6 | NBMA Shortcut Limit Option | NS |
| Mobile IP [RFC 3775] | ||
| 7 | Advertisement Interval Option | RA |
| 8 | Home Agent Information Option | RA |
| X | Authoritative Border Router (ABRO) | 6LoWPAN |
| X | 6LoWPAN Context (6CO) | 6LoWPAN |
| X | Address Registration (ARO) | 6LoWPAN |
| Inverse Neighbor Discovery [RFC 3122] | ||
| 9 | Source Address List | |
| 10 | Target Address List | |
| SEND [RFC 3971] | ||
| 11 | CGA option | |
| 12 | RSA Signature option | |
| 13 | Timestamp option | |
| 14 | Nonce option | |
| 15 | Trust Anchor option | |
| 16 | Certificate option | |
| Mobility options | ||
| 17 | IP Address/Prefix Option [RFC 5568] | |
| 18 | New Router Prefix Information Option [RFC 4068] | |
| 19 | Link-layer Address Option [RFC 5568] | |
| 20 | Neighbor Advertisement Acknowledgment Option [RFC 5568] | |
| 23 | MAP Option [RFC 4140] | |
| SLAAC optimization | ||
| 24 | Route Information Option [RFC 4191] | |
| 25 | Recursive DNS Server Option [RFC 5006] | RA |
| 26 | RA Flags Extension Option [RFC 5175] | |
| Fast Mobility options | ||
| 27 | Handover Key Request Option | [RFC 5269] |
| 28 | Handover Key Reply Option | [RFC 5269] |
| 29 | Handover Assist Information Option | [RFC 5271] |
| 30 | Mobile Node Identifier Option | [RFC 5271] |
| 138 | CARD Request option | [RFC 4065] |
| 139 | CARD Reply option | [RFC 4065] |
Dirección física de la fuente/destino
Figure : Formato de la opción dirección física fuente/destino
La figura Formato de la opción dirección física fuente/destino presenta estas opciones. El tipo 1 designa la dirección física de la fuente y el tipo 2 la dirección del destino.
El campo length es el tamaño en palabras de 64 bits de la opción. Por lo tanto, para el caso de una dirección MAC con longitud de 6 octetos, contiene el valor 1.
El RFC 2464 define el formato para las direcciones MAC-48 utilizadas en las redes Ethernet y Wi-Fi. El RFC 4944 define el formato para las direcciones MAC-16 y MAC-64 utilizadas en las redes de sensores bajo la norma IEEE 802.15.4.
Información sobre el prefijo
Figure : Formato de la opción información sobre el prefijo
Esta opción contiene las informaciones sobre el prefijo para permitir una configuración automática de los dispositivos. El campo tipo tiene el valor 3 y el de longitud, 4. La figura Formato de la opción información sobre el prefijo muestra el formato de esta opción:
- El campo Prefix lenght indica cuántos bits son significativos para el prefijo anunciado en un campo siguiente.
- El bit L indica, cuando vale 1, que el prefijo permite indicar que todos los demás dispositivos que comparten el mismo prefijo, están en el mismo enlace, por lo que el emisor puede contactarlos directamente. En caso contrario, el dispositivo envía el paquete hacia el enrutador. Si éste último sabe que el emisor puede contactar directamente al destinatario, emitirá un mensaje ICMPv6 de indicación de redirección.
- El bit A indica, cuando vale 1, que el prefijo anunciado puede utilizarse para formar la dirección del dispositivo.
- El bit R, indica, cuando vale 1, que el campo prefijo contiene la dirección global de un enrutador agente base. Los bits de mayor peso aún pueden utilizarse para formar un prefijo.
- El campo duración de validez indica, en segundos, la duración durante la cual el prefijo es válido.
- El campo duración preferente indica la duración, en segundos, durante la cual una dirección formada con el protocolo de configuración sin estado se mantiene preferente (cf Tiempo de vida de las direcciones).
Para estos dos campos, un valor de 0xffffffff representa una duración infinita. Estos campos pueden servir durante la fase de transición de un proveedor de acceso a otro; es decir, de un prefijo a otro.
- El campo reservado permite alinear el prefijo a una frontera de palabra de 64 bits.
- El campo prefijo contiene el valor de prefijo anunciado sobre el enlace. Para mantener una alineación de 64 bits para el resto de datos del paquete, este campo tiene una longitud fija de 128 bits.
Cabecera de redirección
Figure : Formato de la opción cabecera de redirección
Esta opción es utilizada por el mensaje de indicación de redirección. Permite encapsular los primeros octetos del paquete IPv6 que provocó la emisión de este mensaje, como ocurre con los mensajes de error de ICMPv6.
El campo tipo tiene el valor 4. El tamaño de esta opción debe evitar que el paquete IPv6 rebase los 1280 octetos (cf figura Formato de la opción cabecera de redirección). Sin embargo, el paquete debe contener la mayor cantidad de información posible.
MTU
Figure : Formato de la opción MTU
Esta opción permite notificar a los dispositivos el tamaño máximo de datos que pueden ser transmitidos sobre el enlace. La figura Formato de la opción MTU muestra su estructura. No es necesario difundir esta información si el dispositivo utiliza siempre el tamaño máximo permitido. Por ejemplo, sobre las redes Ethernet, los dispositivos utilizarán el valor 1,500. En cambio, en las redes Token Ring o FDDI, con frecuencia es necesario especificar si los equipos pueden utilizar la longitud máxima o un tamaño inferior para permitir el uso de puentes en la red.
En esta opción, el campo tipo tiene un valor de 5 y el de longitud, de 1.
Mensajes estándar de Descubrimiento de vecinos
Además de las cinco opciones básicas descritas en la tabla Utilización de las opciones en los mensajes de descubrimiento de vecinos, existen otras específicas para la movilidad y para las redes NBMA (Non Broadcast Multiple Access).
| Solicitud de | Anuncio de | Solicitud de | Anuncio de | Indicación de | |
| enrutador | enrutador | un vecino | un vecino | redirección | |
| Dirección física de la fuente | presente | presente | presente | ||
| Dirección física del destino | presente | presente | |||
| Información sobre el prefijo | ≥ 1 | ||||
| Cabecera de redirección | presente | ||||
| MTU | posible |
Las distintas funcionalidades de descubrimiento de vecinos utilizan cinco mensajes: dos para el diálogo entre un dispositivo y un enrutador, dos para el diálogo entre vecinos, y uno para la redirección. Cada uno de estos mensajes puede incluir opciones adicionales.
Solicitud de enrutador
Figure : Formato de los paquetes de solicitud de enrutador
El mensaje de solicitud de enrutador (cf figura Formato de los paquetes de solicitud de enrutador) es emitido al iniciar un dispositivo para recibir más rápidamente la información del enrutador. Este mensaje se envía a la dirección IPv6 multicast reservada a los enrutadores en el mismo enlace FF02::2. Si el dispositivo aún no conoce su dirección fuente, se utiliza la dirección no especificada.
El campo opción normalmente contiene la dirección física del dispositivo.
Anuncio de enrutador
Figure : Formato de los paquetes de anuncio de enrutador
Este mensaje (cf figura Formato de los paquetes de anuncio de enrutador) es emitido periódicamente por los enrutadores, o bien, en respuesta a un mensaje de solicitud de enrutador generado por un dispositivo. El campo dirección fuente contiene la dirección de enlace local del enrutador, mientras que el campo dirección destino contiene la dirección del dispositivo que generó la solicitud, o la dirección de todas las estaciones (ff02::01).
Cuando el campo de máximo número de saltos tiene un valor distinto de cero, muestra el valor que podría colocarse en el campo de número de saltos de los paquetes emitidos. El bit M indica que una dirección del dispositivo debe ser obtenida mediante un protocolo de configuración (cf Configuración con estado:DHCPv6). El bit O también indica la presencia de un servicio de configuración para obtener información adicional a la dirección. Si no es posible obtener la dirección mediante un servidor, el dispositivo procede a realizar una configuración sin estado, concatenando su identificador de interfaz a los prefijos que conoce. El bit H indica que el enrutador puede ser utilizado como agente base por un nodo móvil (cf Anuncio del agente base).
El campo tiempo de vida del enrutador indica el período (en segundos) durante el cual el equipo que emite el anuncio realizará funciones de enrutador por omisión. El valor máximo corresponde a 18 horas 12 minutos, pero como este mensaje se emite periódicamente, en la práctica no existe un límite para el tiempo de vida de un enrutador. Un valor de 0 indica que el dispositivo no cumple con las funciones de enrutador por omisión. Este tiempo de vida no se aplica a las opciones transportadas por este mensaje.
El campo duración de accesibilidad indica el período (en milisegundos) durante el cual una información almacenada en la memoria caché de la máquina (por ejemplo, la tabla de correspondencia entre las direcciones IPv6 y las físicas) puede ser considerada como válida. Al vencimiento de este tiempo, se emite un mensaje de detección de inaccesibilidad para verificar la pertinencia de la información almacenada.
El campo temporización de retransmisión muestra el período (en milisegundos) entre dos emisiones no solicitadas de este mensaje. Permite que los demás equipos puedan detectar la inaccesibilidad de un enrutador.
Este mensaje puede transportar las siguientes opciones:
- dirección física de la fuente,
- MTU,
- información sobre el prefijo (uno o varios).
Solicitud de un vecino
Figure : Formato de los paquetes de solicitud de un vecino
Este mensaje (cf figura Formato de los paquetes de solicitud de un vecino) permite obtener información a partir de un equipo vecino, es decir, localizado en el mismo enlace físico (o conectado a través de puentes). El mensaje puede ser emitido explícitamente a él, o enviado con una dirección de difusión. En el caso de determinación de la dirección física, éste corresponde a la solicitud de ARP en IPv4.
El campo dirección fuente del paquete IPv6 contiene ya sea la dirección local al enlace, una dirección global o la dirección no especificada. El campo destino puede contener la dirección de difusión múltiple solicitada correspondiente a la dirección buscada (cf Identificador de grupo) o la dirección del dispositivo (en el caso de una detección de inaccesibilidad de vecinos, NUD).
El campo dirección del destino contiene la dirección IPv6 del equipo buscado. El campo opción generalmente contiene la dirección física de la fuente.
Anuncio de un vecino
Figure : Formato de los paquetes de anuncio de un vecino
Este mensaje (cf figura Formato de los paquetes de anuncio de un vecino) se emite en respuesta a una solicitud, aunque también puede ser emitido de forma espontánea para propagar la información de cambio de dirección física, o del estado de "enrutador". Para el caso de la determinación de la dirección física, es equivalente a la respuesta ARP en IPv4.
- El bit R se pone a 1 si el remitente es un enrutador. Este bit se utiliza para permitir la detección de un enrutador que se convierte en un equipo ordinario.
- El bit S en 1 indica que este anuncio se emite en respuesta a una solicitud.
- El bit O en 1 indica que este anuncio debe borrar las informaciones anteriores que se encuentran almacenadas en la memoria cachés de otros equipos, en especial la tabla que contiene las direcciones físicas.
- El campo dirección del destino contiene, si el bit S es 1, el valor del campo dirección del destino de la solicitud a la que está respondiendo este mensaje. Si el bit S es 0, este campo contiene la dirección IPv6 local al enlace del equipo emisor.
- La opción dirección física del destino contiene la dirección física del emisor.
Indicación de redirección
Figure : Formato de los paquetes de indicación de redirección
La técnica de redirección es la misma que en IPv4. Un dispositivo sólo conoce los prefijos de las redes a las que está conectado directamente y la dirección de un enrutador por omisión. Si la ruta se puede optimizar, el enrutador por omisión envía un mensaje para indicar que existe un camino más corto. De hecho, como en IPv6 el enrutador por omisión se establece de forma automática, las rutas no necesariamente son las mejores (cf figura Enrutamiento por omisión no óptimo).
Otro caso particular en IPv6 ocurre con los dispositivos que se encuentran en el mismo enlace físico, pero tienen diferentes prefijos. La comunicación entre ellos pasa inicialmente a traves de enrutador por omisión hasta que éste notifica que existe una ruta directa entre ellos.
La figura Formato de los paquetes de indicación de redirección muestra el formato del mensaje:
- El campo dirección objetivo (Target address) contiene la dirección IPv6 del equipo hacia el que los paquetes deben ser enviados.
- El campo dirección destino contiene la dirección IPv6 del dispositivo que está siendo redirigido hacia la dirección objetivo.
Cuando la redirección apunta a un dispositivo situado en el mismo enlace, la dirección objetivo y de destino son las mismas.
Las opciones incluyen la dirección física de un nuevo enrutador y la cabecera del paquete redirigido.
Este mensaje se puede utilizar de la misma forma que en IPv4. Un dispositivo solamente tiene una ruta por omisión para acceder a equipos con un prefijo diferente. En consecuencia, envía su paquete al enrutador por omisión, quien observa que el prefijo destino es accesible a través de la misma subred que el emisor. El enrutador por omisión reenvía el paquete y notifica al emisor que puede contactar directamente a las máquinas que poseen el prefijo del destino.
IPv6 también utiliza este mensaje para optimizar la resolución fuera del enlace para el caso de redes NBMA.
Configuración automática
Tradicionalmente, la configuración de una interfaz de red de una máquina se hacía manualmente. Esto suele ser un trabajo lento y propenso a errores. Con IPv6, se automatiza el proceso de configuración y se introducen, al mismo tiempo, mecanismos de funcionamiento inmediato (plug and play) a la interfaz de red. La configuración automática significa que un dispositivo obtendrá toda la información necesaria para su conexión a una red local IP sin ninguna intervención humana. En el caso ideal, cualquier usuario desempaca su nuevo equipo, lo conecta a la red local y lo ve funcionar sin tener que introducir la información propia de "especialistas". Ahora vamos a discutir otro aspecto de la configuración automática de IPv6, la auto-configuración de direcciones, que tiene como objetivos:
- La adquisición de una dirección cuando un dispositivo está conectado a una red por primera vez;
- la posibilidad de asignar otros prefijos, o de renumerar un dispositivo.
El proceso de configuración automática de direcciones IPv6 incluye la creación de una dirección local al enlace, la agregación a grupos multicast solicitados, la verificación de la unicidad de la dirección local al enlace y la creación de direcciones unicast global.
La tarea del enrutador es importante en la configuración automática. Indica a la máquina, mediante los bits de la cabecera (cf anuncio de enrutador), del mensaje de anuncio de los enrutadores, el método a conservar y eventualmente proporcionar la información necesaria para su configuración. El bit M (configuración de dirección administrada) puesto a 1 indica que el equipo no debe crear por sí mismo una dirección a partir de su identificador de interfaz y de los prefijos recibidos, sino que debe solicitarla explícitamente ante un servidor de direcciones. El bit O (otra configuración de estado) indica que el dispositivo debe consultar el servidor para obtener otros parámetros distintos de la dirección. El algoritmo para el proceso de configuración automática de direcciones se desglosa de la siguiente manera:
- La primera fase consiste en crear la dirección local al enlace.
- Una vez que la unicidad de esta dirección es verificada, el dispositivo está listo para comunicarse con otras máquinas en el enlace.
- El dispositivo debe tratar de adquirir un mensaje de anuncio de enrutadores para determinar el método de obtención de la dirección unicast global.
- Si hay un enrutador en el enlace, el dispositivo debe aplicar el método especificado por el mensaje de anuncio de enrutadores, a saber:
- La configuración automática sin estado,
- la configuración automática con estado.
- Si no hay ningún enrutador en el enlace, el dispositivo debe tratar de obtener la dirección unicast global por el método de configuración automática con estado. Si el intento falla, no hay más que hacer. Las comunicaciones sólo podrán hacerse sobre el enlace con la dirección local al enlace, pues el dispositivo no tendrá una dirección con la cobertura necesaria que le permita comunicarse con otras máquinas fuera del enlace.
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.
Figure : Estados sucesivos de una dirección en una interfaz
La renumeración de una interfaz consiste en pasar de una dirección a otra. Durante una renumeración, no es aconsejable cambiar repentinamente de dirección, de lo contrario, todas las comunicaciones TCP que la utilizan como identificador de conexión, se cortarían inmediatamente. Esto conllevaría importantes perturbaciones a nivel de las aplicaciones.
Por ello, para facilitar esta transición se implementó un mecanismo de obsolescencia que invalida gradualmente una dirección. Este mecanismo se sirve de la capacidad de asignación de varias direcciones válidas a una misma interfaz. Para elegir la dirección a utilizar, se le asocia un estado que indica en qué fase de su tiempo de vida se encuentra con respecto a la interfaz. El primero de esos estados se conoce como preferido: no hay ninguna restricción de uso. Poco antes de su invalidación, la dirección pasa a un estado de depreciado. En él se desaconseja el uso de la dirección, pero no está prohibido. Una dirección depreciada ya no debe ser utilizada como dirección fuente de nuevas comunicaciones (como el establecimiento de conexión TCP), pero todavía puede emplearse como dirección fuente de comunicaciones ya establecidas. Los paquetes recibidos a una dirección depreciada seguirán siendo entregados normalmente. El control de la duración de cada estad de una dirección válida se efectúa agregando un tiempo de vida al estado preferido. La figura Estados sucesivos de una dirección en una interfaz representa los diferentes estados que toma una dirección cuando se asigna a una interfaz.
Creación de la dirección local al enlace
Figure : Creación de la dirección local al enlace
Durante la inicialización de la interfaz, el dispositivo construye un identificador de interfaz que debe ser único en el enlace. Este identificador se utiliza la dirección de EUI-64. El principio básico para crear la direcciónIPv6 consiste en unir un prefijo con el identificador. La dirección local al enlace se crea tomando el prefijo de Enlace_local (FE80::/64). La dirección creada de esa manera, todavía no puede ser utilizada; tiene un estado temporal pues el dispositivo debe comprobar la exclusividad de esta dirección en el enlace mediante el procedimiento de detección de direcciones duplicadas. Si se encuentra que la dirección local al enlace no es única, se suspende la autoconfiguración y será necesario proceder a una configuración manual.
Una vez que se ha asegurado la unicidad de la dirección local al enlace, ésta se considera una dirección válida para la interfaz, con lo que termina la prima fase del proceso de autoconfiguración.
Detección de una dirección duplicada
Figure : Emisión de un NS en una detección de Dir. duplicada (DAD)
Para comprobar la exclusividad de direcciones locales al enlace o de direcciones unicast, los dispositivos deben ejecutar un algoritmo de detección de direcciones duplicadas (DAD) antes poder utilizarlas. El algoritmo usa los mensajes ICMPv6 solicitud de un vecino y anuncio de un vecino. Si se detecta una dirección que ya está en uso, ésta no podrá ser asignada a la interfaz, la autoconfiguración automática debe suspenderse y será necesario proceder a una configuración manual. Durante la ejecución del algoritmo DAD, la dirección es considerada como "provisional" hasta tener la confirmación de su unicidad. Una dirección provisional se asigna a una interfaz únicamente para recibir los mensajes de solicitud y anuncio de un vecino. Otros mensajes recibidos, son ignorados. El algoritmo DAD consiste en enviar un mensaje de solicitud de un vecino colocando en el campo de dirección objetivo la dirección provisional. Para distinguir el algoritmo DAD del de Descubrimiento de vecinos, el paquete IPv6 que contiene un mensaje de solicitud de un vecino tiene como dirección fuente una dirección no determinada. Así se presentan tres casos:
- Se recibe un mensaje de anucio de un vecino: Significa que la dirección provisional está siendo utilizada como válida por otro dispositivo, por lo que ésta no es única y no puede ser retenida por el dispositivo.
- Se recibe un mensaje de solicitud de un vecino como parte del algoritmo DAD. La dirección provisional también es provisional para otra máquina. En este caso, la dirección provisional no puede ser utilizada por ninguna de ellas.
- No se recibe ningún mensaje durante un segundo (valor por omisión). La dirección provisional es única, por lo que su estado pasa de provisional a válida y se le asigna a la interfaz.
Obsérvese que este algoritmo no proporciona una fiabilidad absoluta, especialmente cuando el enlace está segmentado.
Autoconfiguración sin estado
Figure : Emisión de un RS
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.
Figure : Recepción de un RA
Al igual que para la creación de la dirección de enlace local, la dirección unicast global se obtiene al concatenar el prefijo con el identificador de la interfaz. El prefijo se obtiene del mensaje de anuncio de enrutador, más concretamente, de la opción de información sobre el prefijo. Si bien debe verificarse la unicidad de todas las direcciones unicast, en el caso de una dirección unicast obtenida mediante la configuración automática sin estado, esto no es obligatorio, pues la unicidad del identificador de la interfaz ya fue comprobada durante la configuración de la dirección local al enlace. Dado que el identificador es el mismo, no puede haber ambigüedad sobre la exclusividad de la dirección unicast global creada de esta forma.
La renumeración de los dispositivos en un enlace se realiza mediante enrutadores que transfieren las direcciones utilizadas a un estado depreciado y al mismo tiempo anuncian el nuevo prefijo con el que los dispositivos pueden re-crear una dirección preferida.
Caso de redes NBMA
Figure : Off Link NDP: Primera etapa
Las redes NBMA (Non Broadcast Multiple Access) se caracterizan por no contar con un mecanismo de difusión hacia todos los dispositivos. Esto conduce a dos situiaciones posibles:
- ausencia total de difusión, como en las redes públicas (telefónica, ATM, …) en las que un solo destinatario puede ser contactado a la vez
- posibilidad de difusión por un número limitado de equipos, como es el caso de las redes de radio tipo 3G, WiMAX, en las que la estación base tiene la posibilidad de difundir datos hacia todos los equipos, pero esto no es posible en el sentido inverso (desde un dispositivo).
Figure : Off Link NDP: Segunda etapa
Un comportamiento de redes NBMA también puede ser deseable para limitar las restricciones de consumo energético. Por ejemplo, en el caso de redes de sensores, la difusión, o la difusión restringida (multicast) son costosas en consumo de energía pues todos los dispositivos deben procesar el mensaje y algunos deberán retransmitirlo.
Figure : Off Link NDP: Tercera etapa
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 enrutador responde poniendo el bit L (OffLink) a 1 en la opció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.
- El dispositivo envía sistemáticamente todos los paquetes a la dirección física del enrutador. Éste, que tiene una visión global de la red, los reenvía hacia el destinatario apropiado.
Figure : Off Link NDP: Cuarta etapa (opcional)
- 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 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 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 O (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
Figure : Descubrimiento de MTU primera fase: envío de un paquete demasiado grande
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.
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).
Figure : Descubrimiento de MTU segunda fase: recepción de un mensaje ICMPv6
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 fragmentación).
Figure : Descubrimiento de MTU tercera fase: Emisión de un paquete de tamaño adecuado
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 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.
| |
Incio del capítulo | Tabla de contenido | DHCPv6 | |
