Network Working Group D. Perkins Request for Comments : 1172 CMU R. Hobby UC Davis Julio 1990 Traducción al castellano: Octubre 2002 Rubén Afonso Francos Opciones Iniciales de Configuración del Protocolo Punto a Punto (PPP) Estado de este memorándum Este RFC especifica un protocolo de seguimiento de estándar de Internet para la comunidad Internet. Por favor, remítase a la edición actual de "Estándares de Protocolo Oficiales de Internet" para las condiciones de estandarización y estatus de este protocolo. Esta propuesta es fruto del Grupo de Trabajo del Protocolo Punto a Punto perteneciente al Grupo Especial sobre Ingeniería de Internet (IETF). Los comentarios sobre este memorándum deben enviarse al presidente del Grupo de Trabajo del Protocolo Punto a Punto del IETF. La distribución de este memorándum es ilimitada. Resumen El Protocolo Punto a Punto (PPP) proporciona un método para transmitir datagramas sobre enlaces punto a punto en serie. PPP está formado por : 1) un procedimiento para encapsular datagramas sobre enlaces en serie, 2) un Protocolo de Control de Enlace (LCP) ampliable, y 3) una familia de Protocolos de Control de Red (NCP) para establecer y configurar los diferentes protocolos de red. El esquema PPP de encapsulación, LCP básico, y NCP (llamado Protocolo de Control de IP, IPCP) para controlar y establecer el Protocolo de Internet (IP) están descritos en El Protocolo Punto a Punto (PPP) [1]. Este documento define las opciones iniciales utilizadas por LCP y por IPCP. También especifica un procedimiento para la Monitorización Perkins & Hobby [Pág. 1] RFC 1172 Opciones Iniciales PPP Julio 1990 de la Calidad del Enlace y un sencillo método de autentificación. Tabla de Contenidos 1. Introducción ......................................... 3 2. Opciones de Configuración del Protocolo de Control de Enlace (LCP) ........................... 3 2.1 Unidad Máxima de Recepción ...................... 4 2.2 Mapeado Asíncrono de los Caracteres de Control ........................... 5 2.3 Método de Autentificación ....................... 7 2.4 Número Mágico ................................... 9 2.5 Monitorización de la Calidad del Enlace ......... 13 2.6 Compresión del Campo Protocolo .................. 14 2.7 Compresión de los Campos Dirección y Control..... 16 3. Monitorización de la calidad del enlace .............. 18 3.1 Motivos de diseño ............................... 18 3.2 Descripción del diseño .......................... 19 3.3 Procesos ........................................ 20 3.4 Contadores ...................................... 21 3.5 Mediciones, cálculos, variables de estado ....... 22 3.6 Formato de los paquetes de informe de la calidad del enlace ...................................... 24 3.7 Sugerencias de actuación ........................ 28 3.8 Ejemplo ......................................... 29 4. Protocolo de Autentificación de Contraseña ....... 31 4.1 Formato de los paquetes ..................... 31 4.2 Autentificación ............................. 33 4.3 Ack de autentificación ...................... 35 4.4 Nak de autentificación ...................... 36 5. Opciones de Configuración del Protocolo de Control de IP (IPCP) ..................................... 37 5.1 Direcciones IP .............................. 38 5.2 Tipo de compresión .......................... 40 REFERENCIAS ............................................. 41 CONSIDERACIONES DE SEGURIDAD ............................ 41 DIRECCIÓN DEL AUTOR ..................................... 41 Perkins & Hobby [Pág. 2] RFC 1172 Opciones Iniciales PPP Julio 1990 1. Introducción El Protocolo Punto a Punto (PPP) [1] proporciona un método estándar para encapsular datagramas IP y datos de otros protocolos de red sobre enlaces punto a punto. PPP también suministra un Protocolo de Negociación de Opciones ampliable. [1] solamente especifica el protocolo en sí mismo; las Opciones de Configuración están descritas en este documento. Dichas Opciones de Configuración permiten la variación de la unidad de transmisión máxima (MTU, Maximum Transmission Unit), la asignación dinámica de direcciones IP o la activación de la compresión de cabeceras, entre otras. Este memorándum está dividido en varias secciones. La sección 2 describe las Opciones de Configuración del Protocolo de Control de Enlace. La sección 3 especifica el uso de la opción Monitorización de la Calidad del Enlace. La sección 4 define un sencillo Protocolo de Autentificación de Contraseña. Finalmente, la sección 5 especifica las Opciones de Configuración para el Protocolo de Control de IP. 2. Opciones de Configuración del Protocolo de Control de Enlace (LCP) Como se describe en [1], las Opciones de Configuración del LCP permiten modificar las características estándar de un enlace punto a punto mediante la negociación. Las modificaciones negociables propuestas en este documento incluyen la unidad máxima de recepción, el mapeado asíncrono de los caracteres de control, el método de autentificación del enlace, etc. Los valores iniciales propuestos para el campo Tipo de Opción de Configuración LCP (ver [1]) están asignados de la siguiente manera : 1 Unidad Máxima de Recepción 2 Mapeado Asíncrono de los Caracteres de Control. 3 Método de autentificación. 4 SIN ASIGNAR 5 Número Mágico. 6 Monitorización de la Calidad del Enlace. 7 Compresión del Campo Protocolo. 8 Compresión de los campos Dirección y Control. Perkins & Hobby [Pág. 3] RFC 1172 Opciones Iniciales PPP Julio 1990 2.1. Unidad Máxima de Recepción Descripción Esta Opción de Configuración proporciona una forma de negociar el tamaño máximo de los paquetes que circulan en una dirección del enlace. Por defecto, todas las implementaciones deben ser capaces de recibir tramas con 1500 octetos de información. Esta Opción de Configuración puede ser enviada para informar al extremo de que puedes recibir tramas mayores, o para pedirle que envíe tramas mas pequeñas. Si se piden tramas de menor tamaño, la implementación DEBE ser capaz de seguir recibiendo tramas de 1500 octetos en el caso de que se pierda la sincronización del enlace. Abajo se muestra un esquema del formato de la Opción de Configuración Unidad Máxima de Recepción. Los campos se transmiten de izquierda a derecha. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tipo | Longitud | Unidad Máxima de Recepción | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tipo 1 Longitud 4 Unidad Máxima de Recepción El campo Unidad Máxima de Recepción está formado por dos octetos e indica la nueva unidad máxima de recepción. La Unidad Máxima de Recepción incluye el campo Información del Nivel de Enlace, pero no incluye la cabecera, la cola, o cualquier bit o bytes de transparencia. Por defecto 1500 Perkins & Hobby [Pág. 4] RFC 1172 Opciones Iniciales PPP Julio 1990 2.2 Mapeado Asíncrono de los Caracteres de Control Descripción Esta Opción de Configuración proporciona una forma de negociar el uso del mapeado de los caracteres de control en enlaces asíncronos. Por defecto, PPP traduce todos los caracteres de control a su correspondiente secuencia de dos caracteres. Sin embargo, en muy pocas ocasiones se necesita traducir todos los caracteres de control e incluso muchas veces no se necesita traducir ninguno. La implementación PPP puede usar esta Opción de Configuración para informar al otro extremo sobre los caracteres de control que deben seguir traduciéndose y los que no cuando el otro extremo los envíe. Este todavía podría traducir estos caracteres si fuese necesario debido a limitaciones en su lado de la conexión. Esta Opción de Configuración no soluciona los problemas de los enlaces de comunicación que sólo pueden transmitir caracteres de 7 bits o que no pueden enviar todos los caracteres que no son de control. Pueden utilizarse conversores síncrono-asíncrono (algunos incluidos en modems) que, utilizados en enlaces Punto a Punto, permitan la existencia de una implementación PPP síncrona en un extremo y una implementación asíncrona en el otro extremo del enlace. Es responsabilidad del conversor realizar todas las conversiones de mapeado durante la operación. Para facilitar esta labor, las implementaciones PPP síncronas siempre DEBEN aceptar una Opción de Configuración Mapeado Asíncrono de los Caracteres de Control (y siempre DEBEN responder a una Petición LCP de Configuración que solicite esta Opción de Configuración con un Ack LCP de Configuración). Sin embargo, que la implementación síncrona acepte esta Opción de Configuración no implica que vaya a realizar la traducción de los caracteres ya que las implementaciones PPP síncronas utilizan el relleno de bits en lugar del relleno de caracteres. En vez de eso, todo el mapeado de los caracteres será realizado por el conversor asíncrono- síncrono. Debajo se muestra un esquema del formato de la Opción de Configuración Mapeado Asíncrono de los Caracteres de Control. Los campos se transmiten de izquierda a derecha. Perkins & Hobby [Pág. 5] RFC 1172 Opciones Iniciales PPP Julio 1990 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tipo | Longitud | Mapeado Asíncrono de los +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Caracteres de Control (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tipo 2 Longitud 6 Mapeado Asíncrono de los Caracteres de Control El campo Mapeado Asíncrono de los Caracteres de Control ocupa cuatro octetos e indica el nuevo mapeado asíncrono de los caracteres de control. El mapeado se codifica siguiendo el estilo Big-Endian donde cada bit numerado corresponde al carácter de control ASCII del mismo valor. Si el bit está a cero, entonces ese carácter de control ASCII no necesita ser traducido. Si el bit está a uno, el carácter de control ASCII debe continuar traduciéndose. Por ejemplo, si el bit 19 está a cero, el carácter de control ASCII número 19 (DC3, Control-S) debe ser enviado sin traducir. Por defecto Todos a uno (0xffffffff). Perkins & Hobby [Pág. 6] RFC 1172 Opciones Iniciales PPP Julio 1990 2.3. Método de autentificación Descripción Algunos enlaces pueden requerir que el otr extremo se autentifique antes de permitir el intercambio de datos en el Nivel de Red. Esta Opción de Configuración proporciona una forma de negociar el uso de un protocolo de autentificación determinado. Por defecto, la autentificación no es necesaria. Si la implementación requiere que el otro extremo se autentifique mediante algún protocolo de autentificación en particular debería negociar el uso de dicho protocolo mediante esta Opción de Configuración. Si la opción Tipo de Autentificación se negocia satisfactoriamente, se añade una fase adicional de autentificación al Protocolo de Control de Enlace. Esta fase se sitúa después de la fase de Determinación de la Calidad de Enlace, y antes de la fase de Negociación de la Configuración del Protocolo de Red. El paso de la fase de autentificación a esta última no se producirá hasta que el otro extremo se haya autentificado correctamente utilizando el protocolo de autentificación previamente negociado. Una implementación puede permitir que el extremo elija entre más de un protocolo de autentificación. Para ello puede incluir varias Opciones de Configuración Tipo de Autentificación en sus paquetes de Petición de Configuración. Si una implementación recibe un paquete especificando varios Tipos de Autentificación, como mucho podrá escoger uno de ellos y debería enviar una Negativa de Configuración especificando todos los demás protocolos de autentificación. Se recomienda que la implementación PPP permita la configuración de los parámetros de autentificación al menos por cada interfaz, si no lo hace por cada máquina que se conecta. Los parámetros deberían especificar cuáles son los requisitos mínimos, tanto de la propia implementación como del extremo, en lo que a técnicas de autentificación se refiere para poder establecer la conexión PPP. Estas medidas son necesarias para evitar que un atacante negocie un protocolo de muy baja seguridad, o carente de la misma, en un intento de evitar estas medidas de autentificación. Si una implementación envía un Ack de Configuración con esta Opción de Configuración significa que está de acuerdo en autentificarse utilizando el protocolo especificado. Si una implementación recibe un Ack de Configuración con esta Opción de Configuración debe esperar que el extremo se autentifique con el Perkins & Hobby [Pág. 7] RFC 1172 Opciones Iniciales PPP Julio 1990 protocolo especificado. No hay requisitos específicos sobre si la autentificación tiene que ser en ambos sentidos o sobre si ambos extremos deben utilizar el mismo protocolo de autentificación. Es completamente aceptable que cada extremo del enlace utilice un protocolo de autentificación diferente. Esto dependerá, por supuesto, del protocolo de autentificación negociado. Este documento define un sencillo Protocolo de Autentificación de Contraseña en la Sección 4. Se anima al desarrollo de otros protocolos más seguros. Debajo se muestra un esquema del formato de la Opción de Configuración Método de Autentificación. Los campos se trasmiten de izquierda a derecha. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tipo | Longitud | Método de Autentificación | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Datos ... +-+-+-+-+ Tipo 3 Longitud >= 4 Método de Autentificación El campo Método de Autentificación ocupa dos octetos e indica el protocolo de autentificación deseado. Los valores del Método de Autentificación coinciden siempre con los valores del campo Protocolo PPP de la capa de Enlace de Datos para ese mismo protocolo de autentificación. Los valores actualizados para el campo Tipo de Autentificación se especifican en "Números Asignados" [2]. Los valores iniciales están asignados de la siguiente manera : Valor (en hex) Protocolo c023 Protocolo de Autentificación de Contraseña. Perkins & Hobby [Pág. 8] RFC 1172 Opciones Iniciales PPP Julio 1990 Datos El campo Datos ocupa cero o más octetos y contiene datos adicionales que varían según el protocolo de autentificación elegido. Por defecto No es necesario el uso de ningún protocolo de autentificación. 2.4. Número Mágico Descripción Esta Opción de Configuración proporciona una forma de detectar acoples internos y otras anomalías en el nivel de enlace, y puede ser requerida por otra Opción de Configuración, como por ejemplo la Opción de Configuración Monitorización de la Calidad del Enlace. Antes de que se solicite la Opción de Configuración Número Mágico, la implementación debe escoger su Número Mágico. Se recomienda que éste sea escogido lo más aleatoriamente posible para garantizar con una alta probabilidad que la implementación obtenga un número único. Una buena forma de elegir un número aleatorio único es comenzar con una semilla única. Las fuentes de unicidad sugeridas incluyen números de serie, direcciones físicas de hardware de red, relojes, etc. Las mediciones de tiempo que transcurre entre eventos físicos tales como la recepción de paquetes en redes anexas, tiempo de respuesta de un servidor, o la velocidad de escritura de un usuario son semillas aleatorias especialmente buenas. También se recomienda utilizar tantas fuentes aleatorias simultáneamente como sea posible. Cuando se recibe una Petición de Configuración con una Opción de Configuración Número Mágico, el Número Mágico recibido debería ser comparado con el Número Mágico de la última Petición de Configuración enviada al extremo. Si los dos Números Mágicos son diferentes no existe acople interno y por lo tanto el Número Mágico debería ser reconocido. En el caso de que sean iguales, es posible, pero no con total seguridad, que exista un acople interno y que la Petición de Configuración recibida sea realmente la Petición de Configuración enviada anteriormente. Para determinar esto, debería enviarse un Nak de Configuración con un Número Mágico diferente. No debería enviarse al extremo otra Petición de Configuración hasta que el desarrollo normal de la comunicación produjese dicha acción (por ejemplo, hasta que se Perkins & Hobby [Pág. 9] RFC 1172 Opciones Iniciales PPP Julio 1990 reciba un Nak de Configuración o cuando el reloj de Reinicio termine). La recepción de un Nak de Configuración con un Número Mágico diferente del que tenía el último Nak de Configuración enviado al extremo prueba que el enlace no es un acople interno e indica que el Número Mágico es único. Si el Número Mágico es igual al enviado en el último Nak de Configuración aumenta la posibilidad de un acople interno, y debería escogerse otro Número Mágico. En ambos casos debería enviarse una nueva Petición de Configuración con el nuevo Número Mágico obtenido. Si el acople interno continúa, dicho bucle (enviar Petición de Configuración, recibir Petición de Configuración, enviar Nak de Configuración, recibir Nak de Configuración) se repetirá una y otra vez. Si el enlace no es un acople interno, esta secuencia puede llegar a ocurrir unas pocas veces, pero es extremedamente improbable que ocurra repetidamente. Lo más probable es que los Números Mágicos elegidos por cada extremo diverjan rápidamente, terminando el bucle. La siguiente tabla muestra la probabilidad de colisión suponiendo que ambos extremos del enlace eligen Números Mágicos con una distribución completamente uniforme. Número de Colisiones Probabilidad -------------------- -------------------- 1 1/2**32 = 2.3 E-10 2 1/2**32*2 = 5.4 E-20 3 1/2**32*3 = 1.3 E-29 Para que esta divergencia se produzca se necesitan buenas fuentes de aleatoriedad o unicidad. Si no se puede encontrar una buena fuente de unicidad se recomienda que esta Opción de Configuración no se active; si esto ocurre no se enviarán Peticiones de Configuración con esta Opción y cualquier Opción de Configuración Número Mágico que el extremo envíe deberá ser reconocida o rechazada. En este caso, los acoples internos no pueden ser detectados con fiabilidad por la implementación aunque el extremo si puede detectarlos. Si una implementación envía una Petición de Configuración con una Opción de Configuración Número Mágico, NO DEBE responder con una Negativa de Configuración si el extremo también envía una Petición de Configuración Número Mágico. Esto significa que si una implementación desea usar Números Mágicos DEBE permitir que el extremo también los use. Si recibe una Negativa de Configuración como respuesta a una Petición de Configuración sólo puede significar que el enlace no es un acople interno, y que el extremo no utilizará Números Mágicos. En este caso la Perkins & Hobby [Pág. 10] RFC 1172 Opciones Iniciales PPP Julio 1990 implementación puede actuar como si la negociación hubiera sido satisfactoria (como si hubiera recibido un Ack de Configuración). El Número Mágico también puede ser utilizado para detectar acoples internos durante operaciones normales así como durante la negociación de las Opciones de Configuración. Todas las Peticiones de Eco, Respuestas de Eco, Peticiones de Descarte y paquetes LCP de Informe de la Calidad del Enlace poseen un campo Número Mágico que, en condiciones normales, DEBE ser enviado a cero y DEBE ser ignorado en la recepción. Sin embargo, una vez que el Número Mágico ha sido negociado satisfactoriamente, la implementación LCP DEBE comenzar a transmitir esos paquetes con el Número Mágico negociado. Adicionalmente, es posible que el campo Número Mágico de esos paquetes sea inspeccionado en la recepción. Todos los campos Número Mágico recibidos deben ser iguales a cero o al Número Mágico del extremo, dependiendo de si el extremo negoció uno o no. La recepción de un Número Mágico igual al Número Mágico local indica un acople interno. La recepción de un Número Mágico distinto del local, del Número Mágico del extremo o distinto de cero si no se negoció ninguno, indica que el enlace fue (mal) configurado para comunicarse con otro extremo diferente. Los procedimientos para recuperarse de ambos casos no se especifican y pueden variar de una implementación a otra. Un método un poco pesimista es suponer que el LCP ha sufrido una caída a Nivel Físico y cortar la comunicación. Una posterior conexión iniciará de nuevo el proceso de establecer el enlace, el cual no puede completarse hasta que haya desaparecido el enlace interno y los Números Mágicos se hayan negociado satisfactoriamente. Un procedimiento más optimista (en el caso de un enlace interno) es comenzar a transmitir paquetes LCP de Petición de Eco hasta que se reciba una Respuesta de Eco apropiada, lo cual indica que el acople interno ha desaparecido. Debajo se muestra un esquema del formato de la Opción de Configuración Número Mágico. Los campos se transmiten de izquierda a derecha. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tipo | Longitud | Número Mágico +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Número Mágico (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Perkins & Hobby [Pág. 11] RFC 1172 Opciones Iniciales PPP Julio 1990 Tipo 5 Longitud 6 Número Mágico El campo Número Mágico ocupa cuatro octetos y contiene un número que se aproxima mucho a ser único para uno de los extremos del enlace. Un Número Mágico igual a cero es ilegal y no debería ser enviado. Por defecto Ninguno. Perkins & Hobby [Pág. 12] RFC 1172 Opciones Iniciales PPP Julio 1990 2.5. Monitarización de la Calidad del Enlace Descripción En algunos enlaces puede ser necesario determinar cuando, y cada cuanto tiempo, el enlace pierde datos. Este proceso se denomina Monitorización de la Calidad del Enlace y se realiza transmitiendo periódicamente paquetes de Informe de la Calidad del Enlace tal y como se describe en la Sección 3. La Opción de Configuración Monitorización de la Calidad del Enlace permite activar el uso de los paquetes de Informe de la Calidad del Enlace y también negociar el ratio con el que son transmitidos. Por defecto, la Monitorización de la Calidad del Enlace y los paquetes de Informe de la Calidad del Enlace están desactivados. Debajo se muestra un esquema del formato de la Opción de Configuración Monitorización de la Calidad del Enlace. Los campos se transmiten de izquierda a derecha. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tipo | Longitud | Periodo de Informe +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Periodo de Informe (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tipo 6 Longitud 6 Periodo de Informe El campo Periodo de Informe ocupa cuatro octetos e indica el tiempo máximo en microsegundos que el extremo debería esperar entre cada transmisión de paquetes LCP de Informe de la Calidad del Enlace. El valor cero es ilegal y siempre debería ser desechado o rechazado. La implementación LCP siempre es libre de transmitir paquetes LCP de Informe de la Calidad del Enlace con una frecuencia mayor que la solicitada y confirmada por el extremo. Por Defecto Perkins & Hobby [Pág. 13] RFC 1172 Opciones Iniciales PPP Julio 1990 Ninguno 2.6. Compresión del Campo Protocolo Descripción Esta Opcion de Configuración proporciona una forma de negociar la compresión del campo Protocolo del Nivel de Enlace. Por defecto, todas las implementaciones deben transmitir tramas PPP estándar con un campo Protocolo con una longitud de dos octetos. Sin embargo, la forma en que se eligen los números del campo Protocolo hace que algunos valores se puedan comprimir en un solo octeto y que además éstos sean claramente distinguibles de los que están almacenados en dos octetos. Esta Opción de Configuración puede ser enviada para informar al extremo de que puede recibir campos Protocolo comprimidos en un solo octeto. Los campos Protocolo no se enviarán comprimidos a menos que esta Opción de Configuración haya sido recibida. Como ya se mencionó anteriormente, el campo Protocolo utiliza un mecanismo de extensión compatible con el mecanismo de extensión ISO 3309 para el campo Dirección; el bit menos significativo (LSB) de cada octeto se utiliza para indicar la extensión del campo Protocolo. Un LSB igual a cero indica que el campo Protocolo continúa en el siguiente octeto. Un LSB igual a uno indica que el octeto es el último octeto del campo Protocolo. Se pueden añadir octetos vacíos al campo y éste seguirá indicando el mismo valor (considerense las dos representaciones del 3, 00000011 y 00000000 00000011). Para simplificar, la trama PPP estándar utiliza esta característica y el campo Protocolo siempre se envía representado en dos octetos. Los campos Protocolo cuyo valor sea menor que 256 (decimal) son rellenados con un octeto vacío, incluso cuando la transmisión de éste, el octeto más significativo y que además está vacío, es innecesaria. Sin embargo, cuando se utilizan enlaces de baja velocidad, se desea conservar el ancho de banda enviando la menor cantidad de datos redundantes posibles. La Opción de Configuración Compresión del campo Protocolo permite un compromiso entre la sencillez de implementación y la eficiencia de ancho de banda. Si se negocia satisfactoriamente, el mecanismo de extensión ISO 3309 puede ser utilizado para comprimir el campo Protocolo en un octeto en lugar de en dos. La gran mayoría de las tramas son comprimibles ya que los valores asignados al campo Protocolo suelen ser menores que 256. Perkins & Hobby [Pág. 14] RFC 1172 Opciones Iniciales PPP Julio 1990 Para garantizar que no existe ambigüedad al reconocer los paquetes LCP, éstos nunca deben tener el campo Protocolo comprimido. Además, las implementaciones PPP deben seguir siendo robustas, DEBEN aceptar tramas PPP con campos Protocolo que ocupen tanto dos octetos como uno sólo y NO DEBEN hacer distinciones entre ambos. Cuando se comprime un campo Protocolo, el campo FCS del Nivel de Enlace se calcula sobre la trama comprimida, no sobre la trama original sin comprimir. Debajo se muestra un esquema del formato de la Opción de Configuración Compresión del Campo Protocolo. Los campos se transmiten de izquierda a derecha. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tipo | Longitud | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tipo 7 Longitud 2 Por defecto Desactivada. Perkins & Hobby [Pág. 15] RFC 1172 Opciones Iniciales PPP Julio 1990 2.7. Compresión de los Campos Dirección y Control Descripción Esta Opción de Configuración proporciona una forma de negociar la compresión de los campos Dirección y Control del Nivel de Enlace. Por defecto, todas las implementaciones deben transmitir tramas con campos Dirección y Control y deben asignarles los valores hexadecimales 0xff y 0x03 respectivamente. Estos campos tienen valores constantes por lo que se pueden comprimir fácilmente. Esta Opción de Configuración puede ser utilizada para informar al extremo de que puede recibir los campos Control y Dirección comprimidos. Los campos Control y Dirección comprimidos se construyen simplemente omitiéndolos en los casos en los que no hay ambigüedad. Las tramas ambiguas pueden no estar comprimidas. En dichas tramas los dos octetos que van a continuación de los campos Dirección y Control tienen valores que pueden interpretarse como campos Dirección y Control válidos (por ejemplo, 0xff, 0x03). Esto puede ocurrir cuando está activada la Compresión del Campo Protocolo y éste está comprimido en un octeto. Si el valor del campo Protocolo es 0xff y el primer octeto del campo Información es 0x03, el resultado es ambiguo y los campos Dirección y Control no deberían comprimirse en la transmisión. En la recepción, los campos Dirección y Control se descomprimen examinando los dos primeros octetos. Si contienen los valores 0xff y 0x03 se considera que son los campos Dirección y Control. Si no es así se considera que los campos se comprimieron y no se enviaron. Un caso adicional en el que los campos Dirección y Control nunca deben comprimirse es cuando se envían paquetes LCP. Esta norma garantiza el reconocimiento de los mismos sin ambigüedades. Cuando los campos Dirección y Control están comprimidos, el campo FCS del Nivel de Enlace se calcula sobre la trama comprimida, no sobre la trama original sin comprimir. Debajo se muestra un esquema del formato de la Opción de Configuración Compresión de los campos Dirección y Control. Los campos se transmiten de izquierda a derecha. Perkins & Hobby [Pág. 16] RFC 1172 Opciones Iniciales PPP Julio 1990 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tipo | Longitud | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tipo 8 Longitud 2 Por defecto Sin comprimir. Perkins & Hobby [Pág. 17] RFC 1172 Opciones Iniciales PPP Julio 1990 3. Monitorización de la Calidad del Enlace La transmisión de datos a través de un enlace raramente es perfecta. Los paquetes pueden perderse o corromperse por diferentes motivos (ruido en la línea, fallo del equipo, falta de búfer, etc). Algunas veces se desea determinar cuando, y cada cuanto, el enlace pierde datos. Los encaminadores, por ejemplo, pueden dar preferencia temporalmente a otros encaminadores. Una implementación puede tener la opción de desconectarse y conectarse a un enlace alternativo. El proceso de medir la pérdida de datos se denomina "Monitorización de la Calidad del Enlace". 3.1 Motivos de diseño Existen diferentes maneras de medir la calidad de un enlace, y muchas otras de responder ante ella. En lugar de especificar un modelo, la Monitorización de la Calidad del Enlace está dividida en un "mecanismo" y una "política". PPP especifica el mecanismo de la Monitorización de la Calidad del Enlace definiendo el paquete LCP de Informe de la Calidad del Enlace (LQR, Link-Quality-Report) y especificando cómo utilizarlo. PPP NO especifica una "política" de Monitorización de la Calidad del Enlace (cómo juzgar la calidad del enlace o qué hacer cuando ésta es inadecuada). Estas decisiones se dejan a la implementación y pueden ser diferentes en cada extremo del enlace. Se permite, e incluso se sugiere, que las implementaciones experimenten con diferentes políticas de calidad de enlace. Las especificaciones del mecanismo de la Monitorización de la Calidad del Enlace aseguran que dos implementaciones con políticas diferentes puedan comunicarse e interoperar. Para permitir la implementación de políticas flexibles, el mecanismo PPP de la Monitorización de la Calidad del Enlace mide los datos perdidos en unidades de paquetes, octetos, e Informes de la Calidad del Enlace. Cada extremo del enlace realiza las mediciones por separado, tanto de recepción como de transmisión. Los extremos del enlace intercambian las mediciones de forma que cada uno pueda implementar su propia política de calidad del enlace, tanto para la transmisión como para la recepción. Finalmente, el protocolo de Monitorización de la Calidad del Enlace está diseñado para ser implementado en diferentes tipos de sistemas. Además de que es posible implementar PPP (y especialmente la Monitorización de la Calidad del Enlace) como un proceso individual mediante software, se ha previsto la posible implementación multi- proceso mediante hardware. El mecanismo PPP de la Monitorización de la Calidad del Enlace proporciona para esto una descripción detallada del formato de los paquetes de Informe de la Calidad del Enlace, y especifica puntos de referencia para todas las mediciones Perkins & Hobby [Pág. 18] RFC 1172 Opciones Iniciales PPP Julio 1990 de transmisión y recepción de datos. 3.2. Descripción del diseño Cada implementación de la Monitorización de la Calidad del Enlace mantiene la cuenta del número de paquetes y octetos transmitidos y recibidos satisfactoriamente, y periódicamente transmite esta información al otro extremo dentro de un paquete de Informe de la Calidad del Enlace. Estos paquetes contienen tres secciones: una sección de Cabecera, una sección de Contadores, y una sección de Mediciones. La sección de cabecera consiste en la cabecera normal de los paquetes LCP de Mantenimiento del Enlace incluyendo los campos de Código, Identificador, Longitud y Número Mágico. La sección de Contadores está formada por cuatro contadores, y proporciona la información necesaria para medir la calidad del enlace. El remitente LQR mantiene dos de estos contadores: Out-Tx- Packets-Ctr y Out-Tx-Octets-Ctr (descritos más adelante). El receptor LQR mantiene los dos contadores restantes : In-Rx-Packets- Ctr e In-Rx-Octets-Ctr (descritos más adelante). Estos contadores son similares a una secuencia de números; se incrementan constantemente para dar una indicación relativa del número de paquetes y octetos enviados a través del enlace de salida. Comparando los valores en sucesivos paquetes de Informe de la Calidad del Enlace, el receptor LQR puede calcular el número absoluto de paquetes y octetos recibidos a través del enlace de entrada. Comparando estos números absolutos se obtiene una estimación de la calidad del enlace de entrada. Se transmiten números relativos en lugar de números absolutos porque simplifican significativamente la sincronización del enlace; una implementación se limita a esperar a recibir dos paquetes LQR. La sección de Mediciones consiste en seis variables de estado: In- Tx-LQR, Last-In-Id, In-Tx-Packets, In-Tx-Octets,In-Rx-Packets, e In- Rx-Octets (descritas más adelante). Esta sección permite que la implementación informe de las mediciones de la calidad del enlace, realizadas en su enlace de entrada, al otro extremo (para éste, el informe indicará la calidad del enlace de salida) transmitiendo el número absoluto, en lugar del número relativo, de LQR, paquetes, y octetos que han sido recibidos. Estos valores se calculan observando la sección de Contadores de los paquetes de Informe de la Calidad del Enlace recibidos en el enlace de entrada. Los números absolutos pueden ser utilizados en esta sección sin que existan problemas de sincronización porque sólo es necesario recibir un paquete LQR para obtener información válida. Perkins & Hobby [Pág. 19] RFC 1172 Opciones Iniciales PPP Julio 1990 La Monitorización de la Calidad del Enlace está descrita con más detalle en las siguientes secciones. Primero, se presenta una descripción de los procesos incluyendo el mecanismo de la Monitorización de la Calidad del Enlace. Después, los procesos que mantienen los contadores de paquetes y octetos; las mediciones, cálculos, y variables de estado utilizadas; el formato de los paquetes de Informe de la Calidad del Enlace; algunas políticas de actuación sugeridas y, finalmente, un ejemplo de cómo calcular la calidad del enlace. 3.3. Procesos El mecanismo PPP de la Monitorización de la Calidad del Enlace se describe utilizando un modelo de "proceso lógico". Tal y como se muestra debajo, existen cinco procesos lógicos duplicados en cada extremo del enlace. +---------+ +-------+ +----+ Salida | |-->| Mux |-->| Tx |===========> | Adminis-| +-------+ +----+ | trador | | de | | Enlace | +-------+ +----+ Entrada | |<--| Demux |<--| Rx |<=========== +---------+ +-------+ +----+ Administrador de Enlace El proceso Administrador de Enlace transmite y recibe Informes de la Calidad del Enlace e implementa la política de calidad del enlace deseada. Los paquetes LQR son transmitidos a un ritmo constante que se negocia mediante la Opción de Configuración LCP Monitorización de la Calidad del Enlace. El proceso Administrador de Enlace solamente mantiene las secciones de Cabecera y de Mediciones del paquete; la sección de Contadores es mantenida por los procesos Tx y Rx. Mux El proceso Mux multiplexa paquetes de varios protocolos (por ejemplo, LCP, IP, XNS, etc) en una secuencia individual y prioritaria de paquetes. Los paquetes de Informe de la Calidad del Enlace DEBEN tener la máxima prioridad posible para asegurar que la información sobre la calidad del enlace se comunica en el menor tiempo posible. Tx Perkins & Hobby [Pág. 20] RFC 1172 Opciones Iniciales PPP Julio 1990 El proceso Tx mantiene los contadores Out-Tx-Packets-Ctr y Out- Tx-Octets-Ctr que son utilizados para medir la cantidad de datos que es enviada por el enlace de salida. Cuando Tx procesa un paquete de Informe de la Calidad del Enlace, inserta el valor de estos contadores en la sección de Contadores del paquete. Debido a que estos contadores representan valores relativos en lugar de valores absolutos, la decisión de cuando actualizarlos, antes o después de que sean insertados en el paquete de Informe de la Calidad del Enlace, se deja a la elección de la propia implementación. Sin embargo, ésta DEBE tomar la misma decisión cada vez que se le presente esta cuestión. El proceso Tx DEBE ir después del proceso Mux de forma que los paquetes se contabilicen en el orden en que son enviados al enlace. Rx El proceso Rx mantiene los contadores In-Rx-Packets-Ctr e In-Rx- Octets-Ctr, que son utilizados para medir la cantidad de datos que se recibe por el enlace de entrada. Cuando Rx procesa un paquete de Informe de la Calidad del Enlace inserta los valores de estos contadores en la sección de Contadores del paquete. De nuevo, la decisión de cuando actualizar los contadores, antes o después de que sean insertados en el paquete de Informe de la Calidad del Enlace, se deja a la elección de la implementación, y ésta DEBE tomar la misma decisión cada vez que tenga que elegir entre estas dos opciones. Demux El proceso Demux desmultiplexa los paquetes de diferentes protocolos. Este proceso DEBE ir a continuación del proceso Rx de forma que los paquetes sean contabilizados en el orden en el que se reciben del enlace. 3.4. Contadores Para poder rellenar la sección de Contadores de los paquetes de Informe de la Calidad del Enlace, la Monitorización de la Calidad del Enlace necesita utilizar un contador sin signo de 8 bits, y otros cuatro de 32 bits que se incrementan al unísono. Estos contadores pueden ser inicializados a cualquier valor antes de que el primer Informe de la Calidad del Enlace se transmita, pero NO DEBEN ser reiniciados de nuevo hasta que el último paquete LCP haya sido enviado. Los contadores vuelven a cero cuando alcanzan su valor máximo (para contadores de 32 bits: 0xffffffff + 1 = 0). Out-Identifier-Ctr (contador de paquetes LQR enviados) Perkins & Hobby [Pág. 21] RFC 1172 Opciones Iniciales PPP Julio 1990 Out-Identifier-Ctr es un contador de 8 bits mantenido por el proceso Administrador de Enlace. Éste incrementa Out-Identifier- Ctr en uno por cada paquete de Informe de la Calidad del Enlace enviado. Out-Tx-Packets-Ctr (contador de paquetes enviados) Out-Tx-Packets-Ctr es un contador de 32 bits mantenido por el proceso Tx. Éste incrementa Out-Tx-Packets-Ctr en uno por cada paquete del Nivel de Enlace enviado. Out-Tx-Octets-Ctr (contador de octetos enviados) Out-Tx-Octets-Ctr es un contador de 32 bits mantenido por el proceso Tx. Éste incrementa Out-Tx-Octets-Ctr en uno por cada octeto de cada paquete del Nivel de Enlace transmitido. Todos los octetos que se incluyan en el cálculo FCS DEBEN ser contabilizados por el contador Out-Tx-Octets-Ctr, así como los propios octetos del FCS. NO SE DEBEN tener en cuenta los demás octetos. In-Rx-Packets-Ctr (contador de paquetes recibidos) In-Rx-Packets-Ctr es un contador de 32 bits mantenido por el proceso Rx. Éste incrementa In-Rx-Packets-Ctr en uno por cada paquete del nivel de Enlace de Datos recibido satisfactoriamente. Los paquetes con campos FCS incorrectos u otros problemas NO DEBEN contabilizarse. In-Rx-Octets-Ctr (contador de octetos recibidos) In-Rx-Octets-Ctr es un contador de 32 bits mantenido por el proceso Rx. Éste incrementa In-Rx-Octets-Ctr en uno por cada octeto de cada paquete del Nivel de Enlace recibido satisfactoriamente. Todos los octetos que están incluidos en el cálculo FCS DEBEN contabilizarse, asi como los propios octetos del FCS. Todos los demás octetos NO DEBEN contabilizarse. 3.5. Mediciones, Cálculos, Variables de Estado Para poder rellenar la sección de Mediciones de los paquetes de Informe de la Calidad del Enlace, la Monitorización de la Calidad del Enlace necesita el proceso Administrador de Enlace para realizar una serie de cálculos y mantener variables de estado. Estos cálculos se realizan, y las variables se actualizan, cada vez que se recibe un paquete de Informe de la Calidad del Enlace a través del enlace de entrada. Perkins & Hobby [Pág. 22] RFC 1172 Opciones Iniciales PPP Julio 1990 In-Tx-LQRs In-Tx-LQRs es una variable de estado de 8 bits que indica el número de paquetes de Informe de la Calidad del Enlace que el extremo tiene que enviar para que la implementación local reciba uno. In-Tx-LQRs define la longitud del periodo en el que fueron medidos In-Tx-Packets, In-Tx-Octets, In-Rx-Packets, e In-Rx- Octets. In-Tx-LQRs se calcula sustrayendo el valor de Last-In-Id del Identificador recibido. Si se pierden más de 255 LQR, In-Tx- LQRs tendrá un valor ambiguo ya que el campo Identificador y todas las variables de estado relacionadas con él son sólo de 8 bits. Se considera que la política de Monitorización de la Calidad del Enlace será lo suficientemente robusta para hacer frente a esta situación (probablemente cortaría el enlace mucho antes de que esto llegase a ocurrir). Last-In-Id Last-In-Id es una variable de estado de 8 bits que almacena el valor del último Identificador recibido. Last-In-Id debería ser actualizada después de que In-Tx-LQRs haya sido calculada. In-Tx-Packets In-Tx-Packets es una variable de estado de 32 bits que indica el número de paquetes que fueron enviados a través del enlace de entrada durante el último periodo. In-Tx-Packets se calcula sustrayendo el valor de Last-Out-Tx-Packets del valor Out-Tx- Packets-Ctr recibido. Last-Out-Packets-Ctr Last-Out-Packets-Ctr es una variable de estado de 32 bits que almacena el valor del último Out-Tx-Packets-Ctr recibido. Last-Out-Packets-Ctr debería actualizarse después de que la variable In-Tx-Packets haya sido calculada. In-Tx-Octets In-Tx-Octets es una variable de estado de 32 bits que indica el número de octetos que se han enviado a través del enlace de entrada durante el último periodo. In-Tx-Octets se calcula sustrayendo el valor de Last-Out-Tx-Octets del Out-Tx-Octets-Ctr recibido. Last-Out-Tx-Octets-Ctr Perkins & Hobby [Pág. 23] RFC 1172 Opciones Iniciales PPP Julio 1990 Last-Out-Tx-Octets es una variable de estado de 32 bits que almacena el valor del último Out-Tx-Octets-Ctr recibido. Debería actualizarse después de que In-Tx-Octets haya sido calculada. In-Rx-Packets In-Rx-Packets es una variable de estado de 32 bits que indica el número de paquetes que fueron recibidos a través del enlace de entrada durante el último periodo. In-Rx-Packets se calcula sustrayendo el valor de Last-In-Rx-Packets del In-Rx-Packets-Ctr recibido. Last-In-Rx-Packets-Ctr Last-In-Rx-Packets-Ctr es una variable de estado de 32 bits que almacena el valor del último In-Rx-Packets-Ctr recibido. Last-In- Rx-Packets-Ctr debería ser actualizada después de que In-Rx- Packets haya sido calculada. In-Rx-Octets In-Rx-Octets es una variable de estado de 32 bits que almacena el número de octetos que fueron recibidos en el enlace de entrada durante el último periodo. In-Rx-Octets se calcula sustrayendo Last-In-Rx-Octets-Ctr del In-Rx-Octets-Ctr recibido. Last-In-Rx-Octets-Ctr Last-In-Rx-Octets-Ctr es una variable de estado del 32 bits que almacena el valor del último In-Rx-Octets-Ctr recibido. Debería ser actualizada después de que In-Rx-Octets haya sido calculada. Validación de las Mediciones Validación de las Mediciones es una variable de estado booleana de 1 bit que indica si las variables de estado In-Tx-Packets, In- Tx-Octets, In-Rx-Packets e In-Rx-Octets contienen mediciones válidas. Estas mediciones no pueden ser consideradas como válidas hasta que dos o más paquetes de Informe de la Calidad del Enlace hayan sido recibidos en el enlace de entrada. Este bit debe ponerse a cero cuando LCP inicie la conexión, y ponerse a uno tras la recepción de dos LQR exactamente. 3.6. Formato de los Paquetes de Informe de la Calidad del Enlace Debajo se muestra un esquema del formato de los paquetes de Informe de la Calidad del Enlace. Los campos se transmiten de izquierda a derecha. Los campos Código, Identificador, Longitud y Número Mágico Perkins & Hobby [Pág. 24] RFC 1172 Opciones Iniciales PPP Julio 1990 forman la cabecera de un paquete LCP normal de Mantenimiento del Enlace; los campos In-Tx-LQRs, Last-In-Id, V, In-Tx-Packets, In-Tx- Octets, In-Rx-Packets e In-Rx-Octets contienen mediciones absolutas resumidas; y los campos Out-Tx-Packets-Ctr, Out-Tx-Octets-Ctr, In- Rx-Packets-Ctr e In-Rx-Octets-Ctr contienen cuentas relativas sin procesar. Hay que destacar que el formato de este paquete no incluye los campos In-Rx-Packets-Ctr e In-Rx-Octets-Ctr al ser transmitido a través del enlace. Dichos campos serán por lógica añadidos por el proceso Rx después de la recepción en el enlace de entrada. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Código | Identificador | Longitud | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Número Mágico | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In-Tx-LQRs | Last-In-Id | Reservado |V| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In-Tx-Packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In-Tx-Octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In-Rx-Packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In-Rx-Octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Out-Tx-Packets-Ctr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Out-Tx-Octets-Ctr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In-Rx-Packets-Ctr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In-Rx-Octets-Ctr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Código 12 para Informe de la Calidad del Enlace. Identificador El campo Identificador ocupa un octeto e indica el número de secuencia de este Informe de la Calidad del Enlace. El campo Perkins & Hobby [Pág. 25] RFC 1172 Opciones Iniciales PPP Julio 1990 Identificador se copia del contador Out-Identifier-Ctr en el momento de la transmisión. En la recepción, el campo Identificador se utiliza para calcular In-Tx-LQRs y después se almacena en Last-In-Id. El espacio de números de secuencia del Identificador de Informe de la Calidad del Enlace DEBE estar separado de la contabilización de los demás paquetes LCP; por ejemplo, la transmisión de una Petición de Eco LCP no debe hacer que el contador Out-Identifier-Ctr se incremente. Longitud El campo Longitud está formado por dos octetos e indica la longitud del paquete LQR incluyendo los campos Código, Identificador, Longitud y todos los demás campos definidos. Los octetos que estén fuera del rango del campo Longitud deberán ser tratados como relleno del Nivel de Enlace y deberían ser ignorados en la recepción. Para poder calcular los valores correctos de In-Tx-Octets e In-Rx-Octets, los Informes de Calidad del Enlace DEBEN ser transmitidos de forma consistente con la misma cantidad de relleno. Número Mágico El campo Número Mágico ocupa cuatro octetos y ayuda a detectar acoples internos. A menos que una Opción de Configuración lo modifique, el campo Número Mágico siempre se transmitirá a cero y DEBERÁ ser ignorado en la recepción. Si se ha negociado el uso de Números Mágicos, los paquetes LQR entrantes deberían comprobarse para asegurarse de que el extremo local no está viendo sus propios Números Mágicos y se está produciendo un acople interno. In-Tx-LQRs El campo In-Tx-LQRs ocupa un octeto e indica el número de periodos cubiertos por la sección de Mediciones de este paquete de Informe de la Calidad del Enlace. El campo In-Tx-LQRs se copia de la variable de estado In-Tx-LQRs en el momento de la transmisión. Last-In-Id El campo Prev-In-Id ocupa un octeto e indica la edad de la sección de Mediciones de este paquete de Informe de la Calidad del Enlace. El campo Last-In-Id se copia del campo Last-In-Id durante la transmisión. En la recepción, el campo Last-In-Id puede compararse con Out-Identifier-Ctr para determinar cuantos Perkins & Hobby [Pág. 26] RFC 1172 Opciones Iniciales PPP Julio 1990 Informes de Calidad del Enlace de salida se han perdido, si es que se ha perdido alguno. V El campo V ocupa 1 bit e indica si la sección de Mediciones de este paquete de Informe de la Calidad del Enlace es válida. El campo V se copia de la variable de estado Validación de Mediciones en el momento de la transmisión. Si el campo V no está a 1, los campos In-Tx-LQRs, Last-In-Id, In-Tx-Packets, In-Tx- Octets, In-Rx-Packets e In-Rx-Octets serán ignorados. Reservado El campo Reservado ocupa 15 bits y está pensado para rellenar el resto de los campos del paquete hasta alcanzar un múltiplo de cuatro octetos, establecido para facilitar las implementaciones mediante hardware. El campo Reservado siempre debería ser transmitido a cero e ignorado en la recepción. In-Tx-Packets El campo In-Tx-Packets ocupa cuatro octetos e indica el número de paquetes enviados a través del enlace de entrada del emisor del paquete de Informe de la Calidad del Enlace durante el último periodo medido. El campo In-Tx-Packets se copia de la variable de estado In-Tx-Packets en el momento de la transmisión. In-Tx-Octets El campo In-Tx-Octets ocupa cuatro octetos e indica el número de octetos enviados a través del enlace de entrada del emisor del paquete de Informe de la Calidad del Enlace durante el último periodo medido. El campo In-Tx-Octets se copia de la variable de estado In-Tx-Octets en el momento de la transmisión. In-Rx-Packets El campo In-Rx-Packets ocupa cuatro octetos e indica el número de paquetes recibidos en el enlace de entrada del emisor del paquete de Informe de la Calidad del Enlace durante el último periodo medido. El campo In-Rx-Packets se copia de la variable de estado In-Rx-Packets en el momento de la transmisión. In-Rx-Octets El campo In-Rx-Octets ocupa cuatro octetos e indica el número de octetos recibidos en el enlace de entrada del emisor del paquete Perkins & Hobby [Pág. 27] RFC 1172 Opciones Iniciales PPP Julio 1990 de Informe de la Calidad del Enlace durante el último periodo medido. El campo In-Rx-Octets se copia de la variable de estado In-Rx-Octets en el momento de la transmisión. Out-Tx-Packets El campo Out-Tx-Packets ocupa cuatro octetos y se utiliza para calcular el número de paquetes enviados a través del enlace de salida del emisor del paquete de Informe de la Calidad del Enlace durante un determinado periodo. El campo Out-Tx-Packet se copia del contador Out-Tx-Packets-Ctr en el momento de la transmisión. Out-Tx-Octets El campo Out-Tx-Octets ocupa cuatro octetos y se utiliza para calcular el número de octetos enviados a través del enlace de salida del emisor del paquete de Informe de la Calidad del Enlace durante un determinado periodo. El campo Out-Tx-Octets se copia del contador Out-Tx-Octets-Ctr en el momento de la transmisión. In-Rx-Packets El campo In-Rx-Packets ocupa cuatro octetos y se utiliza para calcular el número de paquetes recibidos en el enlace de entrada del receptor del paquete de Informe de la Calidad del Enlace durante un determinado periodo. El campo In-Rx-Packets se copia del contador In-Rx-Packets-Ctr en el momento de la recepción. El campo In-Rx-Packets no se muestra porque realmente no se transmite por el enlace, ya que se añade lógicamente (la forma en que se hace depende de la implementación) al paquete mediante el proceso Rx de la propia implementación. In-Rx-Octets El campo In-Rx-Octets está formado por cuatro octetos y se utiliza para calcular el número de octetos recibidos en el enlace de entrada del receptor del Informe de la Calidad del Enlace durante un determinado periodo. El campo In-Rx-Octets se copia del contador In-Rx-Octets-Ctr en el momento de la recepción. In- Rx-Octets no se muestra porque realmente no se transmite por el enlace, ya que se añade lógicamente (la forma en que se hace depende de la implementación) al paquete a través del proceso Rx de la propia implementación. 3.7. Sugerencias de Actuación Los paquetes de Informe de la Calidad del Enlace proporcionan un mecanismo para determinar la calidad del enlace, pero determinar si Perkins & Hobby [Pág. 28] RFC 1172 Opciones Iniciales PPP Julio 1990 éste se puede utilizar o no es decisión de la propia implementación. Se recomienda que la política utilizada sea lo suficientemente previsora para evitar que la calidad del enlace oscile constantemente. Una política especialmente buena es utilizar un algoritmo del tipo 'K de N' . En este algoritmo deberá haber K periodos con éxito de los últimos N, para que la calidad del enlace se pueda considerar satisfactoria. No se especifican los métodos para recuperarse de enlaces de mala calidad y dichos métodos pueden variar de una implementación a otra. Un procedimiento sugerido es cerrar inmediatamente todos los demás protocolos de Nivel de Red (por ejemplo, hacer que IPCP transmita un Terminate-Req), pero continuar enviando paquetes de Informe de la Calidad del Enlace. Una vez que la calidad del enlace alcance un nivel aceptable los protocolos de Nivel de Red podrán ser nuevamente reconfigurados. 3.8. Ejemplo Un ejemplo puede resultar útil. Suponga que el Administrador de Enlace de la implementación A envía un paquete de Informe de la Calidad del Enlace que es recibido por el Administrador de Enlace de la implementación B en el instante t0 con los siguientes valores: Out-Tx-Packets 5 Out-Tx-Octets 100 In-Rx-Packets 3 In-Rx-Octets 70 Suponga que entonces A envía 20 paquetes IP con 200 octetos, y de ellos B recibe 15 paquetes y 150 octetos. En el instante t1, A envía otro LQR que es recibido por B de la siguiente manera: Out-Tx-Packets 26 (5 antiguos, más 20 IP, más 1 LQR) Out-Tx-Octets 342 (42 para LQR) In-Rx-Packets 19 In-Rx-Octets 262 La implementación B puede ahora calcular el número de paquetes y octetos transmitidos, recibidos y perdidos en su enlace de entrada tal y como sigue: In-Tx-Packets = 26 - 5 = 21 In-Tx-Octets = 342 - 100 = 242 In-Rx-Packets = 19 - 3 = 16 In-Rx-Octets = 262 - 70 = 192 In-Lost-Packets = 21 - 16 = 5 In-Lost-Octets = 242 - 192 = 50 Perkins & Hobby [Pág. 29] RFC 1172 Opciones Iniciales PPP Julio 1990 Después de realizar estas operaciones, B evalúa las mediciones de la forma que especifique su implementación. Además, la próxima vez que B envíe un LQR a A, informará de estos valores en la sección de Mediciones, permitiendo de esta forma que A examine estos mismos resultados. Perkins & Hobby [Pág. 30] RFC 1172 Opciones Iniciales PPP Julio 1990 4. Protocolo de Autentificación de Contraseña El Protocolo de Autentificación de Contraseña (PAP, Password Authentication Protocol) puede ser utilizado para autentificar al extremo verificando su identidad. El uso de PAP debe negociarse primero utilizando la Opción de Configuración LCP Método de Autentificación. La negociación satisfactoria añade una fase de autentificación adicional al Protocolo de Control de Enlace, la cual está situada después de la fase de Determinación de la Calidad del Enlace y antes de la fase de Negociación de Configuración del Protocolo de Red. Los paquetes PAP recibidos antes de la fase de autentificación deberían ser descartados silenciosamente. La fase de autentificación termina una vez que se envía o recibe un paquete Ack de Autentificación. Se recomienda el uso de PAP en máquinas y encaminadores que conectan con servidores PPP de red mediante líneas de marcado o circuitos conmutados. El servidor puede entonces utilizar la identificación, de la máquina o el encaminador que está intentando conectar, en las opciones pertenecientes a la negociación de la capa de red, o bien cortar la comunicación en el caso de que la autentificación no sea satisfactoria. Hay que resaltar que PAP no es un método de autentificación especialmente robusto. Las contraseñas se envían a través del enlace en texto plano y no existe protección frente a ataques sucesivos de prueba-error. Actualmente se está trabajando en métodos más seguros para autentificar PPP y otros protocolos. Se recomienda encarecidamente cambiarse a estos métodos en cuanto estén disponibles. 4.1. Formato de los paquetes En el campo de información de las tramas PPP del Nivel de Enlace, donde el campo de protocolo indica c023 (hex) (Protocolo de Autentificación de Contraseña), se encapsula un único paquete de Protocolo de Autentificación de Contraseña. Debajo se muestra un esquema del formato de éste último. Los campos son transmitidos de izquierda a derecha. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Código | Identificador | Longitud | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Datos ... +-+-+-+-+-+ Perkins & Hobby [Pág. 31] RFC 1172 Opciones Iniciales PPP Julio 1990 Código El campo Código ocupa un octeto e indica el tipo de paquete PAP. Los códigos PAP se asignan de la siguiente manera: 1 autentificación 2 Ack de autentificación 3 Nak de autentificación Identificador El campo Identificador ocupa un octeto y ayuda en el emparejamiento de peticiones con sus correspondientes respuestas. Longitud El campo Longitud ocupa dos octetos e indica la longitud del paquete PAP incluyendo los campos Código, Identificador, Longitud y Datos. Los octetos que estén fuera del rango del campo Longitud deben tratarse como relleno del Nivel de Enlace e ignorarse en la recepción. Datos El campo Datos ocupa cero o más octetos. Su formato se determina por el campo Código. Perkins & Hobby [Pág. 32] RFC 1172 Opciones Iniciales PPP Julio 1990 4.2. Autentificación Descripción El paquete de Autentificación se utiliza para comenzar el Protocolo de Autentificación de Contraseña. La implementación, habiendo enviado un paquete Ack de Configuración LCP con una Opción de Configuración Método de Autentificación, y posteriormente especificado el Protocolo de Autentificación de Contraseña, debe enviar un paquete de autentificación durante la fase de autentificación. Si una implementación recibe un Ack de Configuración debería esperar la posibilidad de que el extremo envíe un paquete de autentificación durante esta fase. Un paquete de autentificación se envía con el campo Código a 1 (Autentificar) y los campos Identificador del Extremo (Peer-Id) y Contraseña como se desee. Cuando se recibe un paquete de autentificación, DEBE enviarse algún tipo de respuesta a dicho paquete. Debajo se muestra un esquema del formato de los paquetes de autentificación. Los campos son transmitidos de izquierda a derecha. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Código | Identificador | Longitud | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Long Peer-ID | Peer-ID ... +-+-+-+-+-+-+-+-+-+-+-+ |Long Contraseña| Contraseña ... +-+-+-+-+-+-+-+-+-+-+-+ Código 1 para autentificación Identificador El campo Identificador está formado por un octeto y ayuda a emparejar las peticiones con sus correspondientes respuestas. Este campo debería cambiarse cada vez que se envía un paquete de autentificación diferente de la petición anterior. Long Peer-ID El campo Long Peer-ID está formado por un octeto e indica la Perkins & Hobby [Pág. 33] RFC 1172 Opciones Iniciales PPP Julio 1990 longitud del campo Peer-ID. Peer-ID El campo Peer-ID está formado por cero o más octetos e indica el nombre utilizado por el extremo para autentificarse. Long Contraseña El campo Long Contraseña está formado por un octeto e indica la longitud del campo Contraseña. Contraseña El campo Contraseña puede ocupar cero o más octetos e indica la contraseña que tiene que utilizarse para la autentificación. Perkins & Hobby [Pág. 34] RFC 1172 Opciones Iniciales PPP Julio 1990 4.3. Ack de Autentificación Descripción Si el par Peer-ID/Contraseña recibido en una autentificación es reconocible y aceptable, la implementación PAP debería enviar un paquete PAP con el campo Código con el valor 2 (Ack de Autentificación), el campo Identificador copiado de la autentificación recibida, y opcionalmente, un mensaje ASCII en el campo Mensaje. Debajo se muestra un esquema del formato del paquete Ack de Autentificación. Los campos son transmitidos de izquierda a derecha. 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Código | Identificador | Longitud | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Long Mensaje | Mensaje ... +-+-+-+-+-+-+-+-+-+-+-+-+- Código 2 para el Ack de Autentificación Identificador El campo Identificador ocupa un octeto y ayuda a emparejar las peticiones con sus correspondientes respuestas. El campo Identificador DEBE copiarse del campo Identificador del paquete de autentificación que provocó el Ack de Autentificación. Long Mensaje El campo Long Mensaje ocupa un octeto e indica la longitud del campo Mensaje. Mensaje El campo Mensaje ocupa cero o más octetos y contiene un mensaje ASCII. Perkins & Hobby [Pág. 35] RFC 1172 Opciones Iniciales PPP Julio 1990 4.4. Nak de Autentificación Descripción Si el par Peer-ID/Password recibido en una autentificación no es reconocible o válido, entonces la implementación PAP debe transmitir un paquete PAP con el campo Código igual a 3 (Nak de Autentificación), el campo Identificador copiado del paquete autentificación recibido y, opcionalmente, un mensaje ASCII en el campo Mensaje. Debajo se muestra un esquema del formato del paquete Nak de Autentificación. Los campos son transmitidos de izquierda a derecha. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Código | Identificador | Longitud | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Long Mensaje | Mensaje ... +-+-+-+-+-+-+-+-+-+-+-+-+- Código 3 para Nak de autentificación. Identificador El campo Identificador ocupa un octeto y ayuda a emparejar las peticiones con sus correspondientes respuestas. El campo Identificador DEBE copiarse del campo Identificador del paquete de autentificación que produjo este Nak de Autentificación. Long Mensaje El campo Long Mensaje ocupa un octeto e indica la longitud del campo Mensaje. Mensaje El campo Mensaje ocupa cero o más octetos y contiene un mensaje ASCII. Perkins & Hobby [Pág. 36] RFC 1172 Opciones Iniciales PPP Julio 1990 5. Opciones de Configuración del Protocolo de Control de IP (IPCP) Las Opciones de Configuración de IPCP permiten la negociación de los parámetros deseados del Protocolo Internet. Las modificaciones negociables propuestas en este documento incluyen direcciones IP y protocolos de compresión. Los valores iniciales propuestos para el campo Tipo de Opción de Configuración de IPCP (ver [1]) se asignan de la siguiente manera: 1 Direcciones IP 2 Tipo de Compresión Perkins & Hobby [Pág. 37] RFC 1172 Opciones Iniciales PPP Julio 1990 5.1. Direcciones IP Descripción Esta Opción de Configuración proporciona una forma de negociar las direcciones IP que van a ser utilizadas en cada extremo del enlace. Por defecto, no se les asigna ninguna dirección IP. Una dirección igual a cero será interpretada como una petición para que el otro extremo especifique la dirección. Si la implementación permite el uso de varias direcciones IP debería incluir varias Opciones de Configuración de Dirección IP en sus paquetes de Petición de Configuración. Si la implementación recibe una Petición de Configuración especificando varias Opciones de Configuración de Dirección IP, puede enviar una Negativa de Configuración especificando una o más de las direcciones IP. La implementación que desee que no se le asigne ninguna dirección IP (como puede ser una pasarela) puede rechazar todas las Opciones de Configuración de Dirección IP. Debajo se muestra un esquema del formato de la Opción de Configuración Dirección IP. Los campos son transmitidos de izquierda a derecha. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tipo | Longitud | Dirección IP de Origen +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Dirección IP de Origen (cont) | Dirección IP de Destino +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Dirección IP de Destino (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tipo 1 Longitud 10 Dirección IP de Origen La Dirección IP de Origen, formada por 4 octetos, es la dirección local deseada por el emisor de la Petición de Configuración. En un Ack de Configuración, Nak de Configuración, o Negativa de Configuración, la dirección IP de origen es la dirección remota del emisor, y por lo tanto la dirección local para el receptor de Perkins & Hobby [Pág. 38] RFC 1172 Opciones Iniciales PPP Julio 1990 la Opción de Configuración. Dirección IP de Destino La Dirección IP de Destino, formada por 4 octetos, es la dirección remota con respecto al emisor de la Petición de Configuración. En un Ack de Configuración, Nak de Configuración, o Negativa de Configuración, la Dirección IP de Destino es la dirección local del emisor, y por lo tanto la dirección remota con respecto al receptor de la Opción de Configuración. Por defecto Ninguna dirección IP asignada. Perkins & Hobby [Pág. 39] RFC 1172 Opciones Iniciales PPP Julio 1990 5.2. Tipo de Compresión Descripción Esta Opción de Configuración proporciona una forma de negociar el uso de un protocolo de compresión específico. Por defecto, la compresión no está activada. Debajo se muestra un esquema del formato de la Opción de Configuración Tipo de Compresión. Los campos son transmitidos de izquierda a derecha. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tipo | Longitud | Tipo de Compresión | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Datos ... +-+-+-+-+ Tipo 2 Longitud >= 4 Tipo de Compresión El campo Tipo de Compresión ocupa dos octetos e indica el tipo de protocolo de compresión deseado. Los valores para el campo Tipo de Compresión son siempre los mismos que los del protocolo PPP de Nivel de Enlace para el mismo protocolo de compresión. Los valores mas recientes para el campo Tipo de Compresión se especifican en "Números Asignados" [2]. Los valores iniciales son los siguientes: Valor (en hex) Protocolo 0037 TCP/IP con compresión Van Jacobson Datos El campo Datos ocupa cero o más octetos y contiene datos adicionales, determinados por el protocolo de compresión indicado en el campo Tipo de Compresión. Perkins & Hobby [Pág. 40] RFC 1172 Opciones Iniciales PPP Julio 1990 Por defecto Ningún protocolo de compresión activado. Referencias [1] Perkins, D., "El Protocolo Punto a Punto para la Transmisión MultiProtocolo de Datagramas Sobre Enlaces Punto a Punto", RFC 1171, Julio, 1990. [2] Reynolds, J., y J. Postel, "Números Asignados", RFC 1060, USC/Information Sciences Institute, Marzo 1990. Consideraciones de seguridad Las cuestiones sobre seguridad se discuten en la Sección 2.3. Dirección del Autor Esta propuesta es fruto del Grupo de Trabajo del Protocolo Punto a Punto perteneciente al Grupo de Ingenieros de Internet (IETF). Se puede contactar con dicho grupo a través de su presidente: Russ Hobby UC Davis Computing Services Davis, CA 95616 Teléfono : (916) 752-0236 EMail : rdhobby@ucdavis.edu Las cuestiones sobre este memorándum también pueden ser dirigidas a: Drew D. Perkins Carnegie Mellon University Networking and Communications Pittsburgh, PA 15213 Teléfono : (412) 268-8576 EMail : ddp@andrew.cmu.edu Agradecimientos Mucha gente ha dedicado tiempo ayudando a desarrollar el Protocolo Punto a Punto. La lista completa de gente es demasiado grande, pero las siguientes personas merecen un agradecimiento especial: Ken Adelman (TGV), Craig Fox (NSC), Phill Gross (NRI), Russ Hobby (UC Davis), David Kaufman (Proteon), John LoVerso (Xylogics), Bill Melohn (Sun Microsystems), Mike Patton (MIT), Drew Perkins (CMU), Perkins & Hobby [Pág. 41] RFC 1172 Opciones Iniciales PPP Julio 1990 Greg Satz (cisco systems) y Asher Waldfogel (Wellfleet). Dirección de los traductores/revisores Traductor: Revisor: Pedro J. Ponce de León EMail: pjleon@arrakis.es Perkins & Hobby [Pág. 42]