Red Grupo de Trabajo K. Sollins 
 Petición de Comentarios: 1350 MIT 
 ETS: 33 Julio 1992 
 Obsoletes: RFC 783 
                      EL PROTOCOLO TFTP (REVISIÓN 2) 

 Condición de este Memo 

    Este RFC especifica un IAB de normas de protocolo para Internet 
    Comunidad, y pide a la discusión y propuestas de mejoras. 
    Por favor refiérase a la edición actual del "Protocolo Oficial IAB 
    Normas "para la normalización de la situación y la condición de este protocolo. 
    La distribución de este memo es ilimitada. 

 Resumen 

    TFTP es un protocolo muy sencillo utiliza para transferir archivos. Es de 
    Esta que viene su nombre, Trivial File Transfer Protocol o TFTP. 
    Cada paquete nonterminal es reconocido por separado. Este documento 
    Describe el protocolo y sus tipos de paquetes. El documento también 
    Explican las razones de algunas de las decisiones de diseño. 

 Acknowlegements 

    El protocolo fue diseñado originalmente por Noel Chiappa, y se 
    Rediseñado por él, Bob Baldwin y Dave Clark, con comentarios de 
    Steve Szymanski. La actual revisión del documento incluye 
    Modificaciones resultantes de los debates y con las sugerencias de los 
    Larry Allen, Noel Chiappa, Dave Clark, Geoff Cooper, Mike Greenwald, 
    Liza Martin, David Reed, Craig Milo Rogers (de la USC-ISI), Kathy 
    Yellick, y el autor. El reconocimiento y la retransmisión 
    Régimen se inspiró en TCP, y el error fue sugerido por el mecanismo 
    PARC EFTP abortar el mensaje. 

    La de mayo, revisión de 1992 para arreglar el "Sorcerer's Apprentice" protocolo 
    Bug [4] y otros problemas menores documento fue hecho por Noel Chiappa. 

    Esta investigación fue apoyada por la Agencia de Proyectos de Investigación Avanzada 
    Del Departamento de Defensa y fue supervisado por la Oficina de Naval 
    Investigación bajo contrato número N00014-75-C-0661. 

 1. Propósito 

    TFTP es un protocolo simple para transferir archivos, y, por tanto, fue nombrado 
    El Trivial File Transfer Protocol o TFTP. Se ha aplicado 
    En la parte superior de la Internet User Datagram protocolo (UDP o Datagram) [2] 

 Sollins [Página 1] 
 
 RFC 1350 TFTP Revisión 2 Julio 1992 
    Así que se puede utilizar para mover archivos entre máquinas en diferentes 
    La aplicación de las redes de UDP. (Esto no debería excluir la posibilidad 
    De la aplicación de TFTP en la parte superior de otros protocolos datagrama.) Es 
    Diseñado para ser pequeño y fácil de aplicar. Por lo tanto, carece de la mayoría 
    De las características de un FTP. Lo único que puede hacer es leer 
    Y escribir archivos (o por correo) desde / a un servidor remoto. No puede lista 
    Directorios, y en la actualidad no existen disposiciones para la autenticación de los usuarios. 
    En común con otros protocolos de Internet, que pasa de 8 bits de bytes 
    Datos. 

    Tres modos de transferencia son soportados: netascii (Esto es 
    ASCII tal como se define en "EE.UU. Código normalizado para el intercambio de información" 
    [1] con las modificaciones especificadas en el "Protocolo Telnet 
    Especificación "[3].) Tenga en cuenta que es de 8 bits ASCII. El término 
    "Netascii" se utiliza en este documento en el sentido de este 
    Particular versión de ASCII.); Octeto (Esto reemplaza el "binario" modo 
    De las versiones anteriores de este documento). Cruda de 8 bits de bytes; mail, 
    Netascii caracteres enviados a un usuario en lugar de un archivo. (El correo 
    Modo es obsoleto y no debería aplicarse o utilizarse.) Adicional 
    Modos pueden ser definidos por los pares de cooperar anfitriones. 

    Referencia [4] (sección 4.2) hay que consultar para más valiosa 
    Directrices y sugerencias sobre TFTP. 

 2. Descripción del Protocolo 

    Cualquier transferencia comienza con una solicitud para leer o escribir un archivo, que 
    También sirve para solicitar una conexión. Si el servidor concede el 
    Solicitud, la conexión se abre y el archivo se envía en fijo 
    Longitud de los bloques de 512 bytes. Cada paquete de datos contiene un bloque de 
    Datos, y debe ser reconocido por un reconocimiento antes de que el paquete 
    Próximo paquete puede ser enviado. Un paquete de datos de menos de 512 bytes 
    Señales de terminación de una transferencia. Si un paquete se pierde en la 
    Red, el destinatario tendrá timeout y podrá retransmitir su 
    Último paquete (que puede ser de datos o un reconocimiento), causando así 
    El remitente de los paquetes perdidos que perdieron a retransmitir paquetes. El 
    Remitente tiene que mantener sólo un paquete en la mano para la retransmisión, ya que 
    El bloqueo de paso reconocimiento garantiza que todos los paquetes tienen más edad 
    Ha recibido. Note que las dos máquinas involucradas en una transferencia son 
    Considera emisores y receptores. Uno de los datos envía y recibe 
    Reconocimientos, los otros reconocimientos envía y recibe los datos. 

    La mayoría de los errores causa de terminación de la conexión. Un error es 
    Manifestado mediante el envío de un paquete de error. Esta bolsa no es 
    Reconocido, y no volvió (es decir, un servidor TFTP o usuario puede 
    Después de terminar el envío de un mensaje de error), de modo que el otro extremo de la 
    Conexión no podrá obtenerlo. Por lo tanto tiempos se utilizan para detectar 
    Tal terminación cuando el paquete de error se ha perdido. Los errores se 

 Sollins [Página 2] 
 
 RFC 1350 TFTP Revisión 2 Julio 1992 
    Causada por tres tipos de eventos: no poder satisfacer las 
    Solicitud (por ejemplo, no se encuentra el archivo, el acceso violación, o no usuario de este tipo), 
    Recibir un paquete que no se puede explicar por un retraso o 
    La duplicación de la red (por ejemplo, un paquete formado incorrectamente), y 
    Perder el acceso a un recurso necesario (por ejemplo, el disco o el acceso pleno 
    Negó durante un traslado). 

    TFTP reconoce únicamente una condición de error que no causa 
    Terminación, el puerto fuente de un paquete que se recibió incorrecta. 
    En este caso, un paquete de error se envía a la originarios de acogida. 

    Este protocolo es muy restrictiva, con el fin de simplificar 
    Aplicación. Por ejemplo, la longitud fija que la asignación de bloques 
    Fácilmente, y el bloqueo de paso acuse proporciona corriente 
    Control y elimina la necesidad de reordenar los paquetes de datos. 

 3. Relación con otros protocolos 

    Como se mencionó TFTP está diseñado para ser aplicado en la parte superior de la 
    Protocolo de datagrama (UDP). Desde Datagram se aplica en la 
    Protocolo de Internet, los paquetes de Internet tendrá una cabecera, una Datagram 
    Cabecera, y una cabecera de TFTP. Además, los paquetes pueden tener un 
    Cabecera (LNI, cabecera ARPA, etc) para que a través de los locales 
    El medio de transporte. Como se muestra en la Figura 3-1, el orden de los contenidos 
    De un paquete será: locales de mediano cabecera, si se utilizan, Internet cabecera, 
    Datagrama cabecera, TFTP cabecera, seguido por el resto de la TFTP 
    Paquete. (Esto puede ser o no de datos, dependiendo del tipo de paquete 
    Tal como se especifica en la cabecera de TFTP.) TFTP no especifica ninguna de las 
    Valores en el encabezado de Internet. Por otro lado, la fuente y el 
    Puerto de destino los campos de la cabecera Datagram (su formato es dado 
    En el apéndice) es usada por TFTP y el campo de longitud refleja la 
    Tamaño de los paquetes de TFTP. La transferencia de los identificadores (TID), utilizados por 
    TFTP se pasan a la capa Datagram a ser utilizados como los puertos, por lo que 
    Que debe estar entre 0 y 65.535. La inicialización de TID's es 
    Examina en la sección de protocolo de conexión inicial. 

    El TFTP cabecera consiste en un campo de 2 bytes que indica opcode 
    El paquete del tipo (por ejemplo, DATOS, ERROR, etc) Estos opcodes y la 
    Formatos de los diversos tipos de paquetes se analizan con más detalle en el 
    Sección sobre los paquetes TFTP. 

 Sollins [Página 3] 
 
 RFC 1350 TFTP Revisión 2 Julio 1992 
           -------------------------------------------------- -- 
          | Local Media | Internet | Datagram | TFTP | 
           -------------------------------------------------- -- 

                       Figura 3-1: Orden de las Cabeceras 
 4. Protocolo de conexión inicial 

    Una transferencia se establece mediante el envío de una solicitud (WRQ a escribir en una 
    Exterior del sistema de archivos, o RRQ a leer de ella), y recibir un 
    Respuesta positiva, un reconocimiento de escritura de paquetes, o los primeros datos 
    De paquetes para leer. En general un reconocimiento paquete contendrá 
    El bloque número de los paquetes de datos que se reconoce. Cada uno de los datos 
    Paquete está asociada con un bloque número; bloque de los números 
    Consecutivos, y empezar con uno. Dado que la respuesta positiva a una 
    De escritura es un reconocimiento de paquetes, en este caso especial la 
    Bloque número será cero. (Normalmente, desde un reconocimiento de paquetes 
    Es reconocer un paquete de datos, el reconocimiento se sobrecito 
    Contener el número del bloque de paquete de datos que se reconoce.) Si 
    La respuesta es un paquete de error, a continuación, la solicitud ha sido denegada. 

    Con el fin de crear una conexión, cada extremo de la conexión elige un 
    TID por sí mismo, que se utilizarán para la duración de esa conexión. El 
    TID escogidas para una conexión debe ser escogido de forma aleatoria, a fin de que la 
    Probabilidad de que el mismo número es elegido dos veces en inmediata 
    La sucesión es muy bajo. Cada paquete está asociada con las dos 
    TID's de los extremos de la conexión, la fuente y el TID 
    TID destino. Estos son TID del apoyo entregado a la UDP (o 
    Otro protocolo de datagrama) como origen y destino los puertos. A 
    Requirente anfitrión elige su fuente TID como se ha descrito anteriormente, y envía 
    Su solicitud inicial de la conocida TID 69 decimal (105 octal) en la 
    Servicio de acogida. La respuesta a la solicitud, bajo condiciones normales de operación, 
    Utiliza un TID elegido por el servidor como su fuente TID y el TID elegido 
    Para el mensaje anterior por el solicitante como su destino TID. 
    Los dos elegidos del TID se utilizan para el resto de la transferencia. 

    A modo de ejemplo, la siguiente muestra los pasos para crear un 
    Conexión para escribir un archivo. Tenga en cuenta que WRQ, ACK, y son los DATOS 
    Nombres de la petición de escritura, reconocimiento, y tipos de datos de paquetes 
    Respectivamente. El apéndice contiene un ejemplo similar para leer un 
    Archivo. 

 Sollins [Página 4] 
 
 RFC 1350 TFTP Revisión 2 Julio 1992 
       1. Host A envía una "WRQ" para acoger con B = Una fuente del TID, 
          Destino = 69. 

       2. Host B envía un "ACK" (con número de bloques = 0) a un anfitrión con 
          Fuente = B's TID, destino = A del TID. 

    En este punto la conexión se ha establecido y los primeros datos 
    Paquete puede ser enviado por un host con un número de secuencia de 1. En la 
    Siguiente paso, y en todos los pasos sucesivos, los conductores deben asegurarse de 
    TID que la fuente coincide con el valor que se acordó en los pasos 1 
    Y 2. Si una fuente no coincide con TID, el paquete debe ser 
    Descartado como erróneamente enviado desde algún otro sitio. Un paquete de error 
    Debe ser enviada a la fuente de los paquetes incorrecta, en tanto que no 
    Inquietante la transferencia. Esto se puede hacer sólo si el TFTP en el hecho de 
    Recibe un paquete con una incorrecta TID. Si el apoyo a los protocolos 
    No lo permite, esta condición de error no se plantean. 

    El siguiente ejemplo demuestra el correcto funcionamiento de las 
    Protocolo en el que la situación anterior puede ocurrir. Host A envía un 
    Petición al anfitrión B. En algún lugar de la red, el paquete de solicitud es 
    Duplicada, y como resultado dos reconocimientos son devueltos al anfitrión 
    A, con diferentes TID escogidas de acogida B en respuesta a los dos 
    Solicitudes. Cuando llega la primera respuesta, continúa el anfitrión de un 
    Conexión. Cuando la segunda respuesta a la solicitud que llega, 
    Debe ser rechazado, pero no hay razón para terminar la primera 
    Conexión. Por lo tanto, si es diferente del TID son elegidos para los dos 
    Conexiones de host B, y un anfitrión de los controles de la fuente de la TID 
    Los mensajes que recibe, en la primera relación se puede mantener al mismo tiempo 
    La segunda es rechazada por regresar un paquete de error. 

 5. Paquetes TFTP 

    TFTP admite cinco tipos de paquetes, todas las cuales se han mencionado 
    Anteriormente: 

           Opcode operación 
             1 Lea petición (RRQ) 
             2 Escriba solicitud (WRQ) 
             3 Datos (DATA) 
             4 Reconocimiento (ACK) 
             5 de error (ERROR) 

    El TFTP cabecera del paquete contiene el opcode asociados con 
    Ese paquete. 

 Sollins [Página 5] 
 
 RFC 1350 TFTP Revisión 2 Julio 1992 
             2 bytes cadena 1 byte cadena 1 byte 
             ------------------------------------------------ 
            | Opcode | Nombre de archivo | 0 | Modo | 0 | 
             ------------------------------------------------ 

                        Figura 5-1: RRQ / WRQ paquete 
    RRQ y WRQ paquetes (opcodes 1 y 2, respectivamente) tienen el formato 
    Muestra en la Figura 5-1. El nombre de archivo es una secuencia de bytes en 
    Netascii terminarse con un byte nulo. El modo de campo contiene el 
    Cadena "netascii", "octet", o "mail" (o cualquier combinación de mayúsculas 
    Y minúsculas, como "NETASCII", NetAscii ", etc) en netascii 
    Indicando las tres modalidades definidas en el protocolo. Un anfitrión que 
    Recibe datos en modo netascii debe traducir los datos a su propio 
    Formato. Octeto modo se utiliza para transferir un archivo que se encuentra en la de 8 bits 
    Formato de la máquina desde la que el archivo está siendo transferido. Es 
    Se supone que cada tipo de máquina tiene un único formato de 8 bits que 
    Es más común, y que el formato que se elija. Por ejemplo, en un 
    DEC-20, una máquina de 36 bits, esto es de cuatro octetos de 8 bits para una palabra con 
    Cuatro bits de rotura. Si un host recibe un octeto de archivo y, a continuación, 
    Retornos, el archivo debe ser devuelto idéntica a la original. 
    Correo modo utiliza el nombre de un destinatario de correo en lugar de un archivo y 
    Debe comenzar con un WRQ. De lo contrario, es idéntico al modo netascii. 
    El receptor de correo cadena debería tener el formato "nombre de usuario" o 
    "Nombre de usuario @ nombre de host". Si la segunda forma se utiliza, permite la 
    Opción de reenvío de mensajes por un relé de equipo. 

    La discusión anterior asume que tanto el remitente y el receptor son 
    Que operan en el mismo modo, pero no hay razón por la que esto tiene que 
    Ser el caso. Por ejemplo, se puede construir un servidor de almacenamiento. No 
    No es razón que esa máquina tiene que traducir en su netascii 
    Propia forma de texto. Más bien, el remitente puede enviar archivos en netascii, 
    Pero el servidor de almacenamiento puede simplemente almacenarlos sin traducción en 
    Formato de 8 bits. Otro tal situación es un problema que en la actualidad 
    Existe sobre los sistemas DEC-20. Ni netascii octeto ni todos los accesos 
    Los bits en una palabra. Se podría crear un modo especial para tal 
    Máquina que lee todos los bits en una palabra, pero en el que el receptor 
    Almacena la información en formato de 8 bits. Cuando este archivo es 
    Obtenerse en el sitio de almacenamiento, debe ser devuelta a su antiguo 
    Formulario para ser útil, por lo que el modo de invertir también deben ser aplicadas. El 
    Sitio, el usuario tiene que recordar alguna información para lograrlo. En 
    Estos dos ejemplos, la petición de los paquetes se especifica el modo de octeto 
    Al extranjero, pero el equipo local estaría en algún otro modo. 
    No existe el equipo o la aplicación específica modos se han especificado en 
    TFTP, pero sería compatible con esta especificación. 

    También es posible definir otras modalidades de cooperación de pares 

 Sollins [Página 6] 
 
 RFC 1350 TFTP Revisión 2 Julio 1992 
    Hosts, aunque esto debe hacerse con cuidado. No se exige 
    Que cualquier otra aplicación de estos hosts. No existe una autoridad central 
    Que se definen estos modos o asignarles nombres. 
                    2 bytes 2 bytes n bytes 
                    ---------------------------------- 
                   | Opcode | Block # | Datos | 
                    ---------------------------------- 

                         Figura 5-2: DATOS paquete 
    Los datos se transfiere en paquetes DATOS muestra en la Figura 5-2. 
    DATOS paquetes (opcode = 3) tener un número de bloque y los datos de campo. El 
    Bloque de números en paquetes de datos y comenzar con un aumento de un por 
    Cada nuevo bloque de datos. Esta restricción permite que el programa para utilizar una 
    Solo número para discriminar entre paquetes nuevos y duplicados. 
    El campo de datos es de cero a 512 bytes de longitud. Si se trata de 512 bytes 
    De largo, el bloque no es el último bloque de los datos, si es de cero a 
    511 bytes de longitud, que señala el final de la transferencia. (Vea la sección 
    En la terminación normal para obtener más información.) 

    Todos los paquetes que no sean duplicados y ACK de los utilizados para 
    Terminación se reconoce a menos que se produce un aviso de tiempo [4]. El envío de una 
    DATOS paquete es un reconocimiento para el primer paquete ACK de la 
    DATOS paquete anterior. El WRQ DATOS paquetes y son reconocidos por 
    ERROR o paquetes ACK, mientras RRQ 
                          2 bytes 2 bytes 
                          --------------------- 
                         | Opcode | Block # | 
                          --------------------- 

                          Figura 5-3: paquete ACK 
    Y paquetes ACK son reconocidos por ERROR DE DATOS o paquetes. Figura 
    5-3 describe una de paquetes ACK, el opcode es de 4. El número de bloques en 
    Un ACK se hace eco de la manzana número de los paquetes que se DATOS 
    Bibliográfica. A WRQ se reconoce con un paquete con un ACK 
    Número de bloque cero. 
 Sollins [Página 7] 
 
 RFC 1350 TFTP Revisión 2 Julio 1992 
                2 bytes 2 bytes cadena 1 byte 
                ----------------------------------------- 
               | Opcode | ErrorCode | ErrMsg | 0 | 
                ----------------------------------------- 

                         Figura 5-4: ERROR paquete 
    Un paquete de ERROR (opcode 5) toma la forma representada en la Figura 5-4. Un 
    ERROR paquete puede ser el reconocimiento de cualquier otro tipo de paquete. 
    El código de error es un entero indicando la naturaleza del error. A 
    Tabla de valores y significados se da en el apéndice. (Tenga en cuenta que 
    Varios códigos de error se han añadido a esta versión de esta 
    Documento.) El mensaje de error se destina al consumo humano, y 
    Debe estar en netascii. Al igual que todas las demás cadenas, que se pone término con 
    Un cero byte. 

 6. La terminación normal 

    El final de una transferencia se caracterizó por un paquete que contiene DATOS 
    Entre 0 y 511 bytes de datos (es decir, Datagram longitud <516). Este 
    Paquete es reconocido por un paquete ACK DATOS igual que todos los demás paquetes. 
    El anfitrión de la final reconoce DATOS paquete puede terminar su lado 
    De la conexión en el último envío de ACK. Por otra parte, 
    Dallying se alienta. Esto significa que el anfitrión de enviar el final 
    ACK esperará por un tiempo antes de dar por terminado el fin de retransmitir 
    El último ACK si se ha perdido. El sabrá que acknowledger 
    El ACK se ha perdido si recibe el paquete final DATOS nuevo. 
    El anfitrión de la última DATOS envío debe retransmitir el paquete hasta que se 
    Reconoció el envío o de acogida veces. Si la respuesta es un 
    ACK, la transmisión se ha completado correctamente. Si el remitente de 
    Los datos agota el tiempo de espera y no está dispuesta a retransmitir más, la 
    Transferencia todavía se han completado con éxito, después de que la 
    Acknowledger o de la red pueden haber experimentado un problema. También es 
    Posible en este caso que la transferencia no se ha realizado correctamente. En cualquier 
    Caso, la conexión se ha cerrado. 

 7. La terminación prematura 

    Si la petición no se puede conceder, o algún error que se produce durante la 
    Transferencia, en ese momento un paquete de ERROR (opcode 5) es enviada. Esta es sólo una 
    Cortesía, dado que no será retransmitido o reconocido, por lo que 
    Nunca podrá ser recibido. Tiempos también debe utilizarse para detectar errores. 
 Sollins [Página 8] 
 
 RFC 1350 TFTP Revisión 2 Julio 1992 
 Apéndice I. 

 Orden de las Cabeceras 

                                                   2 bytes 
     -------------------------------------------------- -------- 
    | Local Media | Internet | Datagram | TFTP Opcode | 
     -------------------------------------------------- -------- 

 TFTP Formatos 

    Tipo Op # Formato sin cabecera 

           2 bytes cadena 1 byte cadena 1 byte 
           ----------------------------------------------- 
    RRQ / | 01/02 | Nombre de archivo | 0 | Modo | 0 | 
    WRQ ----------------------------------------------- 
           2 bytes 2 bytes n bytes 
           --------------------------------- 
    DATOS | 03 | Block # | Datos | 
           --------------------------------- 
           2 bytes 2 bytes 
           ------------------- 
    ACK | 04 | Block # | 
           -------------------- 
           2 bytes 2 bytes cadena 1 byte 
           ---------------------------------------- 
    ERROR | 05 | ErrorCode | ErrMsg | 0 | 
           ---------------------------------------- 

 Protocolo de conexión inicial de la lectura de un archivo 

    1. Host A envía una "RRQ" para acoger con B = Una fuente del TID, 
       Destino = 69. 

    2. Host B envía un "DATOS" (con número de bloques = 1) a los anfitriones con un 
       Fuente = B's TID, destino = A del TID. 


 Sollins [Página 9] 
 
 RFC 1350 TFTP Revisión 2 Julio 1992 
 Códigos de error 

    Valor Significado 

    0 No definido, véase el mensaje de error (si la hay). 
    1 No se encuentra el archivo. 
    2 Disponibilidad violación. 
    3 de disco completo o la asignación superado. 
    4 TFTP ilegal operación. 
    5 Desconocida transferencia ID. 
    6 de fichero ya existe. 
    7 Este usuario no existe. 

 Internet User Datagram cabecera [2] 

    (Esto se ha incluido sólo por conveniencia. TFTP no será necesario 
    Aplicado en la parte superior de la Internet User Datagram Protocolo.) 

      Formato 

     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 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+ 
    | Puerto de Origen | Puerto de destino | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+ 
    | Longitud | Checksum | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+ 
    Los valores de Campos 
    Fuente Port de cobro por iniciador de paquete. 

    Dest. Puerto de cobro por la máquina de destino (69 por RRQ o WRQ). 

    Longitud Número de bytes en el paquete UDP, UDP incluyendo la cabecera. 

    Checksum de referencia 2 describe las normas para el cálculo de comprobación. 
                    (El implementador de este debe estar seguro de que la 
                    Algoritmo utilizado es correcto aquí.) 
                    Campo contiene cero en caso de no utilización. 

    Nota: TFTP pasa transferencia identificadores (TID) a Internet del usuario 
    Datagrama de protocolo que se utilizará como origen y destino los puertos. 
 Sollins [Página 10] 
 
 RFC 1350 TFTP Revisión 2 Julio 1992 
 Referencias 

    [1] EE.UU. Código normalizado para el intercambio de información, USASI X3.4-1968. 

    [2] Postel, J., "User Datagram Protocolo", RFC 768, USC / Información 
         Instituto de Ciencias, el 28 de agosto de 1980. 

    [3] Postel, J., "Protocolo de Especificaciones Telnet", RFC 764, 
         USC / Instituto de Ciencias de la Información, junio, 1980. 

    [4] Braden, R., Editor, "Requisitos para hosts de Internet -- 
         Aplicación y Apoyo ", RFC 1123, USC / Ciencias de la Información 
         Instituto, de octubre de 1989. 

 Consideraciones de Seguridad 

    Desde TFTP o de acceso no incluye mecanismos de control de acceso, la atención debe 
    Se han de adoptar en los derechos concedidos a un servidor TFTP proceso a fin de no 
    Violar la seguridad del sistema de servidor de archivo de hosts. TFTP es a menudo 
    Con los controles instalados de tal manera que sólo los archivos que han leído público 
    El acceso se encuentran disponibles a través de TFTP y escritura de archivos a través de TFTP es 
    Desestima. 

 Dirección del autor 

    Karen R. Sollins 
    Instituto de Tecnología de Massachusetts 
    Laboratorio de Ciencias de la Computación 
    545 Plaza de Tecnología 
    Cambridge, MA 02139-1986 

    Teléfono: (617) 253-6006 

    EMail: SOLLINS@LCS.MIT.EDU 

 Sollins [Página 11]