Resumen

  • Un borrador individual del 28 de octubre define NEXT_HOP_MTU como atributo BGP opcional y no transitivo de cuatro octetos para rutas unicast IPv4 e IPv6. Indica el tamaño IP aceptable en un borde identificado, no el mínimo de todas las conexiones hasta el destino.
  • El valor nuevo parte del MTU del borde local. Si se acepta una cifra válida del vecino, se anuncia la menor; la política local puede bajar más, jamás subir. Para programar un MTU de reenvío por destino, cada trayectoria posible debe llevar una cifra válida.

El número viaja; su autoridad no crece

Imaginemos que un router fronterizo recibe una ruta en un enlace que permite paquetes grandes. Puede adjuntar esa capacidad a la ruta y comunicarla a sus vecinos internos. Esa información ayuda a un emisor que cruza precisamente ese borde. Pero hay otros enlaces después. El texto propuesto insiste en que el atributo no representa el MTU de extremo a extremo y no cambia por sí solo la decisión de rutas BGP. Una cifra en el plano de control no puede ensanchar un cable que no ha medido.

La operación principal es min(L,R): L es el MTU IP de la interfaz fronteriza propia; R, una cifra válida recibida y admitida según la política para ese vecino. Si no hay R aceptable, se usa L. La política local puede reducir el resultado, nunca aumentarlo. Tampoco puede sustituirse el borde de verdad por una cómoda interfaz interior. En una sesión externa de varios saltos no cabe inventar una frontera a partir de una interfaz ajena; una cifra configurada debe respetar la interfaz que conduce al siguiente salto.

No todos tienen que anunciar ni aceptar el atributo. Ambas funciones deben poder activarse por separado para cada vecino y familia de direcciones; ninguna viene exigida por defecto. Su ausencia significa que no hay promesa. Un reflector interno con el mismo siguiente salto debería transmitir el dato sin cambios; una nueva frontera externa debe calcular el mínimo con su propio MTU. Una ruta agregada sólo puede llevar cifra si todos sus componentes la tienen. Un destino sólo puede recibir un MTU de reenvío programado si todos sus caminos tienen valores válidos, usando el menor. El camino sin dato tiene derecho a bloquear esa conclusión.

Si el atributo está mal formado, se descarta conforme a la RFC 7606; la sesión BGP sigue y la ruta no desaparece. Cuando cambia el MTU físico del borde, debe anunciarse una ruta de reemplazo. El código de atributo figura como TBD; el registro de IANA es la referencia para una asignación efectiva. Una cifra inflada puede causar pérdida de paquetes; una demasiado baja sacrifica capacidad, por lo que la confianza en el vecino externo también importa.

La descubierta del MTU de trayectoria para IPv6 sigue resolviendo el mínimo del recorrido completo. La ficha del IETF lo presenta como propuesta individual, sin prueba de despliegue ni ganancia medida. Una prueba que siga el valor por varias fronteras y documente cada reducción mostraría si la promesa se mantiene en su sitio.

Fuentes: borrador; estado IETF; IANA; RFC 7606; RFC 8201.