Network Working Group W. Simpson, Editor Petici—n de Comentarios: 1661 Daydreamer STD: 51 Julio 1994 Obsoletos: 1548 Categor’a: Seguimiento de Est‡ndares Traducci—n al Castellano: Mayo 2003 Ing. Lucas Eduardo Alberione El Protocolo Punto A Punto (PPP) Estado de este memor‡ndum Este documento especifica una serie de est‡ndares de protocolos para la comunidad de Internet y solicita su discusi—n y sugerencias para mejoras. Por favor, remitirse a la edici—n actual de "Est‡ndares de Protocolos Oficiales de Internet" (STD 1) para consultas acerca del estado de la estandarizaci—n y estado de este protocolo. La disribuci—n de este memor‡ndum es ilimitada. Resœmen El Protocolo Punto A Punto (PPP - Point-to-Point Protocol) provee de un mŽtodo est‡ndar para el transporte de datagramas multiprotocolos a travŽs de enlaces punto a punto. PPP consiste en tres componentes principales: 1. Un mŽtodo de encapsulamiento de datagramas multiprotocolos. 2. Un protocolo de control de enlace (LCP - Link Control Protocol) para el establecimiento, configuraci—n y prueba de la conexi—n de enlace de datos. 3. Una familia de Protocolos de Capa de Red (NCP - Network Control Protocols) para el establecimiento y la configuraci—n de diferentes protocolos de capa de red. Este documento define la organizaci—n y metodolog’a de PPP, la encapsulamiento de PPP, conjuntamente con un mecanismo extensible de negociaci—n de opciones el cual es capaz de negociar una variada selecci—n de par‡metros y provee funciones adicionales de administraci—n. El protocolo de control de enlace de PPP (LCP - Link Control Protocol) est‡ descripto en funci—n de este mecanismo. êndice 1. Introducci—n 1.1 Especificaci—n de Requerimientos 1.2 Terminolog’a 2. Encapsulamiento PPP 3. Operaci—n del Enlace PPP 3.1 Resœmen 3.2 Diagrama de Fases 3.3 Enlace Muerto 3.4. Fase de Establecimiento del Enlace 3.5. Fase de Autenticaci—n 3.6. Fase de Protocolo de Capa de Red 3.7. Fase de Terminaci—n del Enlace 4. El Aut—mata de Negociaci—n de Opciones 4.1 Tabla de Transiciones de Estado 4.2 Estados 4.3 Eventos 4.4. Acciones 4.5 Prevenci—n de Ciclos 4.6 Contadores y Temporizadores 5. Formato de Paquetes LCP 5.1. Solicitud de Configuraci—n 5.2. Acuse de Recibo de Configuraci—n 5.3. Acuse Negativo de Configuraci—n 5.4. Rechazo de Configuraci—n 5.5. Solicitud y Acuse de Finalizaci—n 5.6. Rechazo de C—digo 5.7. Rechazo de Protocolo 5.8. Solicitud y Respuesta de Eco 5.9. Solicitud de Descarte 6. Opciones de Configuraci—n de LCP 6.1. M‡xima-Unidad-Recepci—n 6.2. Protocolo-Autenticaci—n 6.3. Protocolo-Calidad 6.4. Nœmero-Magico 6.5. Compresi—n-Campo-Protocolo 6.6. Compresi—n-Campo-Direcci—n-y-Control CONSIDERACIONES DE SEGURIDAD REFERENCIAS RECONOCIMIENTOS DIRECCIîN DEL DIRECTOR DIRECCIîN DEL EDITOR 1. Introducci—n El Protocolo Punto-A-Punto est‡ designado para enlaces simples que transportan paquetes entre dos pares. Estos enlaces proveen de operaci—n full-duplex bidireccional simult‡nea, y se asume que entreguen paquetes en orden. Se tiene el prop—sito que PPP provea de una soluci—n comœn para la f‡cil conexi—n de una amplia variedad de anfitriones, puentes y ruteadores [1]. Encapsulamiento El encapsulamiento de PPP provee de multiplexi—n de diferentes protocolos de capa de red simult‡neamente sobre el mismo enlace. El encapsulamiento de PPP ha sido cuidadosamente dise–ado para mantener la compatibilidad con el hardware m‡s comœnmente utilizado. S—lo 8 octetos adicionales son necesarios para realizar el encapsulamiento cuando es utilizado bajo el formato por defecto del tipo HDLC. En ambientes en donde el ancho de banda es un factor cr’tico, el encapsulamiento y el enmarcado debe ser reducido a 2 o 4 octetos. Para soportar implementaciones de alta velocidad, el encapsulameinto por defecto utiliza s—lo campos simples, en donde s—lo uno de ellos necesita ser examinado para la demultiplexi—n. El encabezado por defecto y los campos de informaci—n caen en los l’mites de 32 bits, y el pie de marco deber’a ser rellenado hasta un l’mite arbitrario. Protocolo de Enlace de Datos Para ser lo suficiente vers‡til y portable hacia una amplia variedad de ambientes, el PPP provee un Protocolo de Enlace de Datos (LCP - Link Control Protocol). El LCP es utilizado para autom‡ticamente obtener un concenso acerca de las opciones de encapsulamiento, manejar varios l’mites de tama–o de paquetes, detectar enlaces c’clicos (looped-back link) y otros errores de configuraci—n y para finalizar el enlace. Otros servicios opcionales provistos son la autenticaci—n de identidad del otro par en el enlace y la determinaci—n de cu‡ndo un enlace est‡ funcionando de manera adecuada y cu‡ndo est‡ fallando. Protocolos de Control de Red Los enlaces Punto a Punto tienen tendencia a agravar varios problemas con la familia actual de protocolos de red. Por ejemplo, la asignaci—n y administraci—n de direcciones IP, lo cual es un problema hasta en los ambientes LAN, y especialmente dificil sobre enlaces punto a punto de conmutaci—n de circuitos (como servidores de modems por discado). Estos problemas son manejados por una familia de Protocolos de Control de Red (NCPs - Network Control Protocols), en donde cada uno trata las necesidades espec’ficas requeridas por sus respectivos protocolos de capa de red. Estos NCPs est‡n definidos en documentos compa–eros. Configuraci—n Se intenta que los enlaces PPP sean f‡ciles de configurar. Por rezones de dise–o, el estandar establece por defecto el manejo de todas la configuraciones comunes. El implementor puede especificar mejoras a la configuraci—n por defecto, las cuales son autom‡ticamente notificadas al par sin intervenci—n del operador. Finalmente, el operador debe configurar las opciones para el enlace de manera expl’cita para operar en ambientes en donde de otra manera ser’a imposible. Esta autoconfiguraci—n es implementada a travŽs de un mecanismo de negociaci—n de opciones, en donde cada extremo del enlace describe al otro sus capacidades y requisitos. Aunque el mecanismo de negociaci—n de opciones descripto en este documento est‡ especificado en tŽrminos del Protocolo de Enlace de Datos (LCP), los mismos servicios son dise–ados para ser utilizados por otros protocolos, especialmente la familia de NCPs. 1.1 Especificaci—n de Requerimientos En este documento, varias palabras son utilizadas para denotar los requisitos de la especificaci—n. Estas palabras a menudo aparecen en mayœsculas. DEBE Esta palabra, o el adjetivo "requerido", significan que la definici—n es un requerimiento absoluto en la especificaci—n. NO DEBE Esta frase significa que es una abosluta prohibici—n de la especificaci—n. DEBERêA Esta palabra,o el adjetivo "recomendado", significa que pueden existir razones v‡lidas en circusntancias particulares para ignorar a este item, pero todas las implicaciones deben ser comprendidas y cuidadosamente evaluadas antes de elegir otro curso de acci—n. PUEDE Esta palabra, o el adjetivo "opcional", ssignifican que este item es uno entre un grupo de alternativas permitidas. Una implementaci—n que no incluya esta opci—n DEBE ser preparada para interoperar con otra implementaci—n que la incluya. 1.2 Terminolog’a En este documento frecuentemente se utilizan los siguientes tŽrminos: Datagrama La unidad de transmisi—n en la capa de red (tal como IP). Un datagrama puede ser encapsulado en uno o m‡s paquetes entregados a la capa de enlace de datos. Marco La unidad de transmisi—n en la capa de enlace de datos. Un marco puede incluir un encabezado y/o fin de marco, conjuntamente con cierto nœmero de unidades de datos. Paquete La unidad b‡sica de encapsulamiento, la cual es entregada a travŽs de la interface entre la capa de red y la capa de enlace de datos. Un paquete usalmente est‡ contenido en un marco; excepciones son cuando mœltiples paquetes son incorporados a un solo marco. Par El otro extremo de de un enlace punto a punto. Descartado silenciosamente La implementaci—n descarta un paquete sin procesamiento extra. La implementaci—n DEBERêA proveer de la capacidad de archivar el error (error logging), incluyendo los contenidos del paquete descartado silenciosamente, y DEBERêA guardar el evento en un contador de estad’sticas. 2. Encapsulamiento PPP El encapsulamiento en PPP es utilizado para posibilitar el transporte de datagramas multiprotocolo. El encapsulamiento requiere el enmarcado para indicar el principio y fin del mismo. MŽtodos de enmarcado son provistos en documentos compa–eros. Abajo se muestra el encapsulamiento PPP en resumen. Los campos son transmitidos de izquierda a derecha. +----------+-------------+---------+ | Protocolo|Informaci—n | Relleno | |8/ 16 bits| * | * | +----------+-------------+---------+ Campo Protocolo El campo Protocolo se compone de uno o dos octetos, y su valor identifica al datagrama encapsulado en el campo de Informaci—n (Information) del paquete. El octeto m‡s significativo de este campo es transmitido y recibido en primer lugar. La estructura de este campo respeta el mecanismo de extensiones ISO 3309 para campos de direcci—n. Todos los valores para el campo de Protocolo DEBEN ser impares; el bit menos significativo del octeto menos significativo DEBE ser igual a "1". Adem‡s, todos los valores para el campo de Protocolo DEBEN ser asignados de manera que el bit menos significativo del octeto m‡s significativo sea igual a "0". Los marcos que no cumplan con estas reglas DEBEN ser tratados como pertenecientes a un Protocolo desconocido. Los valores en el rango de "0***" a "3***" en el campo Protocolo identifican al protocolo de capa de red espec’fico del paquete, y valores en el rango de "8***" a "b***" a paquetes pertenecientes a Protocolos de Control de Red (Network Control Protocols - NCPs) soportados. Los valores en el rango de "4***" a "7***" son utilizados por protocolos con bajo volœmen de tr‡fico que no tienen un NCP asociado. Valores en el rango de "c***" a "f***" identifican a paquetes como Protocolos de Control de capa de enlace (tales como LCP). Valores actualizados para el campo de Protocolo son especificados en el RFC "Nœmero Asignados" ("Assigned Numbers" RFC) [2]. Esta especificaci—n reserva los siguientes valores: Valor (en hex) Nombre del Protocolo 0001 Protocolo de Relleno (Padding Protocol) 0003 a 001f reservado (transparencia ineficiente) 007d reservado (Escape de Control) 00cf reservado (PPP NLPID) 00ff reservado (compresi—n ineficiente) 8001 a 801f no utilizado 807d no utilizado 80cf no utilizado 80ff no utilizado c021 Protocolo de Control de Enlace c023 Protocolo de Autenticaci—n de Contrase–as c025 Informe de Calidad del Enlace c223 Protocolo de Autenticaci—n Challenge Handshake Desarrolladores de nuevos protocolos DEBEN obtener un nœmero a travŽs de la Autoridad para la Asignaci—n de Nœmeros en Internet (Internet Assigned Numbers Authority - IANA), a travŽs de IANA@isi.edu. Campo Informaci—n El campo Informaci—n tiene cero o m‡s octetos. Contiene el datagrama para el protocolo especificado en el campo de Protocolo. La longitud m‡xima para el campo de Informaci—n, incluyendo al relleno, pero sin incluir al campo de Protocolo, est‡ sujeto al tama–o de la Unidad M‡xima de Recepci—n (Maximum Receive Unit - MRU), que por defecto tiene un valor de 1500 octetos. Por medio de la negociaci—n, algunas implementaciones cooperativas de PPP pueden usar otros valores para MRU. Relleno Durante la transmisi—n, el campo de informaci—n PUEDE ser relleno con un nœmero arbitrario de octetos hasta alcanzar el valor dado por la MRU. Es responsabilidad de cada protocolo diferenciar a los octetos de relleno de los de informaci—n. 3. Operaci—n del Enlace PPP 3.1 Resœmen Para establecer comunicaciones a travŽs de un enlace punto a punto, cada extremo del enlace PPP DEBE primero enviar paquetes LCP para configurar y probar el enlace de datos. Luego que el enlace ha sido establecido, el par PUEDE ser autenticado. Entonces, PPP DEBE enviar paquetes NCP para seleccionar y configurar uno o m‡s protocolos de capa de red. Una vez que cada uno de los protocolos de capa de red elegidos ha sido configurado, los datagramas originados por cada uno de ellos pueden ser enviados a travŽs del enlace. El enlace permanecer‡ configurado para soportar comunicaciones hasta que arriven paquetes espec’ficos LCP o NCP solicitando el cierre del enlace, o hasta que ocurra algœn evento externo (expiraci—n de un temporizador de inactividad o intervenci—n del administrador de la red). 3.2 Diagrama de Fases En el proceso de configuraci—n, manutenci—n y finalizaci—n del enlace punto a punto, el enlace PPP pasa a travŽs de diferentes fases que son especificadas en el siguiente diagrama de estados simplificado: +------+ +---------------+ +--------------+ | | ACTIVO | | ABIERTO | | EXITO/NADA |Muerto|------->|Establecimiento|---------->|Autenticaci—n |---+ | | | | | | | +------+ +---------------+ +--------------+ | ^ | | | | FALLA| FALLA| | +<--------------+ +----------+ | | | | | +-----------+ | +---------+ | | INACTIVO | | | CERRANDO | | | +------------|Terminaci—n|<---+<---------- | Red |<-----+ | | | | +-----------+ +---------+ No todas las transiciones est‡n especificadas en este diagrama. La siguiente sem‡ntica DEBE ser respetada. 3.3 Enlace Muerto (la capa f’sica no est‡ lista) El enlace comienza y termina necesariamente en esta fase. Cuando un evento externo (tal como la detecci—n de portadora o la configuraci—n por parte del administrador de la red) indica que la capa f’sica est‡ lista para ser utilizada, PPP proceder‡ a la fase de Establecimiento del Enlace (Link Establishment). Durante esta fase, el aut—mata LCP (descripto luego) estar‡ en los estados Inicial (Initial) o Comenzando (Starting). La transici—n a la fase de Establecimiento (Link Establishment) va a disparar un evento Activo (Up) hacia el aut—mata LCP. Nota de implementaci—n: T’picamente, un enlace retornar‡ a esta fase autom‡ticamente luego de la desconexi—n del modem. En el caso de un enlace "hard-wired", esta fase puede ser extremadamente breve - lo suficientemente extensa para detectar la presencia del dispositivo. 3.4. Fase de Establecimiento del Enlace (Link Establishment) El Protocolo de Control de Enlace (LCP) es utilizado para establecer la conexi—n a travŽs del intercambio de paquetes de Configuraci—n.Este intercambio estar‡ completo, y el estado Abierto (Opened) de LCP ingresado, una vez que un paquete Configure-Ack (Acuse de Recibo de Configuraci—n, descripto m‡s adelante) haya sido enviado y recibido. Se asume que todas las Opciones de Configuraci—n (Configuration Options) estŽn establecidas en sus valores por defecto a menos que fuesen alterados por un intercambio de configuraci—n. RefiŽrase al cap’tulo que trata las opciones de Configuraci—n de LCP para m‡s detalles. Es importante considerar que s—lo las Opciones de Configuraci—n que son independientes de protocolos de red particulares son configuradas por LCP. La configuraci—n protocolos de red individuales es manejada por protocolos de Control de Red (NCPs) durante la fase de Protocolo de Capa de Red (the Network-Layer Protocol phase). Cualquier paquete, aparte de los paquetes LCP, recibido durante esta fase debe ser silenciosamente descartado. La recepci—n de un Solicitud de Configuraci—n LCP (LCP Configure-Request) provoca un retorno a la fase de Establecimiento del Enlace, desde las fases de Protocolo de Capa de Red o de Autenticaci—n. 3.5. Fase de Autenticaci—n (Authentication Phase) En algunos enlaces puede ser deseable requerir que un par se autentique antes de permitir que sus paquetes de protocolo de capa de red sean intercambiados. Por defecto, la autenticaci—n no es imprescindible. Si en una implementaci—n se desea que un par se autentique mediante algœn protocolo de autenticaci—n espec’fico, entonces, en este caso DEBE utilizarse tal protocolo de autenicaci—n durante la fase de Establecimiento del Enlace. La autenticaci—n DEBERêA tener lugar tan pronto como sea posible, luego del establecimiento del enlace. Sin embargo, la determinaci—n de la calidad del enlace PUEDE ocurrir de manera concurrente. Una implementaci—n NO DEBE permitir el intercambio de paquetes de determinaci—n de calidad del enlace, que puede demorar el proceso de autenticaci—n de manera indefinida. El avance desde la fase de Autenticaci—n hacia la de Protocolo de Capa de Red NO DEBE llevarse a cabo hasta que la autenticaci—n se haya completado. Si la autenticaci—n falla, el autenticador DEBERêA proceder, en lugar de la fase de Terminaci—n del Enlace (Link Termination). S—lo los paquetes pertenecientes al Protocolo de Control de Enlace, al protocolo de autenticaci—n y al monitoreo de la calidad del enlace son permitidos durante esta fase. Si otra clase de paquetes fuera de los anteriores est‡ presente durante esta fase, dicho paquete DEBE ser silenciosamente descartado. Notas de Implementaci—n: Una implementaci—n NO DEBERêA fallar en la autenticaci—n simplemente debido a la expiraci—n de un temporizador o a la falta de respuesta. La autenticaci—n DEBERêA permitir algœn tipo de mŽtodo de retransmisi—n y s—lo proceder a la fase de Terminaci—n del Enlace luego de que una serie de intentos han sido llevados a cabo. La implentaci—n responsable de comenzar la Terminaci—n del Enlace es la que ha rechazado la autenticaci—n a su par. 3.6. Fase de Protocolo de Capa de Red (Network-Layer Protocol Phase) Una vez que PPP ha finalizado con sus fases previas, cada protocolo de capa de red (tales como IP, IPX o AppleTalk) DEBE ser configurado separadamente por el Protocolo de Control de Red (Network Control Protocol - NCP) apropiado. Cada NCP PUEDE ser Abierto y Cerrado en cualquier momento. Nota de Implementaci—n: Debido a que una implementaci—n incialmente puede utilizar una cantidad de tiempo significante para determinar la calidad del enlace, las implementaciones DEBERêAN evitar tiempos fijos de expiraci—n de temporizadores cuando esperan que sus pares configuren un NCP. Una vez que el NCP ha alcanzado el estado Abierto (Opened), PPP transportar‡ a los paquetes correspondientes de protocolo de capa de red. Cualquier paquete soportado de protocolo de capa de red que sea recibido cuando el NCP correspondiente no estŽ en el estado Abierto DEBE ser descartado silenciosamente. Nota de Implementaci—n: Mientras que el LCP estŽ en el estado Abierto, cualquier paquete que no estŽ soportado por la implementaci—n DEBE ser retornado a travŽs de un Rechazo de Protocolo (Protocol-Reject), descripto m‡s adelante. S—lo los paquetes pertenecientes a protocolos soportados son descartados silenciosamente. Durante esta fase, el tr‡fico del enlace consiste en cualquier combinaci—n posible de paquetes de LCP, NCP y de paquetes de protocolos de capa de red. 3.7. Fase de Terminaci—n del Enlace (Link Termination Phase) PPP puede dar por finalizado un enlace en cualquier momento. Esto podr’a ocurrir debido a la ausencia de portadora, a una falla de autenticaci—n, a una falla en la calidad del enlace, a la finalizaci—n de un temporizador de per’odo de ocio, o por un cierre del enlace de ’ndole administrativa. LCP es utilizado para cerrar un enlace a travŽs del intercambio de paquetes de Terminaci—n (Terminate packets). Cuando un enlace se est‡ cerrando, PPP informa a los protocolos de capa de red, por lo que dichos protocolos deber’an tomar una acci—n adecuada. Luego del intercambio de paquetes de Terminaci—n, la implementaci—n deber’a notificar a la capa f’sica que se desconecte, para as’ forzar la terminaci—n del enlace, particularmente en el caso de una falla de autenticaci—n. El emisor de la Solicitud de Terminaci—n (Terminate-Request) DEBERêA desconectarse luego de haber recibido el acuse de recibo (Terminate-Ack) para tal solicitud, o luego de que el contador de Reinincio (Restart counter) finalice. El receptor de la Solicitud de Terminaci—n DEBERêA esperar a que su par se desconecte, y NO DEBE desconectarse hasta que haya pasado, al menos, un per’odo de Reinicio (Restart time) luego de haber enviado el acuse de recibo para la terminaci—n. PPP DEBERêA proceder a la etapa de Enlace Muerto (Link Dead phase). Cualquier paquete recibido durante esta fase, que no sea LCP, DEBE ser descartado silenciosamente. Nota de implementaci—n: El cierre de un enlace mediante LCP es suficiente. No existe la necesidad de que cada NCP envie una serie de paquetes de Terminaci—n. De manera opuesta, el hecho de que un NCP haya Cerrado no es raz—n suficiente para provocar la terminaci—n del enlace PPP, aœn si tal NCP fuese, actualmente, el œnico en estado Abierto. 4. El Aut—mata de Negociaci—n de Opciones (Option Negotiation Automaton) El aut—mata de estado finito est‡ definido por eventos, acciones y transiciones de estado. Los eventos incluyen a la recepci—n de comandos externos tales como Abierto y Cerrado, finalizaci—n del temporizador de Reinicio (Restart timer) y la recepci—n de paquetes de un par. Las acciones incluyen el comienzo temporizador de Reinicio y a la transmisi—n de paquetes hacia el par. Ciertas clases de paquetes - Acuses Negativos de Configuraci—n (Configure-Naks) y Rechazos de Configuraci—n (Configure-Rejects), o Rechazos de C—digo (Code-Rejects) y Rechazos de Protocolo (Protocol-Rejects), o Solicitudes de Eco (Echo-Requests), o Respuestas de Eco (Echo-Replies) y Solicitudes de Descarte (Discard-Requests) - no son diferenciados en las descripciones del aut—mata. Como describiremos luego, estos paquetes sirven para funciones diferentes. Sin embargo, siempre provocan las mismas transiciones. Eventos Activo (Up) = capa inferior activa Inactivo (Down) = capa inferior inactiva Abierto (Open) = Abierto administrativo Cerrado (Close) = Cerradoo administrativo TO+ = Timeout con contador > 0 TO- = Timeout con contador expirado RCR+ = Recepci—n de Solicitud de Configuraci—n (Bueno) RCR- = Recepci—n de Solicitud de Configuraci—n (Malo) RCA = Acuse de Recibo de Recepci—n de Paquetes de Configuraci—n RCN = Rechazo / Acuse Negativo de Recepci—n de Paquetes de Configuraci—n RTR = Recepci—n de Solicitud de Finalizaci—n RTA = Recepci—n de Acuse de Recibo de Terminaci—n RUC = Recepci—n de C—digo Desconocido RXJ+ = Rechazo de Recepci—n de C—digo (permitido) o Rechazo de Recepci—n de Protocolo RXJ- = Rechazo de Recepci—n de C—digo (permitido) o Rechazo de Recepci—n de Protocolo RXR = Recepci—n de Solicitud de Eco o Recepci—n de Respuesta de Eco o Recepci—n de Solicitud de Eco Acciones tlu = Esta-Capa-Activa tld = Esta-Capa-Inactiva tls = Esta-Capa-Inicializada tlf = Esta-Capa-Finalizada irc = Inicializar-Contador-Reinicio zrc = Reinicio-Conteo-Cero scr = Solicitud-Env’o-Configuraci—n sca = Env’o-Acuse-Configuraci—n scn = Env’o-Acuse-Negativo-Configuraci—n str = Env’o-Solicitud-Finalizaci—n sta = Env’o-Respuesta-Eco scj = Env’o-Rechazo-C—digo ser = Env’o-Respuesta-Eco 4.1 Tabla de Transiciones de Estado A continuaci—n se presenta la tabla de transiciones de estados completa. Los estados est‡n indicados de manera horizontal y los eventos de manera vertical. Las transiciones de estado est‡n representadas de la forma acci—n/nuevo-estado. Las acciones mœltiples est‡n separadas por comas y pueden continuar en l’neas subsiguientes, en la medida que el espacio lo requiera; las acciones mœltiples pueden ser implementadas de cualquier manera conveniente. El estado puede ser seguido por una letra, la cual indica una explicaci—n al pie de la p‡gina. El gui—n ('-') indica una transici—n ilegal. | Estado | 0 1 2 3 4 5 Evento | Inicial Comenzando Cerrado Detenido Cerrando Deteniendo --------+------------------------------------------------------------ Activo | 2 irc,scr/6 - - - - Inactivo| - - 0 tls/1 0 1 Abierto | tls/1 1 irc,scr/6 3r 5r 5r Cerrado | 0 tlf/0 2 2 4 4 | TO+ | - - - - str/4 str/5 TO- | - - - - tlf/2 tlf/3 | RCR+ | - - sta/2 irc,scr,sca/8 4 5 RCR- | - - sta/2 irc,scr,scn/6 4 5 RCA | - - sta/2 sta/3 4 5 RCN | - - sta/2 sta/3 4 5 | RTR | - - sta/2 sta/3 sta/4 sta/5 RTA | - - 2 3 tlf/2 tlf/3 | RUC | - - scj/2 scj/3 scj/4 scj/5 RXJ+ | - - 2 3 4 5 RXJ- | - - tlf/2 tlf/3 tlf/2 tlf/3 | RXR | - - 2 3 4 5 Los estados en los cuales el temporizador de Reinicio est‡ corriendo son identificables por la presencia de eventos TO. S—lo las acciones Send-Configure-Request, Send-Terminate-Request y Zero-Restart-Count inician o reinician el temporizador de Reinicio (Restart timer). El temporizador de Reinicio es detenido cuando ocurra la transici—n desde cualquier estado en donde el temporizador estŽ corriendo, a un estado en donde dicho temporizador no estŽ corriendo. Los eventos y las acciones est‡n definidas de acuerdo a una arquitectura de env’o de mensajes (message passing architecture), en vez de a una arquitectura de se–alizaci—n (signalling architecture). Si se desea que una acci—n controle a se–ales espec’ficas (como DTR), se requerir‡n acciones adicionales. [p] Opci—n pasiva (Passive option); refiŽrase a la discusi—n sobre el estado Detenido (Stopped). [r] opci—n de Reinicio (Restart option); refiŽrase a la discusi—n sobre el estado Abierto (Open). [x] Conexi—n Cruzada (Crossed connection); refiŽrase a la discusi—n sobre el evento RCA. 4.2 Estados La siguiente lista es una especificaci—n detallada de cada estado del aut—mata. Inicial (Initial) En el Estado Inicial la capa m‡s baja no est‡ disponible (Inactivo - Down), ningœn evento Abierto (Open) ha ocurrido. El temporizador de Reinicio no est‡ corriendo en este estado. Comenzando (Starting) El Estado Comenzando es el hom—logo del evento Abierto al estado Inicial. Un evento Abierto (de ’ndole administrativa) ha sido incializado, pero la capa inferior no est‡ disponible todav’a (Inactivo - Down). El temporizador de Reinicio no est‡ corriendo en este estado. Cuando la capa inferior est‡ disponible (Activo - Up), la petici—n Configure-Request es enviada. Cerrado (Closed) En el estado Cerrado, el enlace est‡ disponible (Activo - Up); el evento Abierto no ha ocurrido. El temporizador de Reinicio no est‡ corriendo en este estado. Durante la recepci—n de paquetes Configure-Request, un paquete Terminate-Ack es enviado. Paquetes del tipo Terminate-Ack son descartados silenciosamente para evitar la creaci—n de un ciclo (loop). Detenido (Stopped) El Estado Detenido es el hom—logo del evento Abierto al estado Cerrado. Se entra a este estado cuando el aut—mata est‡ esperando por un evento Inactivo (Down), luego de una acci—n del tipo This-Layer-Finished o luego de haberse enviado un paquete Terminate-Ack. El temporizador de Reinicio no est‡ corriendo en este estado. Durante la recepci—n de paquetes Configure-Request, se env’a una respuesta adecuada. Y, durante la recepci—n de otro tipo, un paquete Terminate-Ack es enviado. Paquetes del tipo Terminate-Ack son descartados silenciosamente para evitar la creaci—n de un ciclo (loop). Nota Fundamental: El Estado Detenido es una clase de "empalme" hacia la finalizaci—n del enlace, para una falla en la configuraci—n del mismo y para otros modos de falla del aut—mata. Estos estados potencialmente separados han sido combinados. Existe una condici—n entre la respuesta al evento Inactivo ( desde la acci—n This-Layer-Finished) y el evento Receive-Configure-Request. Cuando un paquete Configure-Request arriva antes de que ocurra el evento Inactivo, dicho evento Inactivo retornar‡ al aut—mata al estado Comenzando (Starting). Esto previene del ataque por repetici—n (attack by repetition). Opci—n de Implementaci—n: Luego de que un par falla en la respuesta a solicitudes de configuraci—n, esto es, Configure-Requests, una implementaci—n PUEDE esperar de manera pasiva a que el par env’e Configure-Requests. En este caso, la acci—n This-Layer-Finished no se utiliza para el evento TO- en los estados Req-Sent, Ack-Rcvd y Ack-Sent. Esta opci—n es œtil para circuitos dedicados o para circuitos que no posean se–ales de estado pero NO DEBERêA ser utilizado en circuitos conmutados. Cerrando (Closing) En este estado, se realiza un intento para finalizar de la conexi—n. Una solicitud de finalizaci—n (Terminate-Request) ha sido enviada y el temporizador de Reinicio est‡ corriendo, pero todav’a no ha sido recibido un acuse de recibo para dicha solicitud (Terminate-Ack). Cuando ocurre la recepci—n de Terminate-Ack se entra en el estado Cerrado (Closed). Y cuando ocurre la finalizaci—n del temporizador de Reinicio, un nuevo Terminate-Request es transmitido y dicho temporizador, reiniciado. Luego que el temporizador de Reinicio ha terminado la m‡xima cantidad de veces permitida (establecida por Max-Terminate), se entra en el estado Cerrado. Deteniendo (Stopping) Este estado es el hom—logo del evento Abierto (Open) al estado Cerrando (Closing). Una solicitud de finalizaci—n (Terminate-Request) ha sido enviada y el temporizador de Reinicio est‡ corriendo, pero todav’a no ha sido recibido un acuse de recibo para dicha solicitud (Terminate-Ack). Nota Fundamental: Este estado da la oportunidad de finalizar el enlace antes de la recepci—n de tr‡fico nuevo. Luego de que el enlace ha finalizado, una nueva configuraci—n deber’a ser establecida a travŽs de los estados Detenido (Stopped) o Comenzando (Starting). Solicitud-Enviada (Request-Sent) En este estado, se realiza un intento para configurar la conexi—n. Una solitud de configuraci—n (Configure-Request) ha sido enviada y el temporizador de Reinicio est‡ corriendo, pero un acuse de recibo de configuraci—n (Configure-Ack) todav’a no ha sido recibido ni eviado. Acuse-Recibido (Ack-Received) En este estado, una solitud de configuraci—n (Configure-Request) ha sido enviada y un acuse de recibo de configuraci—n (Configure-Ack) ha sido recibido. El temporizador de Reinicio est‡ corriendo todav’a, dado que el acuse de recibo de configuraci—n (Configure-Ack) todav’a no ha sido enviado. Acuse-Enviado (Ack-Sent) En este estado, una solitud de configuraci—n (Configure-Request) y un acuse de recibo de configuraci—n (Configure-Ack) han sido enviados, pero dicho acuse de recibo de configuraci—n todav’a no ha sido recibido. El temporizador de Reinicio est‡ corriendo, dado que el acuse de recibo de configuraci—n (Configure-Ack) todav’a no ha sido recibido. Abierto (Opened) En este estado, un acuse de recibo de configuraci—n (Configure-Ack) ha sido enviado y recibido. El temporizador de Reinicio no est‡ corriendo. Cuando se entra en este estado, la implementaci—n DEBERêA notificar a las capas superiores que ahora est‡ Activa (Up). De manera contraria, cuando se abandona este estado, la implementaci—n DEBERêA notificar a las capas superiores que ahora est‡ Inactiva (Down). 4.3 Eventos Las transiciones y las acciones en el aut—mata son causadas por eventos. Activo (Up) Este evento ocurre cuando una capa inferior notifica que est‡ disponible para la transmisi—n de paquetes. T’picamente, este evento es utilizado por procesos, tales como de manejo del m—dem (modem handling) y procesos de llamada (calling process), o por otros desde el enlace PPP hacia el medio f’sico, para notificar a LCP que el enlace est‡ entrando en la fase de Establecimiento del Enlace (Link Establishment phase). Adem‡s, puede ser utilizado por LCP para notificar a cada NCP que el enlace est‡ entrando en la fase de Protocolo de Capa de Red (Network-Layer Protocol phase). Esto es, la acci—n This-Layer-Up causada por NCP desencadena el evento Activo (Up) en el NCP. Inactivo (Down) Este evento ocurre cuando una capa inferior indica que ya no est‡ disponible para la transmisi—n de paquetes. T’picamente, este evento es utilizado por procesos, tales como de manejo del m—dem (modem handling) y procesos de llamada (calling process), o por otros desde el enlace PPP hacia el medio f’sico, para notificar a LCP que el enlace est‡ entrando en la fase de Enlace Muerto (Link Dead phase). TambiŽn puede puede ser utilizado por LCP para notificar a cada NCP que el enlace est‡ abandonando en la fase de Protocolo de Capa de Red (Network-Layer Protocol phase). Esto es, la acci—n This-Layer-Down causada por NCP desencadena el evento Inactivo (Down) en el NCP. Abierto (Opened) Este evento indica que el enlace est‡ disponible para el manejo de tr‡fico; esto es, el administrador de red (un ser humano o un programa) ha indicado que est‡ permitido que el enlace sea Abierto (Opened). Cuando ocurre este evento, el enlace no est‡ en el estado Abierto (Opened), por lo que el aut—mata intenta enviar paquetes de configuraci—n al par. Si el aut—mata no es capaz de comenzar la configuraci—n (la capa inferior est‡ Inactiva o un evento Cerrado no se ha completado), el establecimiento del enlace es demorado autom‡ticamente. Cuando se recibe una solicitud de terminaci—n (Terminate-Request) o cuando ocurren otros eventos que causan que el enlace deje de estar disponible, el aut—mata va a progresar hacia un estado en el cual el enlace estŽ listo para ser abierto nuevamente. No es necesaria intervenci—n administrativa adicional. Opci—n de Implementaci—n: La experiencia ha demostrado que los usuarios ejecutan un comando Abierto (Open) adicional cuando desean renegociar el enlace. Esto podr’a indicar que nuevos valores ser‡n negociados. Dado que este no es el significado del evento Abierto (Open), se sugiere que cuando dicho evento es ejecutado en los estados Abierto, Cerrando, Deteniendo o Detenido, la implementaci—n provoque un evento Inactivo, seguido inmediatamente por un evento Activo. Debe tenerse cuidado en que dicho evento Inactivo no puede ser provocado desde otro origen. El evento Inactivo, seguido del evento Activo, provoca una renegociaci—n del enlace ordenada, progresando desde el estado Comenzando (Starting) hacia el estado solicitud-Enviada (Request-Sent). Esto provocar‡ la renegociaci—n del enlace, sin efectos colaterales. Cerrado (Close) Este evento indica que el enlace no est‡ disponible para el manejo de tr‡fico; esto es, el administrador de red (un ser humano o un programa) ha indicado que no est‡ permitido que el enlace sea Abierto. Cuando ocurre este evento y el enlace no est‡ en el estado Cerrado, el automat‡ intenta terminar la conexi—n. Se denegar‡n intentos adicionales de reconfiguraci—n del enlace hasta que ocurra un nuevo evento Abierto. Nota de Implementaci—n: Cuando una autenticaci—n falla, el enlace DEBERêA ser finalizado para prevenir el ataque por repetici—n y la negaci—n de servicio a otros usuarios. Dado que el enlace est‡ disponible de manera administrativa (por definici—n), esto puede ser logrado a travŽs de la simulaci—n del evento Cerrado hacia el LCP, seguido inmediatamente por un evento Abierto. Debe tenerse cuidado que dicho evento Cerrado no puede ser provocado desde otro origen. El evento cerrado, seguido del evento Abierto, provoca una finalizaci—n del enlace ordenada, progresando desde desde el estado Cerrando hacia el estado Deteniendo, y la acci—n This-Layer-Finished puede finalizar el enlace. El aut—mata espera el pr—ximo intento de conexi—n en el estado Detenido o en el estado Comenzando. Timeout (TO+,TO-) Este evento indica la finalizaci—n del temporizador de Reinicio. Dicho temporizador de Reinicio es utilizado para respuestas cronometradas a paquetes de solicitudes de configuraci—n (Configure-Request) y de solicitudes de finalizaci—n (Terminate-Request). El evento TO+ indica que el temporizador de Reinicio tiene un valor mayor a cero, lo que hace que los paquetes de solicitudes de configuraci—n (Configure-Request) y de solicitudes de finalizaci—n (Terminate-Request) sean retransmitidos. El evento TO- indica que el temporizador de Reinicio tiene un valor no mayor a cero y no hay paquetes a ser retransmitidos. Recepci—n de Solicitud de Configuraci—n (Receive-Configure-Request: RCR+,RCR-) Este evento ocurre cuando un paquete de solicitud de configuraci—n (Configure-Request) es recibido desde el par. El paquete Configure-Request indica la intenci—n de abrir una conexi—n y puede especificar Opciones de Configuraci—n. El paquete Configure-Request se describir‡ m‡s detalladamente en una secci—n posterior. El evento RCR+ indica que el paquete Configure-Request fue aceptado y dispara la transmisi—n de su correspondiente paquete Configure-Ack. El evento RCR- indica que el paquete Configure-Request no fue aceptado y dispara la transmisi—n de su correspondiente paquete de acuse negativo de configuraci—n (Configure-Nak) o de un paquete de rechazo de configuraci—n (Configure-Reject). Nota de Implementaci—n: Estos eventos pueden ocurrir en una conexi—n que todav’a estŽ en el estado Abierto (Opened). La implementaci—n DEBE ser preparada para renegociar inmediatamente las Opciones de configuraci—n. Acuse de Recibo de Recepci—n de Paquetes de Configuraci—n (Receive-Configure-Ack - RCA) Este evento ocurre cuando cuando se recibe un paquete Configure-Ack v‡lido desde el par. Este paquete es la respuesta positiva a un paquete Configure-Request. Paquetes fuera de secuencia o inv‡lidos son descartados de manera silenciosa. Nota de Implentaci—n: Dado que un paquete correcto ya ha sido recibido antes de alcanzar los estados Abierto (Opened) o Ack-Rcvd, es muy extra–o que arrive otro paquete de esta clase. Como est‡ especificado, todos los paquetes Ack/Nak/Rej inv‡lidos son descartados silenciosamente; esto no afecta a las transiciones del aut—mata. Sin embargo, no es imposible que un paquete formado correctamente arribase a travŽs de una conexi—n cruzada cronometrada de manera incidental (coincidentally-timed cross-connection). Es m‡s comœn que sea el resultado de un error de implementaci—n. De manera extrema, esta occurrencia DEBERêA ser archivada (logged). Rechazo / Acuse Negativo de Recepci—n de Paquetes de Configuraci—n (Receive-Configure-Nak/Rej - RCN) Este evento ocurre cuando un paquete Configure-Nak o Configure-Reject es recibido desde el par. Estos paquetes son respuestas negativas a un paquete de tipo Configure-Request. Paquetes fuera de secuencia o invalidos son descartados de manera silenciosa. Nota de Implementaci—n: Aunque los paquetes Configure-Nak y Configure-Reject causan la misma transici—n de estado en el automata. Estos paquetes tienen efectos diferentes en las opciones de configuraci—n enviadas como resultado del paquete Configure-Request. Recepci—n de Solicitud de Finalizaci—n (Receive-Terminate-Request - RTR) Este evento ocurre cuando un paquete Terminate-Request es recibido. Este paquete indica la intenci—n por parte del par de finalizar con la conexi—n. Nota de Implementaci—n: Este evento no es idŽntico al evento Cerrado (Closed, ver m‡s arriba) y no suplanta a los comandos de tipo Abierto ejecutados por el administrador de la red. La implementaci—n DEBE ser preparada para recibir un nuevo paqutee Configure-Request, sin intervenci—n de dicho administrador. Recepci—n de Acuse de Recibo de Terminaci—n (Receive-Terminate-Ack - RTA) Este evento ocurre cuando un paquete Terminate-Ack es recibido. Este paquete usualmente es una respuesta a un paquete de tipo Terminate-Request. El paquete Terminate-Ack tambiŽn podr’a indicar que el par est‡ en el estado Cerrado o en el estado Detenido; se utiliza para resincronizar la configuraci—n del enlace. Recepci—n de C—digo Desconocido (Receive-Unknown-Code - RUC) Este evento ocurre cuando cuando se recibe desde el par un paquete que no puede ser interpretado. Un paquete de Rechazo de C—digo (Code-Reject) es enviado como respuesta. Rechazo de Recepci—n de C—digo, Rechazo de Recepci—n de Protocolo (Receive-Code-Reject, Receive-Protocol-Reject - RXJ+,RXJ-) Este evento ocurre cuando un paquete del tipo Code-Reject o Protocol-Reject se recibe desde el par. El evento RXJ+ surge cuando un valor rechazado es aceptable, tal como un paquete Code-Reject de un c—digo extendido o un paquete Protocol-Reject de un NCP. Estos paquetes est‡n comprendidos en el ‡mbito de la operaci—n normal. La implementaci—n DEBE dejar de enviar paquetes de naturaleza "ofensiva". El evento RXJ- surge cuando un valor rechazado es catastr—fico, tal como un paquete Code-Reject de un Configure-Request, o un Protocol-Reject de LCP. Este evento notifica de un error irrecuperable que termina con la conexi—n. Recepci—n de Solicitud de Eco, Recepci—n de Respuesta de Eco, Recepci—n de Solicitud de Eco (Receive-Echo-Request, Receive-Echo-Reply, Receive-Discard-Request - RXR) Este evento ocurre cuando un paquete Echo-Request, Echo-Reply o Discard- Request es recibido desde del par. El paquete Echo-Reply es la respuesta a un paquete Echo-Request. No hay respuestas para los paquetes Echo-Reply o Discard-Request. 4.4. Acciones Las acciones en el aut—mata son causadas por eventos e indican t’picamente la transmission de paquetes y/o el comienzo o la detenci—n del temporizador de Reinicio. Evento Ilegal (-) (Illegal-Event) Esto indica que no puede ocurrir en un automata implementado correctamente. La implementaci—n tiene un error interno, el cual debe ser reportado y archivado. No se produce ninguna transici—n; la implementaci—n NO DEBERêA reiniciarse (reset) o congelarse (freeze). Esta-Capa-Activa (tlu) (This-Layer-Up) Esta acci—n indica a las capas superiores que el aut—mata est‡ entrando en el estado Abierto. Tipicamente, esta acci—n es utilizada por el LCP para disparar el evento Activo (Up) hacia un NCP, un Protocolo de Autenticaci—n, un Protocolo de Calidad de Enlace; o PUEDE ser utilizada por un NCP para indicar que el enlace est‡ disponible para su tr‡fico de capa de red. Esta-Capa-Inactiva (tld) (This-Layer-Down) Esta acci—n indica a las capas superiores que el aut—mata est‡ abandonando el estado Abierto. Tipicamente, esta acci—n es utilizada por el LCP para disparar el evento Inactivo (Down) hacia un NCP, un Protocolo de Autenticaci—n, un Protocolo de Calidad de Enlace; o PUEDE ser utilizada por un NCP para indicar que el enlace ya no est‡ disponible para su tr‡fico de capa de red. Esta-Capa-Inicializada (tls) (This-Layer-Started) Esta acci—n indica a las capa inferiores que el aut—mata est‡ entrando en el estado Comenzando (Starting) y que se requiere de la capa inferior para el enlace. La capa inferior DEBERêA responder con un evento Activo cuando dicha capa estŽ activa. Los resultados de esta acci—n son altamente dependientes de la implementaci—n. Esta-Capa-Finalizada (tlf) (This-Layer-Finished) Esta acci—n indica a las capas inferiors que el automata est‡ entrando en el estado Inicial, Cerrado o Detenido, y que la capa inferior ya no es necesaria para el enlace. La capa inferior DEBERêA responder con un evento Inactivo (Down) cuando haya finalizado. T’picamente, esta acci—n PUEDE ser utilizada por el LCP para avanzar a la fase de Enlace Muerto (Link Dead phase), o PUEDE ser utilizada por un NCP para indicar al LCP que el enlace puede finalizar cuando no haya otros NCP abiertos. Los resultados de esta acci—n son altamente dependientes de la implementaci—n. Inicializar-Contador-Reinicio (irc) (Initialize-Restart-Count) Esta acci—n establece el temporizador de Reinicio al valor apropiado (Max-Terminate o Max-Configure). Es contador es decrementado para cada transmission, incluyendo la primera. Nota de Implementaci—n: Adem‡s de del establecimiento del contador de Reinicio, la implementaci—n DEBE establecer el per’odo de tiempo de sesi—n (timeout) a su valor inicial cuando se utilice retroceso (backoff) en el contador de Reinicio. Reinicio-Conteo-Cero (zrc) (Zero-Restart-Count) Esta acci—n establece el temporizador de Reinicio a cero. Nota de Implementaci—n: Esta acci—n habilita al automata (FSA) a realizar una pausa antes de pasar al estado final, permitiendo que el tr‡fico sea procesado por el par. Adem‡s de establecer el temporizador de Reinicio a cero, la implementaci—n DEBE establecer el per’odo de tiempo de sesi—n (timeout) a un valor apropiado. Solicitud-Env’o-Configuraci—n (scr) (Send-Configure-Request) Un paquete del tipo Configure-Request es transmitido. Esto denota la intenci—n de abrir una conexi—n con un juego especificado de Opciones de Configuraci—n. El temporizador de Reinicio es iniciado cuando el paquete Configure-Request es transmitido, para protecci—n contra la pŽrdida de paquetes. El temporizador de Reinicio es decrementado cada vez que un paquete Configure-Request es eviado. Env’o-Acuse-Configuraci—n (sca) (Send-Configure-Ack) Un paquete del tipo Configure-Ack es transmitido. Esto acusa la recepci—n de un paquete Configure-Request con un juego aceptable de Opciones de Configuraci—n. Env’o-Acuse-Negativo-Configuraci—n (scn) (Send-Configure-Nak) Un paquete del tipo Configure-Nak o Configure-Reject es transmitido. Esta respuesta negativa reporta la recepci—n de un paquete Configure-Request con un juego inaceptable de Opciones de Configuraci—n. Los paquetes Configure-Nak son utilizados para rechazar a un valor de Opci—n de Configuraci—n y para sugerir uno nuevo y aceptable. Los paquetes Configure-Reject son utilizados para rechazar toda negociaci—n acerca de una Opci—n de Configuraci—n, t’picamente porque no es reconocida o implementada. El uso de paquetes Configure-Nak versus Configure-Reject se describe m‡s detalladamente en el cap’tulo sobre Formatos de Paquetes LCP. Env’o-Solicitud-Finalizaci—n (str) (Send-Terminate-Request) Un paquete Terminate-Request es enviado. Esto indica el deseo de cerrar una conexi—n. El temporizador de Reinicio es activado cuando el paquete Terminate-Request es transmitido, como protecci—n contra pŽrdida de paquetes. El temporizador de Reinicio es decrementado cada vez que se env’a un paquete Terminate-Request. Env’o-Acuse-Finalizaci—n (sta) (Send-Terminate-Ack) Un paquete Terminate-Ack es transmitido. Esto certifica la recepci—n de un paquete Terminate-Request o, de otra manera, se utiliza para sincronizar los aut—matas. Env’o-Rechazo-C—digo (scj) (Send-Code-Reject) Un paquete Code-Reject es transmitido. Esto indica la recepci—n de un tipo de paquete desconocido. Env’o-Respuesta-Eco (ser) (Send-Echo-Reply) Un paquete Echo-Reply es transmitido. Esto indica la recepci—n de un paquete Echo-Request. 4.5 Prevenci—n de Ciclos El protocolo realiza un intento razonable al evitar ciclos durante la negociaci—n de Opciones de Configuraci—n. Sin embargo, el protocolo NO garantiza que dichos ciclos no ocurran. Como en cualquier negociaci—n, es posible la configuraci—n de dos implementaciones de PPP con pol’ticas conflictivas que nunca convergen. Adem‡s, es posible configurar pol’ticas que no convergen, pero hacer eso toma una cantidad de tiempo significante. Los implementadores deber’an tener esto en mente y DEBERêAN implementar mecanismos de detecci—n de ciclos o tiempos de descuento de m‡s alto nivel (higher level timeouts). 4.6 Contadores y Temporizadores Temporizador de Reinicio (Restart Timer) Este es un temporizador especial utilizado por el aut—mata. Es utilizado para temporizar transmisiones de paquetes Configure-Request y Terminate-Request. La finalizaci—n de este temporizador causa un evento Timeout y una retransmisi—n de los paquetes Configure-Request y Terminate-Request correspondientes. El temporizador de Reinicio DEBE ser configurable, pero DEBERêA ser establecido a un tiempo por defecto de tres (3) segundos. Nota de Implementaci—n: El temporizador de Reinicio DEBERêA estar basado en la velocidad del enlace. El valor por defecto es establecido para bajas velocidades (2.400 a 9.600 bps), para enlaces de conmutaci—n de alta latencia (l’neas telef—nicas t’picas). Velocidades de enlace m‡s altas o enlaces de conmutaci—n de baja latencia DEBERêAN tener tiempos correspondientes de retransmisi—n m‡s r‡pidos. En vez de en un valor constante, el temporizador de Reinicio PUEDE comenzar en un valor inicial peque–o e incrementarse hasta el valor final configurado. Cada valor sucesivo menos el valor final DEBERêA ser, al menos, el doble del valor previo. El valor inicial DEBERêA ser lo suficientemente grande como para contabilizar el tama–o de los paquetes, dos veces el valor del tiempo de viaje redondo (round trip time) para la transmisi—n a la velocidad del enlace, y al menos 100 milisegundos adicionales para permitir al par que procese los paquetes antes de responder. Algunos circuitos a–aden 200 milisegundos para retardos de satŽlite. Tiempos de viaje Redondo para modems operando a 14.400 bps han sido medidos en el rango de 160 a m‡s de 600 milisegundos. Max-Terminate Se requiere de un contador de reinicio para paquetes Terminate-Request. Max-Terminate indica el nœmero de paquetes Terminate-Request enviados sin recibir un paquete Terminate-Ack antes de asumir que el par es incapaz de responder. Max-Terminate DEBE ser configurable, pero DEBERêA ser establecido por defecto a dos (2) transmisiones. Max-Configure Un contador similar es recomendado para paquetes Configure-Request. Max- Configure indica el nœmero de paquetes Configure-Request enviados sin recibir un paquete v‡lido del tipo Configure-Ack, Configure-Nak o Configure-Reject antes de asumir que el par es incapaz de responder. Max-Terminate DEBE ser configurable, pero DEBERêA ser establecido por defecto a diez (10) transmisiones. Max-Failure Se recomienda un contador similar para paquetes Configure-Nak. Max-Failure indica el nœmero de paquetes Configure-Nak enviados sin recibir un paquete del tipo Configure-Ack antes de asumir que la configuraci—n no est‡ convergiendo. Otros paquetes Configure-Nak para solicitud de opciones de par son convertidos en paquetes Configure-Reject, y las opciones solicitadas localmente ya no son agregadas. Max-Failure DEBE ser configurable, pero DEBERêA ser establecido por defecto a cinco (5) transmisiones. 5. Formato de Paquetes LCP Existen tres clases de paquetes LCP: 1. Paquetes de Configuraci—n de Enlace, utilizados para establecer y configurar un enlace (Configure-Request, Configure-Ack, Configure-Nak y Configure-Reject). 2. Paquetes de Finalizaci—n de Enlace, utilizados para finalizar un enlace (Terminate-Request y Terminate-Ack). 3. Paquetes de Mantenimiento de Enlace, utilizados para administrar y depurar en enlace (Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply, and Discard-Request). Desde el punto de vista de la simplicidad, no existe un campo de versi—n en un paquete LCP. Una implementaci—n LCP funcionando correctamente siempre dar‡ respuesta a Protocolos desconocidos y C—digos con un paquete LCP f‡cilmente reconocible, proveyendo as’ de un mecanismo determin’stico de ca’das (fallback) para la implementaci—n de otras versiones. Sin importar quŽ opciones de configuraci—n est‡n activas, todas las Configuraciones de Enlace LCP, Finalizaciones de Enlace y paquetes Code-Reject (c—digos 1 a 7) siempre son enviados como si ninguna Opci—n de Configuraci—n fuese negociada. En particular, cada Opci—n de Configuraci—n especifica un valor por defecto. Esto asegura que tales paquetes LCP sean siempre reconocibles, aun cuando un extremo del enlace crea, de manera err—nea, que el enlace est‡ abierto. Exactamente un paquete LCP es encapsulado dentro del campo de Informaci—n de PPP, donde el campo de Protocolo de PPP contiene el valor hexadecimal c021 (LCP - Link Control Protocol). Un resumen del formato del paquete de Protocolo de Control de Enlace LCP se muestra a continuaci—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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C—digo | Identificador | Longitud | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Datos ... +-+-+-+-+ C—digo Este campo es de un octecto (8 bits) e identifica el tipo de paquete. Cuando un paquete es recibido con un valor desconocido en el campo C—digo, un paquete Code-Reject es transmitido. Valores actualizados para este campo est‡n especificados en la versi—n m‡s reciente del RFC "Assigned Numbers" [2]. Este documento incluye los siguientes valores: 1 Configure-Request 2 Configure-Ack 3 Configure-Nak 4 Configure-Reject 5 Terminate-Request 6 Terminate-Ack 7 Code-Reject 8 Protocol-Reject 9 Echo-Request 10 Echo-Reply 11 Discard-Request Identificador El campo Identificador es de un octeto y ayuda a corresponder solicitudes con respuestas. Cuando un paquete es recibido con un valor desconocido en el campo Identificador, el paquete es descartado de manera silenciosa sin afectar al aut—mata. Longitud Este campo es de dos octetos e indica la longitud del paquete LCP, incluyendo a los campos C—digo, Identificador, Longitud y Datos. Este campo NO DEBE exceder al valor de MRU del enlace. Los octetos fuera del rango del campo Longitud son tratados como relleno (padding) y son ignorados durante la recepci—n. Cuando se recibe un paquete con un campo de Longitud inv‡lido, dicho paquete se descarta silenciosamente sin afectar al aut—mata. Datos El campo de datos pude tener cero o m‡s octetos, commo se indica en el campo de Longitud. El formato de este campo est‡ determinado por el campo C—digo. 5.1. Solicitud de Configuraci—n (Configure-Request) Descripci—n Una implementaci—n que desea abrir una conexi—n DEBE transmitir un paquete Configure-Request. El campo de Opciones es rellenado con cualquier cambio aplicado a los valores por defecto del enlace. Una vez recibido un paquete Configure-Request, un respuesta apropiada DEBE ser transmitida. Un resumen del formato del paquete Configure-Request se muestra m‡s abajo. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C—digo | Identificador | Longitud | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opciones ... +-+-+-+-+ C—digo Se utiliza el valor 1 para paquetes Configure-Request. Identificador Este campo DEBE ser cambiado cuando el contenido del campo Opciones haya sido modificado, y cuando se haya recibido una respuesta v‡lida a una solicitud anterior. Para retransmisiones, el campo Identificador PUEDE permanecer sin modificaciones. Opciones El campo Opciones es de longitud variable y contiene la lista de cero o m‡s Opciones de Configuraci—n que el emisor desea negociar. Todas las Opciones de Configuraci—n son siempre negociadas de manera simult‡nea. El formato de dichas Opciones de Configuraci—n se describe m‡s detalladamente en un cap’tulo posterior. 5.2. Acuse de Recibo de Configuraci—n (Configure-Ack) Descripci—n En cada Opci—n de Configuraci—n recibida en un solicitud de Configuraci—n (Configure-Request) que sea reconocible y todos sus valores aceptables, entonces la implementaci—n DEBE transmitir un paquete Configure-Ack. Las opciones de Configuraci—n reconocidas NO DEBEN ser reordenadas o modificadas de ninguna manera. Durante la recepci—n de un paquete Configure-Ack. El campo identificador DEBE coincidir con el paquete Configure-Request transmitido. Adem‡s, las opciones de Configuraci—n en un paquete Configure-Ack DEBEN coincidir exactamente con las que han sido transmitidas en el œltimo paquete Configure-Request. Paquetes inv‡lidos son descartados silenciosamente. Un resumen del formato de este paquete se muestra debajo. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C—digo | Identificador | Longitud | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opciones ... +-+-+-+-+ C—digo Se utiliza el valor 2 para paquetes Configure-Ack. Identificador El campo Identificador es una copia del mismo campo en el paquete Configure-Request que ha provocado este paquete Configure-Ack. Opciones El campo Opciones es de longitud variable y contiene la lista de cero o m‡s Opciones de Configuraci—n que el emisor est‡ certificando. Todas las Opciones de Configuraci—n son siempre certificadas de manera simult‡nea. El formato de dichas Opciones de Configuraci—n se describe m‡s detalladamente en un cap’tulo posterior. 5.3. Acuse Negativo de Configuraci—n (Configure-Nak) Si cada instancia de las Opciones de Configuraci—n recibidas es reconocible pero algunos valores no son aceptables, la implementaci—n DEBE transmitir un paquete Configure-Nak. El campo de Opciones es llenado solamente con las Opciones de Configuraci—n no aceptables del paquete Configure-Request. Todas las Opciones de Configuraci—n aceptables son exclu’das del paquete Configure-Nak. Las Opciones de Configuraci—n del paquete Configure-Request NO DEBEN ser reordenadas. Las Opciones que posean campos sin valores (opciones booleanas), en vez, DEBEN utilizar la respuesta a Configure-Reject. Cada Opci—n de Configuraci—n que es aceptaada solamente como un s—la instancia DEBE ser modificada a un valor aceptable para el emisor del paquete Configure-Nak. El valor por defecto PUEDE ser utilizado cuando difiera del valor requerido. Cuando una clase particular de Opci—n de Configuraci—n puede ser listada una vez con valores diferentes, el paquete Configure-Nak DEBE incluir una lista con todos los valores aceptables para esa opci—n, para el emisor del paquete Configure-Nak. Esto incluye a los valores aceptables que estuvieron presentes en el paquete Configure-Request. Finalmente, una implementaci—n puede ser configurada para solicitar la negociaci—n de una Opci—n de Configuraci—n espec’fica. Si esa opci—n no est‡ listada, entonces dicha opci—n PUEDE ser agregada a la lista de Opciones de Configuraci—n acusadas negativamente para solicitar al par que la incluya en su pr—ximo paquete Configure-Request. Cada valor para la opci—n DEBE indicar un valor aceptable para el emisor del paquete Configure-Nak. Durante la recepci—n de un paquete Configure-Nak, el campo Identificador DEBE coincidir con el ultimo paquete Configure-Request transmitido. Paquetes inv‡lidos son descartados silenciosamente. La recepci—n de un paquete Configure-Nak v‡lido indica que cuando un nuevo paquete Configure-Request es enviado, las Opciones de Configuraci—n PUEDEN ser modificadas como se especifica en el paquete Configure-Nak. Cuando estŽn presentes instancias multiples de Opciones de Configuraci—n, el par DEBERêA seleccionar un solo valor a incluir es su pr—ximo paquete Configure-Request. Algunas Opciones de Configuraci—n tienen longitud variable. Dado que una Opci—n acusada negativamente ha sido modificada por el par, la implementaci—n DEBE ser capaz de manipular una longitud de Opci—n que sea diferente de la del paquete Configure-Request original. Un resumen del formato de este paquete se muestra debajo. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C—digo | Identificador | Longitud | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opciones ... +-+-+-+-+ C—digo 3 para paquetes Configure-Nak. Identificador Este campo es una copia del mismo campo Identificador del paquete Configure-Request que ha causado este paquete Configure-Nak. Opciones El campo de Opciones es de longitud variable y contiene la lista de cero o m‡s Opciones de Configuraci—n que el emisor est‡ acusando negativamente. Todas las Opciones de Configuraci—n son siempre acusadas negativamente de manera simult‡nea. 5.4. Rechazo de Configuraci—n (Configure-Reject) Descripci—n Si alguna de las Opciones de Configuraci—n recibidas en un paquete Configure-Request no son reconocidass o no son aceptadas para la negociaci—n (como las configuradas por un admisitrador de red), la implementaci—n DEBE transmitir un paquete Configure-Reject. El campo de Opciones solo es rellenado con las Opciones de Configuraci—n no aceptadas del paquete Configure-Request. Todas las Opciones de Configuraci—n que son aceptadas se excluyen de dicho paquete y las restantes NO DEBEN ser reordenadas de ninguna manera. La recepci—n de un paquete Configure-Reject v‡lido indica que cuando un nuevo paquete Configure-Request es enviado, NO DEBE incluir ninguna de las Opciones de Configuraci—n listadas en el paquete Configure-Reject. Un resumen del formato de este paquete se muestra debajo. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C—digo | Identificador | Longitud | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opciones ... +-+-+-+-+ C—digo 4 para paquetes Configure-Reject. Identificador Este campo es una copia del mismo campo Identificador del paquete Configure-Request que ha causado este paquete Configure-Reject. Opciones Este campo es de longitud variable y contiene la lista de cero o m‡s Opciones que el emisor est‡ rechazando. Todas las Opciones de Configuraci—n son rechazadas de manera simult‡nea. 5.5. Solicitud y Acuse de Finalizaci—n (Terminate-Request y Terminate-Ack) Descripci—n LCP se vale los C—digos del tipo Terminate-Request y Terminate-Ack para proveer de un mecanismo para finalizar una conexi—n. Una implementaci—n con intenciones de finalizar una conexi—n DEBERêA transmitir un paquete Terminate-Request. Los paquetes Terminate-Request DEBERêAN ser enviados de manera continua hasta que un paquete Terminate-Ack sea recibido, o la capa inerior indique que sea ha desactivado, o que ha sido transmitido un nœmero suficientemente grande de veces que se sospecha con cierta certeza que el par est‡ inactivo. En la recepci—n de un paquete Terminate-Request, un paquete Terminate-Ack DEBE ser transmitido. La recepci—n de un paquete Terminate-Ack il’cito indica que el par est‡, o en el estado Cerrado (Closed), o en el estado Detenido (Stopped); o que, de otra manera, tiene la necesidad de un renegociaci—n. Un resumen del formato de estos paquetes se muestra debajo. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C—digo | Identificador | Longitud | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Datos ... +-+-+-+-+ C—digo 5 para paquetes Terminate-Request; 6 para paquetes Terminate-Ack. Identificador Durante la transmisi—n, el campo Identificador DEBE ser cambiado cuando el contenido del campo de Datos cambia y cuando se ha recibido una respuesta v‡lida a una solicitud previa. Para retransmisiones, el campo Identificador PUEDE permanecer sin cambios. Durante la recepci—n, el campo Identificador del paquete Terminate-Request es copiado dentro del campo identificador del paquete Terminate-Ack. Datos El campo de Datos tiene una longitud de cero o m‡s octetos y contiene datos no interpretados para uso del emisor. Los datos pueden consistir de caulquier valor binario. El fin de este campo es indicado por el campo Longitud. 5.6. Rechazo de C—digo (Code-Reject) Descripci—n La recepci—n de un paquete LCP con un C—digo desconocido indica que el par est‡ operando con una versi—n diferente. Esto DEBE ser reportado al emisor a travŽs de la transmisi—n de un paquete Code-Reject. Cuando se produce la recepci—n del paquete Code-Reject con un c—digo que es fundamental para esta versi—n de protocolo, la implementaci—n DEBERêA reportar el problema y finalizar la conexi—n, dado que no es comœn que esta situaci—n pueda ser rectificada de manera autom‡tica. Un resumen del formato de este paquete se muestra debajo. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C—digo | Identificador | Longitud | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Paquete-Rechazado ... +-+-+-+-+ C—digo 7 para paquetes Code-Reject Identificador El campo Identidicador DEBE ser cambiado para cada paquete Code-Reject enviado. Paquete-Rechazado El campo Paquete-Rechazado contiene una copia del paquete LCP que est‡ siendo rechazado. Comienza con el campo de informaci—n y no incluye ningœn encabezado de Capa de Enlace de Datos, ni un FCS. Este campo DEBE ser truncado para cumplir con la MRU espec’fica del par. 5.7. Rechazo de Protocolo (Protocol-Reject) Descripci—n La recepci—n de un paquete PPP con un campo de Protocolo inv‡lido indica que el par est‡ tratando de utilizar un protocolo que no es soportado. Esto ocurre usualmente cuando el par intenta configurar un protocolo nuevo. Si el aut—mata LCP est‡ en el estado Abierto, esto DEBE ser reportado al par mediante la transmisi—n de un paquete Protocol-Reject. En la recepci—n de un paquete Protocol-Reject, la implementaci—n DEBE detener el env’o de paquetes del protocolo especificado tan pronto como sea possible. Paquetes del tipo Protocolo-Reject s—lo pueden ser enviados durante el estado Abierto de LCP. Los paquetes de este tipo que sean recibidos en otro estado que no sea el estado Abierto DEBERêAN ser descartados de manera silenciosa. Un resumen del formato de este paquete se muestra debajo. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C—digo | Identificador | Longitud | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocolo-Rechazado ... | Informaci—n-Rechazada ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C—digo 8 para paquetes Protocol-Reject Identificador El campo Identificador debe ser cambiado para cada env’o de un paquete Protocol-Reject. Protocolo-Rechazado Este campo se de dos octetos y contiene el campo de Protocolo de PPP del paquete que est‡ siendo rechazado. Informaci—n-Rechazada Este campo contiene una copia del paquete que est‡ siendo rechazado. Comienza con el campo de Informaci—n y no incluye ningœn encabezado de Capa de Enlace de Datos ni un FCS. El campo Informaci—n-Rechazada DEBE ser truncado para cumplir con la MRU del par. 5.8. Solicitud y Respuesta de Eco (Echo-Request y Echo-Reply) Descripci—n LCP incluye los C—digos Echo-Request y Echo-Reply para proveer de un mecanismo de respuesta de la Capa de Enlace de Datos, para probar al enlace en sus dos direcciones. Esto es de utilidad para la depuraci—n, la determinaci—n de la calidad del enlace, pruebas de desempe–o y para otras funcionas. Durante la recepci—n de un paquete Echo-Request en el estado Abierto de LCP, un paquete Echo-Reply DEBE ser transmitido. Los paquetes Echo-Request y Echo-Reply solamente DEBEN ser enviados en el estado Abierto de LCP. Paquetes de estos tipos recibidos en otro estado DEBERêAN ser descartados silenciosamente. Un resumen del formato de estos paquetes se muestra debajo. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C—digo | Identificador | Longitud | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nœmero-M‡gico | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Datos ... +-+-+-+-+-+-+-+ C—digo 9 para Echo-Request; 10 para Echo-Reply. Identificador Durante la transmission, el campo identificador DEBE ser cambiado cuando el contenido del campo de Datos cambia y cuando una respuesta v‡lida sea recibida en respuesta a una solicitud anterior. Para retransmisiones, el campo identificador PUEDE permanecer sin modificaciones. Durante la recepci—n, el campo Identificador del paquete Echo-Request es copiado en el campo Identificador del paquete Echo-Reply. Nœmero-M‡gico Este campo es de cuatro octetos y ayuda en la detecci—n de enlaces que estŽn en la condici—n de retroalimentaci—n (loop-back). Hasta que la opci—n de Configuraci—n Nœmero-M‡gico haya sido negociada exitosamente, el campo Nœmero-M‡gico DEBE ser transmitido como cero. VŽase la Opci—n de Configuraci—n Nœmero-M‡gico para una explicaci—n m‡s detallada. Datos El campo Datos tiene cero o m‡s octetos y contiene informaci—n no interpretada para uso del emisor. La informaci—n puede consistir de cualquier valor binario. El fin de este campo es indicado por el campo Longitud. 5.9. Solicitud de Descarte (Discard-Request) Descripci—n LCP incluye un C—digo Discard-Request para proveer un mecanismo de Capa de Enlace de Datos para pruebas de direcci—n local a remotas del enlace. Esto es œtil porque ayuda en lo referente a la depuraci—n, a pruebas de desempe–o y a otras funciones. Los paquetes Discard-Request DEBEN ser enviados solamente en el estado Abierto LCP. Durante la recepci—n, el receptor debe descartar silenciosamente cualquier paquete Discard-Request que se reciba. Un resumen del formato de este paquete se muestra debajo. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C—digo | Identificador | Longitud | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nœmero-M‡gico +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Datos ... +-+-+-+-+-+-+-+ C—digo 11 para paquetes Discard-Request. Identificador Este campo DEBE ser cambiado para cada paquete Discard-Request enviado. Nœmero-Magico Este campo es de cuatro octetos y ayuda en la detecci—n de enlaces que estŽn en la condici—n c’clica (loop-back). Hasta que la opci—n de Configuraci—n Nœmero-M‡gico haya sido negociada exitosamente, el campo Nœmero-M‡gico DEBE ser transmitido como cero. VŽase la Opci—n de Configuraci—n Nœmero-M‡gico para una explicaci—n m‡s detallada. Datos El campo Datos tiene cero o m‡s octetos y contiene informaci—n no interpretada para uso del emisor. La informaci—n puede consistir de cualquier valor binario. El fin de este campo es indicado por el campo Longitud. 6. Opciones de Configuraci—n de LCP Las Opciones de Configuraci—n de LCP permite la negociaci—n o modificaciones a las caracter’sticas por defecto de un enlace punto a punto. Si una Opci—n de Configuraci—n no est‡ incluida en un paquete Configure-Request, el valor por defecto para tal Opci—n de Configuraci—n es asumido. Algunas Opciones de Configuraci—n PUEDEN ser listadas m‡s de una vez. El efecto de esto est‡ especificado por tal Opci—n de Configuraci—n. (Ninguna de las Opciones de Configuraci—n en este documento puede ser listada m‡s de una vez.) El final de la lista de Opciones de Configuraci—n est‡ indicado por el campo Longitud del paquete LCP. A menos que sea especificado de otra manera, todas las Opciones de Configuraci—n son aplicables en modo half-duplex; t’picamente, en la direcci—n de recepci—n del enlace, desde el punto de vista del emisor del paquete Configure-Request. Filosof’a de Dise–o Las opciones indican ciertas capacidades adicionales o requerimientos de la implementaci—n que est‡ solicitando dichas opciones. Una implementaci—n que no comprenda ninguna opci—n debe interoperar con una que implemente cada opci—n. Un valor por defecto es especificado para cada opci—n que permita al enlace funcionar correctamente sin negociar dicha opci—n, aunque quiz‡s con un desempe–o menor al —ptimo. Excepto donde se especifique de manera expl’cita, el reconocimiento de una opci—n no requiere que el par tome ninguna acci—n adicional que no sea establecida por defecto. No es necesario enviar los valores por defecto para las opciones en un paquete Configure-Request. Un resumen del formato de las Opciones de Configuraci—n se muestra debajo. 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 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tipo | Longitud | Datos ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tipo El campo Tipo es de un octeto e indica el tipo de Opci—n de Configuraci—n. Valores actualizados para el campo Tipo est‡n especificados en la versi—n m‡s reciente del RFC "Assigned Numbers" [2]. Este documento incluye los siguientes valores: 0 RESERVADO 1 M‡xima-Unidad-Recepci—n (Maximum-Receive-Unit) 3 Protocolo-Autenticaci—n (Authentication-Protocol) 4 Protocolo-Calidad (Quality-Protocol) 5 Nœmero-M‡gico (Magic-Number) 7 Compresi—n-Campo-Protocolo (Protocol-Field-Compression) 8 Compresi—n-Campo-Direcci—n-y-Control (Address-and-Control-Field-Compression) Longitud Este campo es de un octeto e indica la longitud de esta Opci—n de Configuraci—n, incluyendo a los campos Tipo, Longitud y Datos. Si una Opci—n de Configuraci—n negociable es recibida en un paquete Configure-Request, pero con un campo Longitud inv‡lido o no reconocido, un paquete Configure-Nak DEBERêA ser enviado, incluyendo la Opci—n de Configuraci—n deseada con campos Longitud y Datos apropiados. Datos Este campo contiene cero o m‡s octetos y contiene informaci—n espec’fica a la Opci—n de Configuraci—n. El formato y la longitud de este campo est‡ determinado por los campos Tipo y Longitud. Cuando el campo Longitud indica que el campo de Datos es extendido m‡s all‡ del campo Informaci—n, el paquete entero es descartado silenciosamente sin afectar al aut—mata. 6.1 M‡xima-Unidad-Recepci—n (Maximum-Receive-Unit - MRU) Descripci—n Esta Opci—n de Configuraci—n puede ser enviada para informar al par que la implementaci—n puede recibir paquetes m‡s grandes o para solicitarle a dicho par que env’e paquetes m‡s peque–os. El valor por defecto es de 1500 octetos. Si se solicitan paquetes m‡s peque–os, una implementaci—n todav’a DEBE ser capaz de recibir el campo completo de 1500 octetos en el caso que se pierda la sincronizaci—n del enlace. Nota de Implementaci—n Esta opci—n es utilizada para indicar la capacidad de una implementaci—n. No se requiere que el par maximize la utilizaci—n de su capacidad. Por ejemplo, cuando se indica que un MRU es de 2048 octetos, no se requiere que el par env’e paquetes de 2048 octetos. El par no necesita paquetes Configure-Nak para indicar que Žl solo enviar‡ paquetes m‡s peque–os, dado que la implementaci—n siempre requerir‡ de soporte para, al menos, 1500 octetos. Un resumen del formato de este paquete se muestra debajo. 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 | M‡xima-Unidad-Recepci—n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tipo 1 Longitud 4 M‡xima-Unidad-Recepci—n Este campo es de dos octetos y especifica la cantidad maxima de octetos en los campos de Informaci—n y de Relleno (Padding). No incluye al enmarcado, ni al campo Protocolo, FCS, ni bits o bytes de transparencia. 6.2 Protocolo-Autenticaci—n (Authentication Protocol) Descripci—n En algunos enlaces es deseable solicitar al par que se autentique antes de permitir que los paquetes de protocolos de capa de red sean intercambiados. Esta Opci—n de Cofiguraci—n provee de un mŽtodo para negociar el uso de un protocolo espec’fico para autenticaci—n. Por defecto, la autenticaci—n no es requerida. Una implementaci—n NO DEBE incluir Opciones de Configuraci—n del tipo Protocolo-Autenticaci—n multiples en sus paquetes Configure-Request. En cambio, DEBERêA intentar configurar primero al protocolo m‡s deseable. Si ese protocolo ha sido acusado negativamente, desde el punto de vista de la configuraci—n (Configure-Nak), la implementaci—n DEBERêA tratar de configurar al pr—ximo protocolo m‡s deseable en el pr—ximo paquete Configure-Request. La implementacion que est‡ enviando el paquete Configure-Request est‡ indicando que espera que su par se autentifique. Si una implementaci—n env’a un paquete Configure-Ack significa que est‡ de acuerdo de autenticarse ante un protocolo espec’fico. Una implementaci—n que estŽ recibiendo un paquete Configure-Ack DEBERêA esperar que el par se autentique con el protocolo reconocido. No se requiere que la autenticaci—n sea full-duplex o que el mismo protocolo sea utilizado en ambas driecciones. Es perfectamente acceptable que protocolos diferentes sean utilizados en cada direcci—n. Esto, por supuesto, depender‡ de los protocolos espec’ficos negociados. Un resumen del formato de esta Opci—n de Configuraci—n se muestra debajo. 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 | Protocolo-Autenticaci—n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Datos ... +-+-+-+-+ Tipo 3 Longitud >= 4 Protocolo-Autenticaci—n Este campo es de dos octetos e indica el protocolo de autenticaci—n deseado. Los valores para este campo ser‡n siempre los mismos que los del campo de Protocolo PPP para el mismo protocolo de autenticaci—n. Valores actualizados para el campo de Protocolo son especificados en el RFC "Nœmero Asignados" ("Assigned Numbers" RFC) [2]. Esta especificaci—n utiliza los siguientes valores: Valor (en hex) Protocolo c023 Protocolo de Autenticaci—n de Palabras Clave (Password Authentication Protocol) c223 Protocolo de Autenticaci—n Challenge Handshake (Challenge Handshake Authentication Protocol) Datos El campo Datos tiene cero o m‡s octetos y contiene informaci—n adicional, como lo determina el propio protocolo. 6.3 Protocolo-Calidad (Quality-Protocol) Descripci—n En ciertos enlaces es deseable determinar cu‡ndo y cu‡n a menudo dicho enlace descartar‡ informaci—n. Este proceso es llamado monitoreo de calidad de enlace (link quality monitoring). Esta Opci—n de Configuraci—n provee de un mŽtodo para negociar el uso de un protocolo espec’fico para el monitoreo de la calidad del enlace. Por defecto, el monitoreo de la calidad del enlace est‡ desactivada. La implementaci—n que est‡ enviando el paquete Configure-Request est‡ indicando que espera recibir informaci—n de monitoreo de su par. Si una implementaci—n env’a un paquete Configure-Ack, entonces est‡ de acuerdo en utilizar el protocolo especificado. Una implementaci—n recibiendo un paquete Configure-Ack DEBERêA esperar a que el par envie el protocolo reconocido. No se requiere el dicho monitoreo de calidad sea full-duplex o que el mismo protocolo sea utilizado en ambas direcciones. Es perfectamente acceptable que protocolos diferentes sean utilizados en cada direcci—n. Esto depender‡, por supuesto, de los protocolos negociados. Un resumen del formato de esta Opci—n de Configuraci—n se muestra debajo. 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 | Protocolo-Calidad | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Datos ... +-+-+-+-+ Tipo 4 Longitud >= 4 Protocolo-Calidad Este campo es de dos octetos e indica el protocolo de monitoreo de calidad de enlace deseado. Los valores para este campo son siempre los mismos que los del campo de PPP Protocolo para ese mismo protocolo de monitoreo. Valores actualizados para este campo son especificados en el RFC "Nœmero Asignados" ("Assigned Numbers" RFC) [2]. Esta especificaci—n reserva los siguientes valores: Valor (en hex) Protocolo c025 Informe de calidad de Enlace (Link Quality Report) Datos El campo Datos es de cero o m‡s octetos y contiene informaci—n adicional, determinada por dicho protocolo. 6.4. Nœmero-M‡gico Descripci—n Esta Opci—n de Configuraci—n provee de un mŽtodo para detectar enlaces en estado c’clico (looped-back) y otras anomal’as de la Capa de Enlace de Datos. Esta Opci—n PUEDE ser requerida por otras Opciones de Configuraci—n, como la opci—n Protocolo-Calidad. Por defecto, el Nœmero-M‡gico no es negociado, y se inserta un cero cuando deba ser usado de otra manera. Antes de que esta Opci—n de Configuraci—n sea solicitada, una implementaci—n DEBE elegir su Nœmero-M‡gico. Se recomienda que dicho nœmero sea elegido de la manera m‡s aleatoria posible para garantizar una muy alta probabilidad de que una implementaci—n seleccione un nœmero œnico. Una buena manera de lograr esto es comenzar la generaci—n del nœmero con una semilla œnica. Buenas fuentes para la selecci—n de semillas son los nœmeros de series de las m‡quinas, direcciones de hardware de red, relojes de hora, etc. De manera particular, buenas semillas aleatorias son medidas precisas de tiempo entre arrivos de eventos f’sicos, tales como la recepci—n de paquetes desde otras redes conectadas, el tiempo de respuesta del servidor o la tasa de tipeo de un usuario humano. TambiŽn se sugiere que que varias fuentes sean utilizadas de manera simult‡nea. Cuando un paquete Configure-Request es recibido con una Opci—n de Configuraci—n de Nœmero-M‡gico, dicho Nœmero es comparado con el Nœmero-M‡gico del œltimo paquete Configure-Request enviado hacia el par. Si los dos nœmeros son diferentes, el enlace no est‡ en estado c’clico (looped-back) y el Nœmero-M‡gico DEBERêA ser reconocido como v‡lido. Si son iguales, es posible pero no cierto, que el enlace este en estado c’clico y que dicho paquete Configure-Request actualmente sea el œltimo que ha sido enviado. Para determinar esto, un paquete Configure-Nak DEBE ser enviado especificando un Nœmero-M‡gico diferente. Un nuevo paquete Configure-Request NO DEBERêA ser enviado hacia el par hasta que el procesamiento normal cause dicho env’o (esto es, hasta que un paquete Configure-Nak sea recibido o hasta que el temporizador de Reinicio expire). La recepci—n de un paquete Configure-Nak con un Nœmero-M‡gico diferente del perteneciente al œltimo paquete Configure-nak enviado hacia el par prueba que el enlace no est‡ en estado c’clico e indica la existencia de un Nœmero-M‡gico œnico. Si el Nœmero-M‡gico es igual al enviado en el œltimo paquete Configure-Nak, la posibiliad de un enlace en estado c’clico se incrementa y un nuevo Nœmero-M‡gico DEBE ser elegido. En cada caso, un nuevo paquete Configure-Request DEBERêA ser enviado con el nuevo Nœmero-M‡gico. Si, afirmativamente, el enlace est‡ en estado c’clico, esta secuencia (transmitir Configure-Request, recibir Configure-Request, transmitir Configur-Nak, recibir Configure-Nak) se repetir‡ una vez y otra. Si el enlace no est‡ en dicho estado, esta secuencia podr’a ocurrir unas pocas veces, pero no es comœn que ocurra repetidamente. De esta manera, los Nœmeros-M‡gicos elegidos en cada extremo diverger‡n r‡pidamente, finalizando la secuencia. La siguiente tabla muestra la probabilidad de colisiones, asuumiendo que ambos extremos del enlace eligen sus Nœmeros-M‡gicos en base a una distribuci—n de probabilidad perfectamente 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 Buenas fuentes de aleatoriedad son requeridas para que ocurra esta divergencia. Si una buena fuente no puede ser encontrada, se recomienda que esta Opci—n de Configuraci—n no estŽ disponible. Paquetes Configure-Request con esta opci—n NO DEBERêAN ser transmitidos y cualquier Opci—n de Configuraci—n de Nœmero-M‡gico que el par env’e DEBERêA ser reconocida o rechazada. En este caso, los enlaces en estado c’clico no pueden ser detectados por la implementaci—n de una manera confiable, aunque todav’a puedan ser detectados por el par. Si una implementaci—n transmite un paquete Configure-Request con una Opci—n de Configuraci—n de Nœmero-M‡gico, dicha implementaci—n NO DEBE responder con un paquete Configure-Reject cuando reciba un paquete Configure-Request con una Opci—n de Configuraci—n de Nœmero-M‡gico. Esto es, si una implementaci—n desea utilizar Nœmeros-M‡gicos, entonces tambiŽn DEBE permitir que su par haga lo mismo. Si una implementaci—n no recibe un paquete Configure-Reject en respuesta a un paquete Configure-Request, significa que el enlace no est‡ en estado c’clico y que su par no utilizar‡ Nœmeros-M‡gicos. En este caso, una implementaci—n DEBERêA actuar como si la negociaci—n hubiese sido exitosa (como si hubiese recibido un paquete Configure-Ack). El Nœmero-M‡gico tambiŽn podr’a ser utilizado para detectar enlaces en estado c’clico bajo operaci—n normal y tambien durante la negociaci—n de Opciones de Configuraci—n. Todos los paquetes LCP Echo-Request, Echo-Reply y Discard-Request tienen su campo Nœmero-M‡gico. Si un Nœmero-M‡gico ha sido negociado de manera exitosa, una implementaci—n DEBE transmitir dichos paquetes con el campo Nœmero-M‡gico establecido a su valor negociado. Los campos Nœmero-M‡gico de estos paquetes DEBERIçN ser inspeccionados durante la recepci—n. Todos los campos Nœmero-M‡gico recibidos DEBEN ser iguales a cero o al Nœmero-M‡gico del par, dependiendo si el par ha negociado o no un Nœmero-M‡gico. La recepci—n de un campo Nœmero-M‡gico con un valor igual al negociado denota un enlace en estado c’clico. La recepci—n de un campo Nœmero-M‡gico con un valor diferente al negociado de manera local o con un valor igual a cero (si el par no ha negociado uno), indica un enlace que ha sido (mal)configurado para comunicaciones con un par diferente. No hay especificaciones en lo referente a procedimientos para la recuperaci—n de cada situaci—n y podr’an variar entre diferentes implementaciones. Un procedimiento un poco pesimista es asumir un evento del tipo LCP Inactivo (Down). Un evento Abierto (Open) comenzar‡ el proceso de restablecimento del enlace, el cual no puede ser completado hasta que el estado c’clico haya finalizado y los Nœmeros-M‡gicos exitosamente negociados. Un procedimiento m‡s optimista (en el caso de un enlace en estado c’clico) es comenzar transmitiendo paquetes LCP Echo-Request hasta que un paquete Echo-Reply apropiado sea recibido, indicando el fin del estado c’clico. Un resumen del formato de esta Opci—n de Configuraci—n se muestra debajo. 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.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tipo 5 Longitud 6 Nœmero-M‡gico El campo Nœmero-M‡gico es de cuatro octetos e indica un nœmero que es muy probable que sea œnico en un extremo del enlace. Un valor de cero para este campo no est‡ permitido y siempre DEBE ser acusado negativamente (Nak'd), si no es Rechazado de manera rotunda. 6.5. Compresi—n-Campo-Protocolo (Protocol-Field-Compression - PFC) Descripci—n Esta Opci—n de Configuraci—n provee de un mŽtodo para negociar la compresi—n del campo Protocolo de PPP. Por defecto, todas las implementaciones DEBEN transmitir paquetes con el campo Protcolo de dos octetos. Los nœmeros de este campo son elegidos de manera tal que algunos valores podr’an ser comprimidos en un s—lo octeto, que es claramente diferenciable de un valor de dos octetos. Esta Opci—n de Configuraci—n es enviada para informar al par que la implementaci—n puede recibir tales campos Protocolo de un octeto. Como se mencion— anteriormente, el campo Prtocolo utiliza un mecanismo de extensi—n, consistente con el mecanismo de extensi—n ISO 3309 para el campo de Direcci—n; el Bit Menos Significativo (Least Significant Bit - LSB) de cada octeto es utilizado para indicar la extensi—n del campo Protocolo. Con un "0" binario es la manera que el LSB indica que el campo Protocolo continœa con el siguiente octeto. Con la presencia de un "1" binario es como LSB denota el œltimo octeto del campo Protocolo. N—tese que cualquier cantidad de "0" pueden ser agregados al principio del campo y todav’a indicar‡ el mismo valor (considŽrese que las dos representaciones binarias para 3 son 00000011 y 00000000 00000011). Cuando se utilicen enlaces de baja velocidad, es deseable conservar el ancho de banda enviando una peque–a cantidad de datos redundantes como sea posible. La Opci—n de Configuraci—n Compresi—n-Campo-Protocolo permite la negociaci—n entre la simplicidad de una implementaci—n y la eficiencia del ancho de banda. Si la negociaci—n es exitosa, el mecanismo de extension ISO 3309 puede ser utilizado para comprimir al campo Protocolo en un octeto, en vez de en dos. La gran mayor’a de los paquetes son asignados con valores para el campo Protocolo menores a 256. Los campos Protocolo comprimidos NO DEBEN ser transmitidos a menos que esta Opci—n de Configuraci—n haya sido negociada. Cuando as’ lo sea, las implementaciones de PPP DEBEN aceptar paquetes PPP con campos Protocolo de uno o dos octetos y NO DEBEN hacer distinci—n entre ellos. El campo de Protocolo nunca es comprimido cuando se estŽn enviando paquetes LCP. Esta regla garantiza el reconocimiento no ambiguo de paquetes LCP. Cuando el campo Protocolo es comprimido, el campo FCS de Capa de Enlace de Datos es calculado en un marco comprimido, no en un uno no comprimido. Un resumen del formato de esta Opci—n de Configuraci—n se muestra debajo. 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 6.6. Compresi—n-Campo-Direcci—n-y-Control (Address-and-Control-Field-Compression - ACFC) Descripci—n Esta Opci—n de Configuraci—n provee de un mŽtodo para negociar la campresi—n de los campos de Capa de Enlace de Datos Direcci—n y Control. Por defecto, todas las implementaciones DEBEN transmitir marcos con campos de Direcci—n y Control apropiados para el enmarcamiento del enlace. Dado que dichos campos usualmente tienen valores constantes para enlaces punto-a-punto, son f‡cilmente comprimibles. Esta Opci—n de Configuraci—n es enviada para informar al par que la implementaci—n puede recibir campos de Direcci—n y Control comprimidos. Si un marco comprimido es recibido cuando la opci—n Compresi—n-Campo-Direcci—n-y-Control no ha sido negociada, la implementaci—n PUEDE descartar el marco de manera silenciosa. Los campos de Direcci—n y Control NO DEBEN ser comprimidos cuando se est‡n enviando paquets LCP. Esta regla garantiza el reconocimiento no ambiguo de paquetes LCP. Cuando los campos de Direcci—n y Control son comprimidos, el Campo FCS de Capa de Enlace de Datos es calculado en el marco comprimido, no en el marco original no comprimido. Un resumen del formato de estas Opciones de Configuraci—n se muestra debajo. 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 8 Longitud 2 Consideraciones de Seguridad Asuntos de seguridad son discutidos brevemente en las secciones dedicadas a la Fase de Autenticaci—n, al evento Cerrado y a la Opci—n de Configuraci—n Protocolo-Configuraci—n. Referencias [1] Perkins, D., "Requirements for an Internet Standard Point-to- Point Protocol", RFC 1547, Carnegie Mellon University, Diciembre de 1993. [2] Reynolds, J. y Postel, J., "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, Julio de 1992. Reconocimientos Este documento es el producto del Grupo de Trabajo del Protocolo Punto-a-Punto del Grupo de Tareas de Ingenier’a de Internet Internet Engineering Task Force - IETF). Cualquier tipo de comentraio deber’an ser enviados a la lista de correo ietf-ppp@merit.edu. Gran cantidad del texto en este documento es tomada de los requerimientos del grupo de trabajo [1]; de los RFCs 1171 y 1172, por Drew Perkins durante su per’odo en la Carnegie Mellon University y por Russ Hobby de la University of California en Davis. William Simpson fue el principalmente responsable de introducir terminolg’a y filosof’a consistente, y de redise–ar las m‡quinas de estado de fase y negociaci—n. Mucha gente ha invertido mucho tiempo ayudando a desarrollar el Protocolo Punto-a-Punto. Lista completa de dicha gente es demasiado numerosa, pero las siguientes personas merecen un agradecimiento especial: Rick Adams, Ken Adelman, Fred Baker, Mike Ballard, Craig Fox, Karl Fox, Phill Gross, Kory Hamzeh, former WG chair Russ Hobby, David Kaufman, el presidente de WG Steve Knowles, Mark Lewis, el presidente de WG Brian Lloyd, John LoVerso, Bill Melohn, Mike Patton, el presidente de WG Drew Perkins, Greg Satz, John Shriver, Vernon Schryver y Asher Waldfogel. Un agradecimento especial a Morning Star Technologies por la provisi—n de los recursos computacionales y soporte en el acceso a la red, para la escritura de esta especificaci—n. Direcci—n del Presidente El grupo de trabajo puede ser contactado a travŽs de su actual presidente: Fred Baker Advanced Computer Communications 315 Bollay Drive Santa Barbara, California 93117 fbaker@acc.com Direcci—n del Editor Preguntas acerca de este documento pueden ser enviadas a: William Allen Simpson Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com