Resumen

  • RFC 5121 exige que la estación móvil y la base negocien como máximo una subcapa de convergencia para IPv6 en el enlace; el acuerdo identifica un método de transporte, no toda la realidad del enlace.
  • Una implementación puede soportar encapsulaciones que la configuración no habilita, mientras que una negociación exitosa todavía necesita flujo de servicio, CID, túnel, prefijo y anuncios correctos.
  • El control fiable conserva recibos distintos para capacidad, disponibilidad, selección, conexión, topología, configuración y entrega observada.

La palabra «soporta» es cómoda porque evita precisar el tiempo y el lugar. Puede significar que el código contiene una función, que el equipo la tiene habilitada, que dos extremos encontraron una opción común, que se creó una conexión o que un paquete cruzó el sistema. RFC 5121 no autoriza esa elasticidad.

El documento limita su alcance a IPv6 sobre la parte específica de IP de la subcapa de convergencia de paquetes de IEEE 802.16. Reconoce también una vía basada en Ethernet. La estación móvil y la base intercambian capacidades durante el registro y, al crear una conexión de transporte, indican la subcapa que usará. Cada acto deja un recibo diferente.

El catálogo de capacidad no es la oferta activa

Para asegurar interoperabilidad, RFC 5121 requiere que las implementaciones de estación base soporten las encapsulaciones de Standards Track definidas por el IETF para 802.16. Pero el propio texto aclara que no tienen que utilizar todas: algunas pueden estar desactivadas mediante configuración.

La diferencia es operativa. Un auditor que lee la matriz de producto conoce el catálogo potencial. Un operador que lee la configuración conoce la oferta local. Ninguno de los dos sabe todavía qué eligieron dos extremos en una sesión concreta. Y aun el registro de la negociación no indica qué hizo después el clasificador con un paquete.

Cuando ambos extremos soportan IP CS, esa es la opción predeterminada. Cuando soportan IP CS y Ethernet CS, deben usar IP CS. En cualquier caso negocian como máximo una subcapa para IPv6 en el enlace. Si no existe una opción común, no se establece la conexión y el host no puede enviar ni recibir IPv6 por ese camino. La selección elimina una ambigüedad real; por eso merece ser registrada con precisión, no inflada hasta convertirse en un certificado general.

El encabezado no decide solo

El encabezado MAC genérico no lleva una indicación específica del tipo de carga. La decisión depende de clasificadores que observan propiedades como direcciones IPv6, cabecera siguiente, clase de tráfico o intervalos de puertos y asignan el paquete a un flujo de servicio y una conexión. El paquete recibe un encabezado MAC de seis bytes y sale por el CID escogido.

Aquí aparece otra serie de estados: regla instalada, regla coincidente, flujo admitido, CID vigente y transmisión observada. Un error en cualquiera de ellos puede coexistir con una negociación perfecta. Si la telemetría conserva solo el resultado de registro, el equipo que investiga un fallo tendrá que reconstruir después qué reglas y asociaciones estaban activas.

Una prueba mínima debería permitir tomar cualquier paquete observado y recorrer hacia atrás su CID, el flujo y el clasificador que lo eligieron; también debería permitir tomar una estación y enumerar todos sus CID sin confundirlos con enlaces IPv6 independientes.

Varios CID, un enlace L3

RFC 5121 dice expresamente que puede haber múltiples conexiones de transporte entre una estación móvil y una base. Si el router de acceso está integrado en la base, la colección de esas conexiones forma un solo enlace IPv6 para la estación. Si está separado, el texto recomienda un túnel cuya granularidad no sea mayor que una estación o un flujo de servicio. Los túneles y las conexiones radio forman juntos el enlace punto a punto.

La capa 3 no copia la topología visual de la capa 2. Cada estación pertenece a un enlace distinto, aunque varias vean la misma base. Por eso cada enlace estación/host debe recibir un prefijo o conjunto de prefijos único. Uno o más /64 pueden anunciarse con el indicador on-link. El tamaño, el número y otras propiedades son cuestiones de configuración, pero la asociación al enlace no puede quedar implícita.

Un túnel agregado por comodidad puede romper esta correspondencia. No basta con declarar que el túnel está cifrado o activo: hay que demostrar qué contexto de estación conserva, qué router lo termina y cómo impide que un prefijo o un paquete aparezca en el enlace equivocado.

Una optimización necesita sus premisas

La detección de direcciones duplicadas puede parecer innecesaria en un enlace punto a punto. RFC 5121 acepta esa posibilidad solo bajo dos condiciones: el prefijo anunciado debe ser único para ese enlace y el router de acceso no debe autoconfigurarse una dirección global con ese mismo prefijo. Una etiqueta p2p no es sustituto de esas pruebas.

Si una plataforma desactiva DAD de manera automática, debe conservar la evidencia que justificó la decisión y volver a validarla cuando cambie el inventario de prefijos o el router. Si no, una optimización diseñada para una topología precisa sobrevive a la topología que la hacía segura.

La política de identificador de interfaz también cambió con el tiempo. El RFC original daba un papel central al identificador EUI-64 derivado de la MAC, aunque permitía identificadores aleatorios. RFC 8064 actualizó esa recomendación y desaconseja incrustar direcciones estables de capa de enlace. Cambió la política de formación de direcciones, no la definición del enlace. Conservar ambos planos separados permite adoptar la actualización sin inventar un nuevo enlace cada vez que cambia un IID.

Dormir no es desaparecer

Una estación 802.16 puede entrar en modo inactivo y desmontar el enlace radio. Despertarla con anuncios periódicos frecuentes consume recursos, así que RFC 5121 permite intervalos largos de Router Advertisement y aconseja no enviar consultas MLD periódicas mientras el host está dormido.

Ese silencio es intencional únicamente si existe un recibo de transición y un mecanismo de paging coherente. Desde otro punto de observación, la pérdida de estado produce el mismo silencio. El monitor debe conocer el estado de reposo, el último anuncio aceptado, las membresías multicast y el evento que obliga a refrescarlas. Contar paquetes de control sin ese contexto castiga el ahorro correcto o encubre una avería.

Tres cifras distintas para el tamaño

El MTU IPv6 predeterminado recomendado es 1500 octetos. Si se usa otro valor, el router debe anunciarlo mediante la opción MTU de Neighbor Discovery. Path MTU Discovery puede mostrar después una limitación en otra parte del camino. Por tanto existen, como mínimo, tamaño configurado, tamaño anunciado y tamaño demostrado por paquetes.

La página del RFC contiene además una advertencia de custodia. Afirma que un campo de longitud de once bits produce una PDU MAC total de 2048 bytes. El erratum 1768 propone 2047, el mayor valor codificable en once bits, pero su estado es «Held for Document Update». Un sistema serio no borra ese estado. Conserva el texto publicado, la observación aritmética y la clasificación del erratum.

La prueba operativa no se decide entre dos números de una página. Se decide con tamaños controlados, mensajes Packet Too Big, capturas en los límites y el resultado del tráfico real.

Un contrato pequeño, recibos completos

La respuesta no es centralizar cada decisión. El contrato común puede ser pequeño: formato seleccionado, extremos del enlace, identificadores que unen flujo y camino, y una salida de evidencia que otros puedan comprobar. Las políticas locales de automatización, ahorro radio o asignación permanecen locales y reemplazables.

La condición es no comprimir la cadena en una sola bandera. Capacidad dice lo que el producto podría hacer. Configuración dice lo que se permitió. Negociación dice lo que dos extremos eligieron. Conexión dice lo que se creó. Captura dice lo que ocurrió. Resultado dice si el servicio sirvió al usuario. La claridad consiste en impedir que el primer verbo suplante a los demás.

Fuentes