Resumen

  • RFC 4084 distingue conectividad web, solo cliente, protegida por cortafuegos y completa sin declarar que una sea legítima y otra no; exige claridad sobre funciones y restricciones.
  • La aceptación útil separa lo anunciado, lo contratado, lo configurado por el proveedor y lo observado en pruebas repetibles. Un relay o túnel que salva una aplicación no crea una garantía de servicio.

La velocidad no describe la superficie

Una conexión supera la prueba de ancho de banda y, sin embargo, no puede recibir una sesión desde fuera. Otra permite una VPN durante horas, pero pierde el estado al quedar inactiva. Una tercera muestra una dirección pública al navegador aunque el equipo del cliente tenga una dirección privada compartida. Las tres pueden venderse como «acceso a Internet».

RFC 4084 nació para ordenar esa diferencia. Publicado en 2005 como BCP 104, enumera modelos de capacidad ascendente: acceso web; cliente sin dirección pública; cliente con dirección pública; conectividad con cortafuegos administrado; y conectividad completa. Su objetivo no es decidir qué producto debe existir. Los términos son deliberadamente no peyorativos. Una oferta limitada puede ser correcta para un uso limitado, siempre que no se presente como algo que no es.

Para el comprador, la consecuencia es precisa: el nombre de producto no puede ser la prueba de aceptación. Hay que verificar las operaciones de las que dependerá la organización.

Dirección, entrada y permiso son hechos distintos

Tener dirección pública no equivale a poder operar un servidor. RFC 4084 contempla un servicio de cliente con dirección pública donde el proveedor bloquea intentos entrantes o prohíbe servidores por contrato. También contempla acceso sin dirección pública, donde NAT limita servidores y muchas funciones P2P, y conectividad completa, incompatible con NAT y restricciones impuestas por el proveedor sobre tráfico o puertos.

La ficha de dirección debe indicar IPv4 e IPv6, exclusividad, estabilidad, clasificación dinámica, DNS inverso, traducción y alcance entrante. Debe decir quién controla cada punto. Si el cortafuegos fue pedido por el cliente, la información no puede aparecer como una limitación intrínseca del proveedor.

RFC 4787 añade una advertencia técnica. El mapeo de NAT y su filtrado son comportamientos separados. Los temporizadores, los paquetes que renuevan estado y el extremo remoto pueden cambiar el resultado. El P2P que funciona una vez puede estar aprovechando un estado efímero; otro intento puede necesitar relay. Por ello, la prueba conserva hora, origen, destino, puertos, dirección, intervalos y repeticiones.

El contorno editorial es importante. Un mecanismo de evasión puede ser excelente ingeniería y mantener una aplicación disponible. No demuestra que el proveedor prometa conectividad entrante, ni que permita servidores, ni que vaya a sostener el mismo comportamiento cuando cambie la red.

Una recepción con cuatro planos

El plano anunciado conserva el nombre comercial, la versión de la oferta y la capacidad declarada. El plano contratado registra permisos, prohibiciones, asistencia, estabilidad de dirección, uso P2P, servidores, filtros, relay de correo y opciones de seguridad.

El plano configurado documenta la superficie controlada por el proveedor: NAT, filtros de entrada y salida, proxy, interceptación, DNS, ICMP, túneles, redirección de correo y cortafuegos solicitado por el cliente. Necesita fecha e identidad de cambio.

El plano observado describe un ensayo delimitado. Incluye los puntos de medición internos y externos, protocolos, puertos, direcciones vistas, tiempo de inactividad, número de repeticiones y resultado. No modifica el contrato. Tampoco deduce intención.

Tres campos evitan falsas equivalencias: solicitado por el cliente, dependiente de workaround y evento de nueva prueba. Así, una operación puede estar técnicamente disponible pero fuera del soporte; una aplicación puede funcionar solo gracias a un tercero; o una medición puede caducar tras cambiar CPE, dirección, contrato o tecnología de acceso.

El correo obliga a abrir la caja

RFC 4084 detalla restricciones de correo porque exponen las capas ocultas. Un proveedor puede exigir su servidor de envío, bloquear puertos hacia servidores externos, desviar tráfico, limitar POP3 o IMAP4 o marcar direcciones dinámicas de modo que afecte la entrega. El éxito del webmail solo acredita la web.

La recepción separa envío autenticado, SMTP externo, recuperación remota, dominios de remitente, DNS inverso, reputación y cualquier desvío. Para VPN, registra la familia de túnel, el sentido, el comportamiento al quedar inactiva y el fallback. Para DNS, pregunta si se llega a resolvers arbitrarios o si hay redirección. Para ICMP, indica qué diagnóstico cruza el borde. Para servicios entrantes, diferencia prohibición, filtro, interceptación y falta de prueba.

La restricción necesita un responsable

RFC 7754 distingue quien fija una política de quien la ejecuta. Un timeout no revela por sí mismo propósito, legalidad ni autoridad. La prueba de capacidades debe nombrar, cuando exista evidencia, quién pidió la regla, quién la implementó y dónde se observó.

Eso mejora el conflicto. En vez de afirmar que «el ISP bloquea», se puede registrar que dos redes externas no alcanzaron un puerto, que el contrato contiene una restricción o no la contiene, y que el cortafuegos administrado fue solicitado por una parte concreta. La afirmación pequeña es auditable y permite reparar el plano correcto.

Fuentes