.ds LF Malkin y Harkin .ds RF [Pág. %] .ds CF Estándar .ds LH RFC 2347 .ds RH mayo 1998 .ds CH Negociación de Opciones para el TFTP .pl 10.0i .po 0 .ll 7.2i .lt 7.2i .nr LL 7.2i .nr LT 7.2i .hy 0 .ad l .nf .nr Pl \n(.l/\n(.H .ta \n(PlR Network Working Group G. Malkin Request for Commments: 2347 Bay Networks Updates: 1350 A. Harkin Obsoletes: 1782 Hewlett Packard Co. Category: Standards Track May 1998 .ce \*(CH .in 3 .fi .ti 0 Estado de esta Memoria Este documento es la especificación de un protocolo estándar para la comunidad de Internet, y propone discusiones y promueve sugerencias para mejorarlo. Por favor refiérase a la edición actual de los "Protocolos Oficiales y Estándares de Internet" (STD 1) para conocer el estado actual del estándar y de este protocolo. La distribución de esta memoria es ilimitada. .ti 0 Información del Copyright Copyright (C) La Sociedad de Internet (1998). Todos los derechos reservados. .ti 0 Extracto El Protocolo Trivial de Transferencia de Archivos [1] es un protocolo simple, de paso a paso regulado, para la transferencia de archivos que permite a un cliente leer o escribir un archivo en un servidor remoto. Este documento describe una extensión simple del TFTP que le permitirá una negociación previa antes de empezar con la transferencia de archivos. .ti 0 Introducción El mecanismo de negociación de opción propuesto en este documento, es una ampliación compatible con las especificaciones anteriores del protocolo TFTP. Gracias a este mecanismo que es consistente con la petición de paquetes del TFTP, es posible crear una negociación previa antes de proceder a la transferencia propiamente dicha. El mecanismo es simple en principio y lo que hace es forzar una secuencia de petición–respuesta-reconocimiento similar al sistema de paso a paso regulado que usa el mismo TFTP. Mientras que el mecanismo de negociación de opciones es de propósito general, en la que se pueden negociar muchos tipos de opciones, este mecanismo se creo principalmente para dar soporte a la opción de Tamaño de Bloque que se encuentra definido en [2]. Otras opciones adicionales se definen en [3]. .ti 0 Formato de los paquetes Las opciones TFTP se añaden tanto a los paquetes de peticiones de lectura como a los de peticiones de escritura. Y se define un nuevo tipo de paquete, el reconocimiento de opción (OACK), que se usa para reconocer la petición de negociación de opciones del cliente. También se define el nuevo código de error 8 para indicar la presencia de una negociación de opciones y con la señalización de este error puede terminarse la transferencia. Las opciones se añaden a los paquetes de peticiones de lectura o de escritura de la forma siguiente: .KS .nf .in 6 +-------+---~~----+---+---~~---+---+---~~---+---+---~~---+---+--> | cod | archivo | 0 | modo | 0 | opc1 | 0 | valor1 | 0 | < +-------+---~~----+---+---~~---+---+---~~---+---+---~~---+---+--> >-------+---+---~~---+---+ < opcN | 0 | valorN | 0 | >-------+---+---~~---+---+ .KE .fi Los "0" mostrados en estas ilustraciones y los "1" de abajo son todos octetos cero, p.ej. terminadores Nulos para los campos precedentes. cod\p .in 9 El campo del código de operación puede contener un 1 para peticiones de lectura o un 2 para peticiones de escritura, tal como está definido en [1]. .ti 6 archivo\p El nombre del archivo para ser leído o escrito, tal como está definido en [1]. Este campo ha de terminarse con un byte nulo. .ti 6 modo\p Es el modo de la transferencia del archivo: "netascii", "octet", o "mail", tal como está definido en [1]. Este campo ha de terminarse con un byte nulo. .ti 6 opc1\p Es la primera opción en ASCII sin tener en cuenta las mayúsculas o minúsculas (p.ej., "blksize"). Este campo ha de terminarse con un byte nulo. .ti 6 valor1\p El valor asociado con la primera opción, en ASCII sin tener en cuenta las mayúsculas o minúsculas. Este campo ha de terminarse con un byte nulo. .ti 6 opcN, valorN\p Es el último par de opción/valor. Cada campo estará en ASCII sin tener en cuenta las mayúsculas o minúsculas y terminará con un byte nulo. .in 3 Las opciones y sus valores siempre terminan con un byte nulo, para mantener el formato de las peticiones originales. Si hay que negociar múltiples opciones, estas se añadirán una a continuación de la otra. El orden de colocación de las opciones, es indiferente. La longitud máxima de un paquete de petición será de 512 octetos. El paquete OACK tendrá el siguiente formato: .KS .nf .in 6 +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+ | cod | opc1 | 0 | valor1 | 0 | opcN | 0 | valorN | 0 | +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+ .KE .fi .in 9 .ti 6 cod\p El campo del código de operación contendrá un 6, para el reconocimiento de la Opción. .ti 6 opc1\p Es el reconocimiento de la primera opción, que es una copia de la petición original. .ti 6 valor1\p El valor reconocido asociado con la primera opción. De la manera que este valor puede diferir respecto de la petición original, está detallado en la especificación de dicha opción. .ti 6 opcN, valorN\p Es el reconocimiento para el último par de opción/valor. .in 3 .ti 0 Protocolo de Negociación Tal como se ha mostrado arriba, el cliente añade opciones al final de los paquetes de petición de lectura o escritura, y se pueden añadir cualquier cantidad de opciones, el orden de estas opciones es indiferente. Si el servidor soporta la negociación de opciones, y puede reconocer una o más de las opciones en el paquete de petición, el servidor responderá con un Reconocimiento de Opción (OACK). Cada opción que el servidor reconozca, y acepte su valor, se incluirá en el paquete OACK. Algunas opciones pueden variar sus valores tal como estaban propuestos, pero esto es una característica especifica de esa opción. El servidor no colocará en el OACK cualquier opción que no haya sido específicamente pedida por el cliente; esto quiere decir, que únicamente el cliente puede iniciar la negociación de opciones. Las opciones que el servidor no soporta, simplemente las omitirá en el OACK; y esto no generará un paquete de error. Si el valor de una opción soportada es inválido en la especificación de esa opción, tendrá que indicar como debe actuar el servidor: no colocará el reconocimiento en el OACK, o responderá con un valor alternativo, o bien enviará un paquete de ERROR con código 8 para terminar la transferencia. Cualquier opción que no se ha reconocido por el servidor, será ignorada por el cliente, y el servidor hará como si nunca se la hubieran pedido. Si se piden múltiples opciones, el cliente usará de estas opciones las que hayan sido reconocidas por el servidor, y no usará aquellas que no se hubieran reconocido por dicho servidor. Cuando el cliente añade opciones al final de los paquetes de petición de lectura, aparecerá una de las siguientes respuestas devueltas por el servidor: .in 6 OACK - reconocimiento de la petición de lectura y las opciones; DATOS – reconocimiento de una petición de lectura sin opciones; ERROR – la petición ha sido denegada. .in 3 Cuando el cliente añade opciones al final de los paquetes de petición de escritura, aparecerá una de las siguientes respuestas devueltas por el servidor: .in 6 OACK - reconocimiento de la petición de escritura y las opciones; ACK - reconocimiento de una petición de escritura sin opciones; ERROR – la petición ha sido denegada. .in 3 Si un servidor no tiene implementada la negociación de opciones, ignorará cualquiera de ellas que estén añadidas a la petición del cliente. En este caso el servidor devolverá un paquete de DATOS a una petición de lectura o un ACK a una petición de escritura, que es el comportamiento normal de una transferencia TFTP. En el caso que el servidor devuelva un error a una petición que transporta una opción, el cliente podrá intentar repetir esa petición, pero sin añadir las opciones. Esta implementación de opciones podría hacer que el servidor considerará datos extraños en el paquete de petición y por lo tanto erróneos. El cliente tiene dos maneras de valorar la aceptación del paquete de OACK del servidor, dependiendo cómo se realizó la petición de transferencia original. Si la transferencia se inició con una Petición de Lectura, entonces se enviará un ACK (con el número de bloque puesto a 0) al cliente para que confirme los valores en el paquete OACK del servidor. En cambio si la transferencia se inició con un Paquete de Escritura, entonces el cliente empezará la transferencia con el primer paquete de DATOS, usando los valores negociados. Si el cliente no admite el OACK, enviará un paquete de ERROR, con el código 8 hacia el servidor para terminar la transferencia. Una vez que el cliente reconoce un OACK, con una respuesta apropiada sin error, podrá usar solo las opciones devueltas por el servidor con los valores que dicho cliente está de acuerdo. Recuerde que el servidor no puede realizar una petición de opción; solo puede responder a ella. Si el cliente recibe un OACK que contenga una opción no pedida, debe responder con un paquete de ERROR con el código 8 y terminar la transferencia. .ti 0 Ejemplos Petición de Lectura .in 6 .KS cliente servidor ------------------------------------------------------- |1|foofile|0|octeto|0|blksize|0|1432|0| --> RRQ <-- |6|blksize|0|1432|0| OACK |4|0| --> ACK <-- |3|1| 1432 octetos de datos | DATA |4|1| --> ACK <-- |3|2| 1432 octetos de datos | DATA |4|2| --> ACK <-- |3|3|<1432 octetos de datos | DATA |4|3| --> ACK .in 3 Petición de Escritura .in 6 cliente servidor ------------------------------------------------------- |2|barfile|0|octeto|0|blksize|0|2048|0| --> RRQ <-- |6|blksize|0|2048|0| OACK |3|1| 2048 octetos de datos | --> DATA <-- |4|1| ACK |3|2| 2048 octetos de datos | --> DATA <-- |4|2| ACK |3|3|<2048 octetos de datos | --> DATA <-- |4|3| ACK .KE .in 3 .ti 0 Consideraciones de seguridad El protocolo TFTP básico no posee mecanismos de seguridad. Esto es así porque no tiene capacidad de renombrar, borrar o sobre escribir archivos. Este documento no añade ningún tipo de seguridad al TFTP; de todas maneras esta especificación de la negociación de opciones tampoco añade ningún riesgo adicional de seguridad. .ti 0 Referencias .RS .IP [1] 4 Sollins, K., "El protocolo TFTP (Revisión 2)", STD 33, RFC 1350, MIT, octubre 1992. .IP [2] 4 Malkin, G., and A. Harkin, "Opción del tamaño de Bloque para TFTP", RFC 2348, Xylogics, Inc., Hewlett Packard Co., Mayo 1998. .IP [3] 4 Malkin, G., and A. Harkin, A., "Opciónes de exceso de Tiempo y Tamaño de Archivo para TFTP", RFC 2349, Xylogics, Inc., Hewlett Packard Co., Mayo 1998. .RE .hy 0 .nf .in 3 .ti 0 Dirección de los autores Gary Scott Malkin Bay Networks 8 Federal Street Billerica, MA 01821 Phone: (978) 916-4237 EMail: gmalkin@baynetworks.com Art Harkin Internet Services Project Information Networks Division 19420 Homestead Road MS 43LN Cupertino, CA 95014 Phone: (408) 447-3755 EMail: ash@cup.hp.com .ti 0 Traductor: Gabriel Ortí i Flores Barcelona .fi .bp .ti 0 Declaración completa sobre los Derechos de la propiedad intelectual Derechos de la propiedad intelectual (C) La Sociedad de Internet (1998). Todos los derechos reservados. Puede copiarse este documento y/o sus traducciones, también pueden ser añadidos a otros documentos, y se pueden elaborar trabajos derivados que añadan o por otra parte expliquen o ayuden en su aplicación para ser, copiadas, publicadas y distribuidas, totalmente o en parte, sin restricción de ningún tipo, siempre y cuando se incluyan de forma íntegra el aviso de copyright anterior y este párrafo en todas las copias y los trabajos derivados. Por lo tanto, este documento no puede modificarse de forma alguna, quitando el aviso del derecho de la propiedad intelectual o referencias a la La Sociedad de Internet u otras organizaciones de Internet, excepto cuando sea necesario debido al desarrollo de estándares de Internet y en ese caso deben seguirse los procedimientos para los derechos de la propiedad intelectual definidos en los estándares de Internet, o según se requiera cuando se traduzca a otras lenguas distintas del inglés Los permisos concedidos limitados lo son a perpetuidad y no se revocarán por La Sociedad de Internet, sus sucesores o concesionarios. Este documento y la información contenida en él se proporcionan "TAL CUAL" LA SOCIEDAD DE INTERNET Y LA DIVISIÓN DE INGENIERIA DE INTERNET DECLINAN TODAS LAS GARANTÍAS, EXPRESAS O IMPLÍCITAS, INCLUYENDO PERO NO LIMITANDO A CUALQUIER GARANTÍA QUE EN EL USO DE LA INFORMACIÓN CONTENIDA NO SE INFRINGIRÁ NINGÚN DERECHO O CUALQUIER GARANTÍA IMPLÍCITA DE COMERCIALIZACIÓN O LA APTITUD PARA UN PROPÓSITO PARTICULAR. ---------------------------------------------------- Para darse de baja RFC-ES pincha y envia el siguiente url mailto:rfc-es-signoff-request@listserv.rediris.es ----------------------------------------------------