RFC 4944: Paquetes IPv6 Sobre Redes 802.15.4

Redes de Telecomunicaciones
Tarea 1

Un RFC (Petición de comentarios, del inglés Request For Comments) es un informe técnico donde se muestra un estándar aprobado o aun en discusión por un comité.

Estos se encuentran en línea en el siguiente enlace:

www.ietf.org/assignments/

Este RFC fue agregado en la lista en Septiembre del 2007, por integrantes que trabajan en Microsoft Corporation, Intel y Arch Rock Corp.

El documento completo se encuentra en la siguiente liga:

http://datatracker.ietf.org/doc/rfc4944/

El estándar IEEE 802.15.4 esta dirigido a los usuarios de redes personales de área local de bajo rango. EL documento define un formato de marco para la transmisión de paquetes mediante IPv6 (documentado anteriormente en RFC 2460) y la formación de paquetes para IPv6 locales. IPv6 requiere el apoyo de paquetes con tamaños mucho más grandes que el tamaño que el estándar 802.15.4 permite. Este documento también define mecanismos para la compresión de cabecera requerido para IPv6 práctico en el estándar 802.15.4, así como las disposiciones necesarias para la entrega de paquetes en 802.15.4 con mallas.

EL estándar 802.15.4 define cuatro tipos de marcos: marcos beacon, marcos de dirección MAC, marcos de acuse de recibo, y tramas de datos. Las tramas de datos pueden opcionalmente solicitar que se les reconozca. De acuerdo con el RFC 3819, se recomienda que los paquetes IPv6 sean transportados en tramas para las cuales el reconocimiento se solicita con el fin de ayudar a la recuperación de la capa de enlace.

Una recomendación que se hace es que los eventos estén disponibles en la capa de IPv6 para ayudar en la detección de conexión de red, un problema que se está trabajando en el IETF en el momento en que el documento fue escrito. La especificación permite marcos en los que el origen o direcciones de destino (o ambos) se suprimen. Los mecanismos definidos en el documento requieren que ambas direcciones de origen y de destino se incluyan en la cabecera de la trama 802.15.4.

Modos de direccionamiento

El IEEE 802.15.4 define varios modos de direccionamiento: permite el uso de direcciones de 64 bits extendidos o después de un evento, direcciones de 16-bits único en el PAN. Este documento se usan estos dos tamaños de direcciones, una de 64 bits para direcciones extendidas, y de 16-bit para direcciones cortas.

Unidad de transmisión máxima

El tamaño de MTU de los paquetes IPv6 sobre 802.15.4 es de 1280 octetos. Sin embargo, un paquete IPv6 completo no cabe en un marco normal del 802.15.4. Se usan unidades de datos de protocolo que tienen diferentes tamaños dependiendo de cuanto gasto está presente. A partir de un máximo, la capa física tiene un tamaño de paquete de 127 octetos y un gasto general de trama máximo de 25, la resultante del tamaño máximo de la trama a la capa de control de acceso al medio es de 102 octetos. La capa de seguridad impone sobrecarga adicional, que en el máximo caso deja sólo 81 octetos disponibles. Esto es, obviamente, muy por debajo del tamaño de paquete IPv6 mínimo de 1280 octetos, y de acuerdo con la Sección 5 del IPv6 especificación del RFC 2460, una fragmentación de adaptación y montaje en la capa debe ser proporcionado a la capa por debajo de IP.

Capa de adaptación y Formato de trama

Los formatos de encapsulado definidos en esta sección (posteriormente se mencionan como la "encapsulación LoWPAN") son la carga en la MAC del 802.15.4. La carga útil LoWPAN sigue esta cabecera de encapsulación. Todos los datagramas encapsulados en LoWPAN y transportados a través del 802.15.4 son predecedidos por una pila de cabecera de encapsulación. Una cabecera IPv6 normal tendría una pila que contendría, en el siguiente orden, direccionamiento, opciones de enrutamiento, fragmentación, opciones de destino y finalmente, la carga útil, y en una LoWPAN el encabezado, el encabezado de secuencia análoga de mallas a abordar, opciones de enrutamiento, la fragmentación y finalmente la carga útil. Estos ejemplos muestran pilas típicas de cabecera que pueden ser usados en una red LoWPAN.

Un ejemplo de este encapsulado:

+ ------------- + ------------- + ----- +
| IPv6 apertura | IPv6 cabecera | Carga |
+ ------------- + ------------- + ----- +

EL primer patrón de la cabecera puede ser como sigue, en 8 bits se menciona la siguiente información de la tabla (se explica adelante que significa cada cosa).

+------------+-----------------------------------------------+
| 00  xxxxxx | NALP       - Not a LoWPAN frame               |
| 01  000001 | IPv6       - Uncompressed IPv6 Addresses      |
| 01  000010 | LOWPAN_HC1 - LOWPAN_HC1 compressed IPv6       |
| 01  000011 | reserved   - Reserved for future use          |
|   ...      | reserved   - Reserved for future use          |
| 01  001111 | reserved   - Reserved for future use          |
| 01  010000 | LOWPAN_BC0 - LOWPAN_BC0 broadcast             |
| 01  010001 | reserved   - Reserved for future use          |
|   ...      | reserved   - Reserved for future use          |
| 01  111110 | reserved   - Reserved for future use          |
| 01  111111 | ESC        - Additional Dispatch byte follows |
| 10  xxxxxx | MESH       - Mesh Header                      |
| 11  000xxx | FRAG1      - Fragmentation Header (first)     |
| 11  001000 | reserved   - Reserved for future use          |
|   ...      | reserved   - Reserved for future use          |
| 11  011111 | reserved   - Reserved for future use          |
| 11  100xxx | FRAGN      - Fragmentation Header (subsequent)|
| 11  101000 | reserved   - Reserved for future use          |
|   ...      | reserved   - Reserved for future use          |
| 11  111111 | reserved   - Reserved for future use          |
+------------+-----------------------------------------------+

NALP: Especifica que los siguientes bits no son parte de la encapsulación LoWPAN, y cualquier nodo LoWPAN que se encuentra con un valor de 00xxxxxx descartará el paquete. Otros protocolos que desean coexistir con nodos LoWPAN deben incluir una byte que coincide con este patrón inmediatamente después del encabezado.

IPv6: Especifica que la siguiente cabecera IPv6 esta sin comprimir.

LOWPAN_HC1: Especifica que el siguiente encabezado es un LOWPAN_HC1 comprimido IPv6.

LOWPAN_BC0: Especifica que el siguiente encabezado es un LOWPAN_BC0 de malla difusa.

ESC: Especifica que el siguiente encabezado es un solo campo de 8 bits para el valor dispatch. Permite soporte para los valores de dispatch más grande que 127.

Los subsiguientes fragmentos de enlace deberá contener una cabecera de fragmentación que se ajusta al formato que se muestra a continuación.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 0|    datagram_size    |         datagram_tag          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|datagram_offset|
+-+-+-+-+-+-+-+-+

datagram_size: Este campo de 11-bits codifica el tamaño de IP completa antes de la fragmentación de paquetes de capa de enlace. El valor del datagram_size será el mismo para todos los fragmentos de la capa de enlace de un paquete IP. Para IPv6, éste será 40 octetos (el tamaño de la cabecera IPv6 sin comprimir) más que el valor de longitud de carga útil de la cabecera IPv6. Tenga en cuenta que este paquete ya puede ser fragmentado por los anfitriones involucrados en la comunicación, es decir, este campo debe codificarse en una longitud máxima de 1280 octetos.

datagram_tag: El valor del datagram_tag será el mismo para todos los fragmentos de enlace de una carga útil de datagramas. El valor incrementado de datagram_tag debe retornar desde 65535 a cero. Este campo es de 16 bits de longitud, y su inicial valor no está definido.

datagram_offset: Este campo especificará el desplazamiento en incrementos de 8 octetos del fragmento desde el comienzo de la carga útil del datagrama. El primer octeto de los datagramas (por ejemplo, la inicio de una cabecera IPv6) tiene un desplazamiento de cero.

Dirección local de enlace IPv6

La dirección IPv6 local de enlace para una interfaz se forma añadiendo el identificador de interfaz, como se define anteriormente, a el prefijo FE80 :: / 64.

   10 bits            54 bits                  64 bits
+----------+-----------------------+----------------------------+
|1111111010|         (zeros)       | Identificador de Interfaz  |
+----------+-----------------------+----------------------------+

Crítica constructiva

En los últimos años muchos grupos de expertos han estado trabajando en la estandarización del protocolo IPv6 que pronto sustituirá a la ya existente IPv4, y con la que se han presentado problemas debido a que lo que se desea hacer para lograr una transferencia eficaz de un estándar a otro, es no tener que cambiar el hardware de nuestros dispositivos. Por lo que se han hecho cambios en cuanto a como se enviaban los datos en un paquete con IPv4 y como enviarlo ahora con IPv6, ya que la dirección evidentemente es más grande en cuanto a caracteres/bytes, y en cada uno de los estándares del grupo de trabajo 802 se han tenido que realizar una serie de propuestas para la estandarización en el envio de paquetes.

En el caso particular de este RFC, se intenta crear un estándar para lograr que direcciones IPv6 puedan ser agregadas en los paquetes sin afectar al contenido útil. En pocas palabras se hace un cambio en el tamaño en bits de las secciones del paquete para poder contener la información necesaria para la comunicación.

Referencias:
RFC 5104