Resumen

  • RFC 1681 sugirió codificar en la dirección de destino una clase que indicara quién paga, o un índice hacia una tabla de algoritmos de cobro, para actuar antes del contacto.
  • El texto rechazó que el usuario conociera el coste a posteriori y explicó que un aviso al conectar no servía cuando la interacción era automática o una redirección Gopher llevaba silenciosamente a una dirección de pago.
  • La señal podía alimentar una política de red, pero no probar por sí sola al principal humano, las condiciones vigentes, la autorización informada, el servicio útil, el contador correcto, la factura válida o su liquidación.

El momento de la advertencia era parte de la seguridad

RFC 1681 no comienza su problema de cobro con una tabla financiera, sino con la falta de una pausa. Imagina que un servidor Gopher redirige al llamante hacia una dirección «pay-to-play» sin presentar el aviso requerido. No afirma que el fraude ocurriera en Gopher. Usa la escena para mostrar que el software podía cruzar un umbral económico antes de que una persona tuviera ocasión de decidir.

Por eso el documento considera insuficiente mostrar un mensaje al establecer la conexión. Muchas interacciones no ofrecían un punto de intervención humana. Una advertencia posterior al primer contacto podía informar, pero ya no garantizaba una negativa previa al coste.

La solución propuesta adelantaba una parte de la semántica comercial. Algunos bits de la dirección determinarían quién paga. Con un campo mayor, la propia dirección sería un índice de una tabla de algoritmos de cobro. Los routers de frontera de una organización podrían reconocer servicios de pago y aplicar su política local antes de reenviar.

La dirección no contenía toda la tarifa. Era una etiqueta temprana y un selector de política. Su valor estaba en el orden: llegaba antes que el contacto, no después que la factura.

La demanda de direcciones seguía a los usos, no solo a los equipos

La propuesta de cobro pertenecía a un argumento sobre capacidad. En 1994, la mayoría de los hosts finales tenía una sola dirección y era habitual estimar el espacio necesario contando máquinas. RFC 1681 advertía que ese modelo podía fallar si un host necesitaba identidades distintas para servicios, vistas de acceso, usuarios o movilidad limitada.

Una dirección secundaria podía permanecer asociada a un servicio aunque este cambiara de máquina. Varias direcciones en un mismo host podían ofrecer políticas de acceso diferentes sin enseñar un protocolo nuevo ni un puerto especial a toda la comunidad usuaria. Un cortafuegos podía abrir la dirección del servicio y cerrar las demás, siempre que los procesos estuvieran ligados correctamente. Los riesgos habituales de autenticar por dirección seguían presentes.

El memo también pensó en ampliar DNS para devolver información de puerto. La objeción fue operativa: habría que modificar cada cliente relevante. Dar más significado a la dirección aprovechaba el comportamiento de aplicaciones ya desplegadas.

Pero el ahorro en clientes concentraba funciones heterogéneas. La dirección podía localizar un host, identificar un servicio, expresar una política de acceso, seguir una sesión de usuario, facilitar movilidad y seleccionar una regla de cobro. Cada función tenía su propio reloj. El servicio podía sobrevivir al servidor físico; la dirección de usuario podía expirar al cerrar sesión; la tabla comercial podía cambiar sin alterar el destino. El identificador persistente no conservaba automáticamente la versión de todos sus significados.

Cuatro modelos responden quién paga, no cuánto se debe

RFC 1681 enumeró cuatro esquemas. En el «pago por uso» ordinario, cada host se hacía cargo de sus propios paquetes, de modo que ambas partes podían pagar. En «caller pays», asumía el coste quien iniciaba. En una llamada a cobro revertido, pagaba el receptor. En el equivalente a los números estadounidenses «900», el llamante abonaba una prima al servidor.

La diversidad hacía imprescindible que emisor y receptor supieran de antemano quién cargaba con el coste. Descubrirlo después de incurrir en él era inaceptable.

Sin embargo, el pagador es solo un campo. RFC 1125 había distinguido unidad contable, base del cobro, importe real, quién paga o cobra, qué contador de paquetes se utiliza y qué límites se aplican. Leer correctamente un bit de «paga el llamante» no dice si se cobra por byte, paquete o sesión, qué versión del precio rige, qué medidor prevalece ni cuál era el tope autorizado.

La variante de RFC 1681 que usa un índice deja visible esa dependencia. Una dirección que apunta a una fila no conserva el contenido de la fila. Para reconstruir un cargo habría que guardar la tabla, su versión, su operador y su periodo de vigencia. De lo contrario, sobrevive la clave y desaparece la regla.

La frontera podía bloquear una clase, no otorgar mandato comercial

El router organizativo ofrecía un punto de control concreto. El documento imagina que las estaciones anónimas de una residencia universitaria no pudieran aceptar llamadas a cobro revertido. El administrador podía decidir qué categorías atravesaban su frontera sin esperar a que cada aplicación incorporara una interfaz de precios.

Esa decisión era local y real, pero limitada. Permitir un paquete no demostraba que el titular de la cuenta hubiese consentido. El ordenador podía ser compartido, el programa actuar solo y el usuario disponer de una autorización parcial. El proveedor remoto podía mantener otra versión de la tabla. La red podía cumplir su regla y aun así dejar abierta la responsabilidad por el cargo.

RFC 1681 propuso además asignar una dirección IP a cada usuario durante la sesión. El router seguiría contabilizando por dirección; el host guardaría la asignación; la facturación se haría fuera de línea. Distintas clases de usuario podrían recibir formas de dirección con permiso o prohibición para servicios costosos.

La ventaja era poder enlazar registros que antes tenían granularidades distintas. No era una prueba automática de persona. Harían falta el contador del router, el historial horario de asignación del host, la autenticación, el alcance del mandato, la tabla aplicable y la evidencia del servicio. Una dirección por usuario reduce la ambigüedad; no demuestra quién manejó la sesión ni quién aprobó esa transacción.

La condición de documento histórico impide inventar la adopción

La ficha de RFC Editor identifica RFC 1681 como Informational. Fue una respuesta a la convocatoria de documentos IPng de RFC 1550, y su resumen dice que la publicación no implicaba que el área IPng aceptase las ideas. RFC 1550 trataba esos textos como material para la selección y como parte del registro histórico.

El futuro ofrece comparaciones, no confirmaciones. RFC 4291 permite que una interfaz IPv6 tenga múltiples direcciones de distintos tipos y alcances. Eso demuestra que la multiplicidad de direcciones forma parte de IPv6, no que se adoptaran bits de cobro ni que RFC 1681 causara esa arquitectura.

RFC 2782 definió el registro DNS SRV con servicio, protocolo, prioridad, peso, puerto y destino, además de reglas de aplicabilidad para los clientes. Sirve para localizar un servicio. No contiene un precio normalizado, un pagador, un consentimiento, un medidor o una factura.

La recomendación de reservar 2^6, quizá 2^8, direcciones extra por host era margen para posibilidades como servicios múltiples y la costosa dirección por usuario. No era una media observada ni una asignación garantizada.

Del destino al pago hay diez recibos diferentes

Una reconstrucción responsable tendría que separar la dirección elegida; la clase o índice de cobro; la tabla vigente y su propietario; la decisión del router; la cuenta y principal autenticados; las condiciones mostradas antes del compromiso y la respuesta del usuario; la admisión y entrega útil del servicio; la unidad, el contador y el intervalo medidos; el cálculo de factura, pagador y límites; y el pago, reversión o disputa.

Cada paso responde una pregunta distinta. La clase no prueba la vigencia de la tabla. La admisión del router no prueba consentimiento. La conexión no prueba utilidad. El contador no fija el precio. La factura no prueba el pago.

La Primacía del Código en Ejecución de Heng Lu obliga a no convertir una propuesta, una publicación o una etiqueta en realidad adoptada. La Especificación Inicial Mínima separa la semántica común necesaria para interoperar de los acuerdos comerciales que pueden decidirse localmente. Realidad, no promoción completa la disciplina: RFC 1681 no necesita ser reivindicado ni ridiculizado, sino leído con el alcance exacto de sus pruebas.

El memo quiso que la red viera una regla antes de gastar el dinero de alguien. Esa prioridad temporal sigue siendo valiosa, pero solo si la señal temprana no se usa para borrar las pruebas posteriores de identidad, autorización, prestación, medida y liquidación.

Fuentes