Protocolo de Descubrimiento de Vecinos - Revision history

Jincera at 21:55, 19 June 2012

2012-06-19T21:55:43Z

Jincera at 21:45, 19 June 2012

2012-06-19T21:45:52Z

Jincera: /* Información sobre el prefijo */

2012-06-14T06:13:36Z

‎Información sobre el prefijo

Jincera at 06:13, 14 June 2012

2012-06-14T06:13:01Z

Jincera: /* Dirección física de la fuente/destino */

2012-06-12T15:50:40Z

‎Dirección física de la fuente/destino

Jincera at 15:48, 12 June 2012

2012-06-12T15:48:56Z

Jincera at 15:46, 12 June 2012

2012-06-12T15:46:35Z

Jincera: New page: {{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}} TOC El protocolo de descubrimiento de vecinos (NDP, ''Neighbor Discovery Protocol'') permite a un dispositivo integra...

2012-06-12T15:32:11Z

New page: {{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}} __TOC__ El protocolo de descubrimiento de vecinos (NDP, ''Neighbor Discovery Protocol'') permite a un dispositivo integra...

New page

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

__TOC__

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.

{{Tableau eICMPv6}}

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.
* <div vecinos id="NUD"> 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. </div>
* 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 [[Configuración con estado: DHCPv6|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 [[Descubrimiento_de_vecinos#IR |Indicación 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. [[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.

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

{{NB-Opciones}}

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

← Older revision		Revision as of 21:55, 19 June 2012
Line 129:		Line 129:

	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.		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> ==
		+
		+
		+	<tikz title="Formato de la opción MTU'">
		+
		+	\clip (0.2, 5.1) rectangle (11.1, 7);
		+	% \draw[help lines] (0,0) grid (11,6);
		+
		+	\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};
		+
		+	\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
		+	\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght =1 }};
		+	\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};
		+
		+	\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{MTU}};
		+	</tikz>
		+
		+	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.


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

@@ Line 108: / Line 108: @@
 * 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.
 {{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

@@ 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 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. [[Planes de direccionamiento|Duración de vida de las direcciones]]).
+* 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.

← Older revision		Revision as of 06:13, 14 June 2012
Line 63:		Line 63:
	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.		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.

		+	== <div id="información">Información sobre el prefijo</div> ==
		+
		+	<tikz title="Formato de la opción información sobre el prefijo">
		+	\clip (0.2, 2) rectangle (11.1, 7);
		+	% \draw[help lines] (0,0) grid (11,6);
		+
		+	\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};
		+
		+	\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=3}};
		+	\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =4 }};
		+	\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Prefix Length}};
		+	\draw (7.7, 6) node (bitL) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitL.text) node {\tiny{L}};
		+	\draw (8, 6) node (bitA) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitA.text) node {\tiny{A}};
		+	\draw (8.3, 6) node (bitR) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitR.text) node {\tiny{R}};
		+	\draw (8.6, 6) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=1.5cm] {\tiny{Reserved}};
		+
		+	\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Valid Lifetime}};
		+
		+	\draw (0.5, 5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefered Lifetime}};
		+
		+	\draw (0.5, 4.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};
		+
		+	\draw (0.5, 4) node (addr1) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
		+	\draw (0.5, 3.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
		+	\draw (0.5, 3) node (addr3) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefix}};
		+	\draw (0.5, 2.5) node (addr4) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
		+
		+	\draw [color=blue!10, very thick] (addr1.south east) -- (addr1.south west);
		+	\draw [color=blue!10, very thick] (addr2.south east) -- (addr2.south west);
		+	\draw [color=blue!10, very thick] (addr3.south east) -- (addr3.south west);
		+	</tikz>
		+
		+
		+	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 <tt>L</tt> 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 <tt>A</tt> indica, cuando vale 1, que el prefijo anunciado puede utilizarse para formar la dirección del dispositivo.
		+	* 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 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\|Duración 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.
		+	* 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.

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

@@ Line 36: / Line 36: @@
 {{NB-Opciones}}
-== <div id="física">Dirección física de la fuente/destino</div> ==
+== <div id="física">Dirección física de la fuente /destino</div> ==
 <tikz title="Formato de la opción dirección física fuente/destino">

@@ Line 59: / Line 59: @@
 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 ´longitud’’ 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 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.

← Older revision		Revision as of 15:46, 12 June 2012
Line 36:		Line 36:
	{{NB-Opciones}}		{{NB-Opciones}}

		+	== <div id="física">Dirección física de la fuente/destino</div> ==
		+
		+	<tikz title="Formato de la opción dirección física fuente/destino">
		+	\clip (0.2, 5.7) rectangle (11.1,6.7);
		+	% \draw[help lines] (0,0) grid (11,6);
		+
		+	\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};
		+
		+	\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=1/2}};
		+	\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght }};
		+	\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Link Layer Address}};
		+
		+	\draw [draw=white, thick] (addr.north east) -- (addr.south east);
		+	\draw [draw=white, thick] (addr.north east) -- +(-2, 0);
		+	\draw [draw=white, thick] (addr.south east) -- +(-2, 0);
		+
		+	\draw [dashed] (addr.north east) -- (addr.south east);
		+	\draw [dashed] (addr.north east) -- +(-2, 0);
		+	\draw [dashed] (addr.south east) -- +(-2, 0);
		+	</tikz>
		+
		+	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 ´longitud’’ 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.


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