Network Working Group G. Malkin Request for Comments: 1207 FTP Software, Inc. FYI: 7 A. Marine SRI J. Reynolds ISI Febrero 1991 FYI sobre Preguntas y Respuestas Respuestas a Preguntas Hechas Frecuentemente por "Usuarios de Internet Experimentados" Condición de este Memorándum Este RFC FYI es uno de los dos FYI denominados "Preguntas y Respuestas" (P/R), hechos por el Grupo de Trabajo de Servicios de Usuario de la Fuerza de Trabajo de Internet (IETF). El objetivo es documentar la mayoría de las preguntas hechas frecuentemente en Internet. Este memorándum proporciona información para la comunidad de Internet. No especifica ningún estándar de Internet. La distribución de este memorándum es ilimitada. Tabla de Contenidos 1. Introducción.................................................... 1 2. Agradecimientos................................................. 3 3. Preguntas Sobre Internet........................................ 3 4. Preguntas Sobre otras Redes e Inter-redes....................... 3 5. Preguntas Sobre Documentación de Internet....................... 4 6. Preguntas Sobre el Sistema de Nombre de Dominio (DNS)........... 4 7. Preguntas Sobre Mantenimiento de Red............................ 7 8. Preguntas Sobre Protocolo de Internet por Linea Serie (SLIP) e Implementaciones del Protocolo Punto-a-Punto(PPP)............... 9 9. Preguntas Sobre Enrutamiento.................................... 11 10. Preguntas sobre Otros Protocolos e Implementación de Estándares 11 11. Lecturas Recomendadas.......................................... 12 12. Referencias.................................................... 13 13. Consideraciones de Seguridad................................... 14 14. Direcciones de los Autores..................................... 15 1. Introducción Durante los últimos meses, varias personas han monitoreado varias grandes listas de correo y han extraído preguntas que son importantes G. Malkin [Pág. 1] RFC 1207 FYI P/R - Para Usuarios de Internet ExperimentadosFebrero 1991 o hechas frecuentemente. Este RFC FYI es uno de los dos en la serie FYI que presenta las preguntas y sus respuestas. El primer FYI, FYI 4, mostraba preguntas que los nuevos usuarios de Internet hacen frecuentemente y sus respuestas. G. Malkin [Pág. 2] RFC 1207 FYI P/R - Para Usuarios de Internet ExperimentadosFebrero 1991 El objetivo de este FYI es codificar la enseñanza de Internet a fin de que el personal de operaciones de red, especialmente para redes que se acaban de unir a Internet, tengan un conjunto de referencias preciso y actualizado con la que trabajar. Además, las redundancias son sacadas de las listas de correo electrónico y de esta manera los suscriptores de la lista no tienen que leer las mismas dudas y respuestas una y otra vez. Aunque las preguntas y sus respuestas están sacadas de varias listas de correo, aquí están presentadas agrupadas aproximadamente por temas relacionados para su fácil lectura. Primero se expone la pregunta, detrás la respuesta (o respuestas) como aparecían en la lista de correo. A veces las respuestas son abreviadas para un mejor uso del espacio. Si una pregunta no fue contestada en la lista de correo, los editores dan una respuesta. Estas respuestas no se distinguen de las encontradas en las listas. A veces, al intentar ser tan completa como sea posible, los editores dan información adicional que no estaba presente en la respuesta original. Si es así, esa información aparece bajo el encabezado "Información Adicional". Las respuestas son tan correctas como los revisores pueden hacerlas. Sin embargo, mucha de esta información cambia con el tiempo. A medida que el FYI sea actualizado, los errores temporales serán corregidos. Algunas de estas preguntas están en primera persona, y las respuestas estaban dirigidas al remitente de la pregunta. Estas frases no han sido cambiadas más que donde era necesario por claridad. Las referencias a los nombres correspondientes han sido borradas. Las listas de correo de P/R son mantenidas por Gary Malkin en FTP.COM. Son usadas por un subgrupo del Grupo de Trabajo de Servicios de Usuario para discutir los FYIs P/R. Incluyen: quail@ftp.com Esta es una lista de discusión. Su principal uso es para la revisión pre-liberación de los FYIs P/R. quail-request@ftp.com Esto es cómo unirte a la lista de correo quail. quail-box@ftp.com Esto es donde las preguntas y respuestas serán emitidas-y-almacenadas. No es necesario estar en la lista de correo quail para escribir al buzón quail. G. Malkin [Pág. 3] RFC 1207 FYI P/R - Para Usuarios de Internet ExperimentadosFebrero 1991 2. Agradecimientos Las siguientes personas se merecen las gracias por su ayuda y aportaciones a este FYI P/R: Jim Conklin (EDUCOM), John C. Klensin (MIT), Professor Kynikos (Consultante Especial), Jon Postel (ISI), Marshall Rose (PSI, Inc.), David Sitman (Tel Aviv University), Patricia Smith (Merit), Gene Spafford (Purdue), y James Van Bokkelen (FTP Software, Inc.). 3. Preguntas sobre Internet 3.1. ¿Como obtengo estadísticas mirando el tráfico en NSFNET? Los Servicios Informativos de Merit/NSFNET mantienen una variedad de datos estadísticos en 'nis.nsf.net' (35.1.1.48) en el directorio 'stats'. La información incluye la cuenta de paquetes por NSS y cuentas de bytes por tipo de uso (ftp, smtp, telnet, etc.). Los nombres de archivo son del tipo 'NSFaño-mes.tipo'. Los archivos están disponibles por ftp anónimo; use 'guest' como contraseña. Los datos de estos archivos solo representan el tráfico que recorre el nivel más alto de NSFNET, no el trafico de un campus o red regional. Envíe preguntas/comentarios a nsfnet-info@merit.edu. 4. Preguntas Sobre otras Redes e Inter-redes 4.1. Tenemos un usuario que le gustaría acceder a una máquina en "EARN/BITNET". No puedo encontrar nada sobre esto en las tablas de nombres de dominio. Por favor, ¿Qué es esto y como me conecto? Hay varias máquinas en Internet que actúan como pasarelas entre Internet y BITNET. UICVM.UIC.EDU y CUNYVM.CUNY.EDU son dos ejemplos. Puedes dirigir un mensaje de correo a usuario%nombrenodo.bitnet@uicvm.uic.edu donde el mensaje pasará de Internet a BITNET. Información Adicional: Estas mismas pasarelas, conocidas como INTERBIT en el lado de BITNET/EARN, transfieren correo desde ordenadores de esa red que soporten cabeceras de correo SMTP, a Internet. (Algunos ordenadores de BITNET/EARN todavía no soportan SMTP, que no forma parte del protocolo usado por IBM, y en general no es posible enviar correo desde estos ordenadores a través de las pasarelas a Internet.) G. Malkin [Pág. 4] RFC 1207 FYI P/R - Para Usuarios de Internet ExperimentadosFebrero 1991 BITNET y EARN son las dos mayores redes de varias cooperando que usan el conjunto de protocolos IBM RSCS/NJE, pero no se limitan a sistemas IBM. Estas redes administradas independientemente e interconectadas funcionan como una sola red mundial conectando directamente más de 3.300 ordenadores a alrededor de 1.400, mayormente de enseñanza superior y organizaciones mundiales. Esta red mundial soporta correo electrónico, incluyendo listas de correo, transferencia de archivos remitente-iniciado, y mensajes cortos "interactivos". BITNET, es usada frecuentemente (fuera de Europa) para referirse a la totalidad de la red mundial, técnicamente se refiere a esa parte en Estados Unidos, y demás sitios en otros países que están conectados a través de Estados Unidos y no tienen sus propias redes administradas separadamente cooperando. Más de 550 organizaciones en EE.UU. participan en BITNET. EARN es la Red de Investigación Académica Europea (European Academic Research Network). EARN enlaza más de 500 instituciones en Europa y varios países circundantes. BITNET y CSNET se fusionaron a nivel organizativo el 1 de Octubre de 1990, para formar CREN, la Corporación para la Red Educativa y de Investigación (Corporation for Research and Educational Networking). Sin embargo, las dos redes permanecieron separadas al mismo nivel operativo. (EARN y las otras Redes Cooperativas no se involucraron en esta fusión.) 5. Preguntas Sobre Documentación de Internet 5.1. ¿Donde obtengo información sobre solicitar documentos relativos a GOSIP? La información completa a medida que es publicada por NIST está disponible en linea en el servidor NIC.DDN.MIL como PROTOCOLS:GOSIP-ORDER-INFO.TXT. El archivo contiene indicaciones para contactar con gente, pedir direcciones, precios, y, en algunos casos, rutas en linea para varios documentos GOSIP relacionados. Además, la información de Agosto de 1990 fue publicada en un apéndice al RFC 1169, "Explicando la Función de GOSIP" [1]. 6. Preguntas Sobre el Sistema de Nombre de Dominio (DNS) 6.1. ¿Hay un Servidor DNS de Búsqueda? Actualmente, lo que usted está buscando es el servicio que el G. Malkin [Pág. 5] RFC 1207 FYI P/R - Para Usuarios de Internet ExperimentadosFebrero 1991 servidor 128.218.1.109 proporciona en el puerto 5555 - conectado a ese servidor en ese puerto, escribe un nombre de dominio totalmente válido y le responde con una dirección de internet y cierra la conexión. Lo usé cuando tenía un servidor que todavía solo tenía /etc/hosts e hice solo lo que necesitaba - que era básicamente un nslookup manual. Sin embargo, la inmensa mayoría de los usuarios lo encontrarán de forma más simple si usan un herramienta de búsqueda DNS y preguntan la DNS directamente. Esto no requiere mucha sofisticación, y permite al usuario ver como los nombres cortos son expandidos donde esté el usuario mejor que en 128.218.1.109 (dondequiera que esté). Por ejemplo, suponga que un usuario quiere buscar la dirección de un nombre de dominio totalmente válido "X.MISKATONIC.EDU", y además ver que servidor y dirección son usados cuando escribe "Z" como nombre de servidor. Suponiendo que el usuario está en un servidor UNIX y tiene una copia del programa dig, escribe: dig x.miskatonic.edu y dig z y las respuestas aparecerán. Ahora usted está en camino de llegar a ser un experto en DNS. Hay otras alternativas UNIX, p.ej., nslookup, y programas similares para sistemas no UNIX. Su gurú de DNS local seguramente tiene una o más de estas herramientas, y aunque a veces están guardadas al público, son realmente bastante fáciles de usar para casos sencillos. 6.2. Hemos estado teniendo un fallo BIND frecuente en nuestros VAX y Solbourne que es rastreado a un dominio TCP solicitado desde un nombre de servidor IBM NSMAIN corriendo en modo caché (las solicitudes UDP no causan este problema, aunque normalmente es una resolución UDP que está activa por encima del fallo -- esta resolución es una víctima inocente). He descubierto que algo está podando las zonas estropeadas (a veces tal como está siendo usado recursivamente en una resolución). Además, ocasionalmente el descriptor socket/archivo para la conexión TCP es cambiado a accesos inválidos causando una respuesta de fallo de escritura (Aunque esto no es fatal necesariamente,y el resto de la estructura aparentemente no es alterada). ¿Alguien más ha tenido frecuentes fallos BIND (especialmente en los sitios de mayor dominio que tienen dominios TCP de carga G. Malkin [Pág. 6] RFC 1207 FYI P/R - Para Usuarios de Internet ExperimentadosFebrero 1991 pesada)? En ambos el caso de BIND y la implementación de IBM, a veces denominada FAL, hay múltiples versiones, con versiones más antiguas siendo malas de verdad. Además actualice a la versión actual antes de explorar. BIND siempre ha tenido problemas con contaminar su propia base de datos. Estos problemas han sido relativos a conexiones TCP, NS RRs con TTLs pequeños, y otras causas variadas. La experiencia sugiere que la forma de arreglar los fallos a veces ha sido eso de reducir el problema 90% antes que eliminarlo. El soporte de IBM para el DNS (aparte de los sistemas UNIX) es interesante en sus técnicas, animar en su avance, pero todavía algo deprimente cuando se compara con la mayoría de los demás software DNS. IBM también usa terminología que varía algo del usado normalmente en DNS y conserva alguna sintaxis arcaico, p.ej., "..". La combinación de un BIND viejo y un servidor IBM viejo es simple y obviamente desagradable. 6.3. ¿Es el modelo usado por el sistema de nombres de dominio para nombres de servidores ese en el que el propietario de un nombre consigue elegir su dominio? El modelo usado por el DNS es el que consigue controlar en un punto específico en el espacio del nombre, y por tanto es libre de seleccionar el caso que elija, hasta que los puntos donde usted a su vez cede el control. Como caso práctico, hay varias implementaciones que no hacen lo correcto. Las implementaciones de IBM a veces mapean todo en un solo dominio. 6.4. Según el RFC 1034 [2], sección 4.2.1, no se debería tener que codificar RR's juntas para nombre servidores de nombres a menos que estén debajo del corte. Cuando no pongo las RR's juntas, y hago una solicitud para pedir NS, el campo "adicional" es dejado en blanco. Hasta donde puedo contar, todas las demás zonas que he solicitado para pedir NS lo tienen relleno con la dirección IP del servidor NS. ¿Es necesario o no me debe preocupar que el campo adicional esté vacío? El protocolo dice que un campo adicional vacío bo es un problema cuando cuando el nombre servidores de nombres no está "debajo" del corte. G. Malkin [Pág. 7] RFC 1207 FYI P/R - Para Usuarios de Internet ExperimentadosFebrero 1991 En la práctica, poner lo adicional donde no se necesita puede causar problemas si los servidores nombrados en lo agregado son usados para varias zonas. Esto no funciona bien en BIND. No escribir en lo adicional puede causar otros problemas en BIND, generalmente cuando el nombre del servidor es difícil de resolver. De esta manera, la linea "buttom" es para adherir solo cuando es necesario, y no usar alias o algún truco cuando llega a identificar nombres de servidores. 7.1. Leyendo los RFCs SNMP [3,4,5,6] Encuentro mención de autentificación de PDUs. ¿Hay algún estándar para mecanismos de autentificación? Hay un grupo de trabajo de la IETF que está trabajando en este problema. Están cerca de una solución, pero no ha llegado nada todavía a la publicación en RFC. Se espera algo sólido e implementable para Octubre de 1991. 7.2. ¿Los proveedores pueden hacer disponibles sus variables específicas de empresa a los usuarios a través de un mecanismo de distribución estándar? Si. Pero antes de que nadie proponga un MIB, deberían probarlo ellos mismos. En uu.psi.com en pilot/snmp-wg/, hay dos archivos mosy-sparc-4.0.3.c mosy-sun3-3.5 El primero correrá sobre un Sun-Sparc, el segundo sobre un Sun-3. Después de hacerse con uno de estos archivos en modo BINARIO vía FTP anónimo, el remitente puede ejecutar su MIB a través de él, p.ej., % mosy mymib.my Una vez su MIB pasa el examen, lo envía a: mib-checker@isi.edu Si todo está bien, el comprobador de mibs se dispondrá a tenerlo instalado en el directorio /share/ftp/mib en venera.isi.edu. Nota: Este procedimiento no ofrece un respaldo oficial. Los documentos remitidos no deben ser etiquetados como propietarios, confidenciales, o algo análogo. G. Malkin [Pág. 8] RFC 1207 FYI P/R - Para Usuarios de Internet ExperimentadosFebrero 1991 7.3. Tengo una pregunta relativa a esas molestas cadenas de octetos otra vez. Uso el campo "variable-type" del "Response pdu" para determinar como debe ser mostrado el resultado al usuario. Por ejemplo, convierto las direcciones de red a su formato decimal punteado ("132.243.50.4"). Convierto Identificadores de Objetos en cadenas ("1.3.6.1.2...."). Me gustaría simplemente imprimir las Cadenas de Octetos como cadenas. Pero, esto produce un problema en tales casos como atPhysAddress en la cual la Cadena Octeto contiene la dirección de 6 bytes en lugar de una cadena ASCII imprimible. En este caso, querría mostrar los 6 bytes en vez de solo intentar imprimir la cadena. MI PREGUNTA ES: ¿Alguien tiene una sugerencia de como puedo saber si puedo imprimir la cadena o si debo mostrar los bytes octeto. * Recuerde: Quiero soportar variables específicas de empresa también. En general, no hay una manera de que se pueda asegurar que está en una CADENA OCTETO sin saber algo sobre el objeto del que viene la CADENA OCTETO. En MIB-II [6], algunos objetos son denominados como "DisplayString" que tiene la sintaxis de CADENA OCTETO pero está restringido a caracteres del conjunto de caracteres NVT ASCII (mire la Especificación TELNET, RFC 854 [7], para más información). Estos objetos son: sysDescr sysContact sysName sysLocation ifDescr Si quiere poder decidir arbitrariamente como mostrar las cadenas, sin saber nada sobre el objeto, puede escanear los octetos, buscando algún octeto que no sea imprimible en ASCII. Si encuentra asl menos uno, puede imprimir la cadena entera, octeto por octeto, en notación "%02x:". Si todos los octetos son imprimibles en ASCII, entonces simplemente puede printf la cadena. 7.4. Si los MIBs archivados deben ser compatibles con 1155 [3], estaría bien si quien los remite los comprueba antes. ¿Donde están disponibles estas herramientas de MIB por FTP público? Idealmente, un comprobador de sintaxis simple (que en realidad no generaba código) estaría bien. En la liberación ISODE 6.0 hay una herramienta llamada MOSY que reconoce la sintaxis de 1155 y produce un archivo ASCII plano. Si puede ejecutarlo a través de MOSY sin problemas, entonces está bien. G. Malkin [Pág. 9] RFC 1207 FYI P/R - Para Usuarios de Internet ExperimentadosFebrero 1991 7.5. Suponga que quiero crear un objeto MIB privado para hacer que alguna acción suceda, como hacer un reset. ¿Debe la sintaxis o este objeto especificar un valor tal que así: Syntax: INTEGER { perform reset (1), } aunque solo haya un simple valor? O, está bien solo dejar un "Set" en este objeto con cualquier valor para realizar la acción deseada? Si es así, ¿cómo se especifica? Para nuestros aparatos y cachivaches administrables por SNMP con "acciones" similares escriba la variables del MIB, he definido dos valores Syntax: INTEGER { reset(1) not-reset(2) } Y definido el funcionamiento de forma que el único valor válido que la variable puede tomar es "reset" (que es devuelta en la obtención de respuesta PDU) y en las demás ocasiones un get/getnext responderá con "not-reset". 8. Preguntas Sobre Protocolo de Internet por Linea Serie (SLIP) e Implementaciones del Protocolo Punto-a-Punto(PPP) 8.1. Me parece recordar haber escuchado algo de que SLIP [8] solo correrá en lineas serie síncronas. ¿Es verdad? ... ¿hay algo sobre SLIP que excluya que esté siendo implementado sobre lineas asíncronas? Al revés: SLIP está diseñado para lineas asíncronas y no es muy apropiado sobre lineas síncronas. PPP [9, 10] trabaja sobre cualquiera, y es lo que debería implementar si está implementando algo. 8.2. Entonces estamos muy interesados en estándares de este área, ¿podría alguien contarme donde puedo encontrar más información sobre PPP? Además, ¿Este protocolo puede ser usado en otros campos además de Internet (p.e., telecontrol, telemetría) donde vemos una profusión de propietarios incompatibles y hardware para mantener los Protocolos Punto-a-Punto? PPP fue diseñado para ser usado por algunos protocolos además de IP. Si fuese usado por su aplicación particular probablemente debería ser discutido en la lista de discusión de Grupo de Trabajo de Protocolo Punto-a-Punto de la IETF. Para discusiones generales: ietf-ppp@ucdavis.edu. Para suscribirse: ietf-ppp-request@ucdavis.edu La especificación PPP está disponible como RFC 1171 [9], y unas opciones de especificación PPP están disponibles como RFC 1172 [10]. En el UnixWorld de Abril de 1990 (Vol. VII, No. 4, Pg. 85), Howard Baldwin escribe: "El Protocolo Punto-a-Punto (PPP) acaba de ser propuesto a la CCITT por la Fuerza de Trabajo de Ingeniería de Internet. Especifica un estándar para la encapsulación de datos del Protocolo de Internet y redes de otro "nivel" (nivel tres en el modelo OSI de ISO) información de protocolo sobre enlaces punto-a-punto; También proporciona formas de comprobar y configurar lineas y los protocolos de más alto nivel del modelo OSI. El único requerimiento es disponer de un circuito dúplex cualquiera dedicado o conmutado, que pueda operar en algún modo síncrono o asíncrono, transparente a la estructura del enlazador de nivel de datos. "Según Michael Ballard, director de sistemas de red para Telebit, PPP es un perfeccionamiento directo del Protocolo de Internet por Linea Serie (SLIP), que no tenía ningún corrector de errores ni ninguna forma de intercambiar direcciones de red. 8.3. ¿Alguien sabe si hay alguna manera de ejecutar un programa SLIP en un ordenador IBM corriendo SCO Xenix/Unix, con una tabla serie multi-puerto? SCO TCP/IP para Xenix soporta SLIP. Funciona. Sin embargo, tenga cuidado: SCO SLIP funciona *solo* con controladores SCO serie, así que *no* funcionará con tablas inteligentes que vengan con sus propios controladores. Si quiere montones de puertos SLIP, necesitará montones de puertos mudo, quizás con una tabla multi-puerto-mudo. Aquí está la organización -- SunOS 3.5, con las distribuciones 4.3BSD TCP, IP y SLIP instaladas. Slip corre entre los puertos "ttya" de dos 3/60 de Sun. "ping", "rlogin", etc., funcionan bien, pero un montaje NFS da como resultado un "El servidor no responde: Tiempo de RPC Excedido" ("server not responding: RPC Timed Out"). El SunOS 3.5 desactiva la suma de comprobación UDP, que es válido y funciona bien sobre interfaces como ethernet que tiene enlace - Nivel de Comprobación. Por otra parte, SLIP no realiza sumas de comprobación, así que ejecutar NFS sobre SLIP requiere que cambie la Suma de Comprobación UDP a activada. De lo contrario, experimentará funcionamientos erróneos tales como los descritos más arriba. G. Malkin [Pág. 10] RFC 1207 FYI P/R - Para Usuarios de Internet ExperimentadosFebrero 1991 Guardar el kernel antiguo e intentar, % adb -k -w /vmunix /dev/kmem udpcksum?w 1 para parchear al kernel. 9. Preguntas Sobre Enrutamiento 9.1. Algunos correos mencionaban "enrutamiento de máxima entropía". ¿Podría alguien, por favor darme algún punto de referencia en linea o fuera de ella sobre este tema? Prueba NYU CSD Technical Report 371: "Algunos Comentarios sobre Enrutamiento de Red Altamente Dinámicos" ("Some Comments on Highly Dynamic Network Routing") por Herbert J. Bernstein, Mayo de 1988. 10. Preguntas sobre Otros Protocolos e Implementación de Estándares 10.1. ¿Alguien conoce el tipo ethernet 80F3? No lo veo en el RFC 1010, pero, pero lo estoy viendo en nuestra red. El tipo ethernet 0x80F3 es usado por AppleTalk para la resolución de direcciones. Debe tener Macs en su red que están conectados directamente a Ethernet. Esos paquetes son usados por el Mac (generalmente al iniciarse) para determinar un número de nodo AppleTalk válido. Información Adicional: El RFC 1010 está obsoleto. Por favor consulta el RFC 1060 [11], el "Números Asignados" ("Assigned Numbers") actual (publicado en Marzo de 1990), que lista "80F3": Ethernet Exp. Ethernet Descripción Referencias ------------- ------------- ----------- ----------- decimal Hex decimal octal 33011 80F3 - - AppleTalk AARP (Kinetics)[XEROX] 10.2. ¿Alguien sabe el significado de un valor alto para "Protocolo erróneo" en la salida de netstat en máquinas Unix usando ethernet? Estamos viendo valores en las decenas de miles fuera de rango sobre unos pocos cientos de miles de paquetes enviados/recibidos. Algunos valores "Protocolo erróneo" son negativos, también. Cualquier ayuda sería apreciada. Esto indica probablemente que está obteniendo decenas de miles de paquetes de difusión de algún servidor o servidores de su red. Tal vez le interesaría comprar o alquilar un monitor de red LAN, o instalar uno de los paquetes de dominio público para ver que protocolo privado es el culpable. **"FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices"** (RFC 1147, FYI 2), [12] contiene referencias a herramientas que pueden ayudarle a resolver el problema. 10.3. ¿Qué RFC explicaría la manera correcta de configurar direcciones de difusión cuando se usan subredes? Consulte el RFC 1122, **"Requirements for Internet Hosts -- Communication Layer"** [13]. 10.4. ¿Alguien puede decirme que son exactamente los archivos .TAR? ¿son como ZIP o LZH para los PC's de IBM? Si es así, ¿como hago para obtener un compresor/decompresor para archivos .TAR y en que ordenador se ejecuta? G. Malkin [Pág. 11] RFC 1207 FYI P/R - Para Usuarios de Internet ExperimentadosFebrero 1991 TAR es el acrónimo de "Tape ARchive" (Archivo en Cinta). Es una utilidad Unix a Unix que coge los archivos, y directorios de archivos, y crea un único y gran archivo. Originalmente se usaba para hacer copias de seguridad de árboles de directorios en cinta (de ahí el nombre), TAR también es usado para combinar archivos para una transferencia electrónica más fácil. 11. Lecturas Recomendadas Para más información sobre Internet y sus protocolos en general, puede obtener copias de los siguientes trabajos: Bowers, K., T. LaQuey, J. Reynolds, K. Roubicek, M. Stahl, y A. Yuan, "Donde Empezar - Una Bibliografía de Información General del Trabajo de Internet"("Where to Start - A Bibliography of General Internetworking Information"), RFC 1175, FYI 3, CNRI, U Texas, ISI, BBN, SRI, Mitre, Agosto de 1990. Braden, R., Editor, "Requerimientos para Servidores de Internet -- *****"("Requirements for Internet Hosts -- Communication Layer", RFC 1122, Fuerza de trabajo de Ingeniería de Internet (IETF), Octubre de 1989. Braden, R., Editor, "Requerimientos para Servidores de Internet -- Aplicación y Soporte"("Requirements for Internet Hosts -- Application and Support"), RFC 1123, Fuerza de trabajo de Ingeniería de Internet (IETF), Octubre de 1989. Comer, D., "**Internetworking** con TCP/IP: *****, Protocolos y Arquitectura ("Internetworking with TCP/IP: Principles, Protocols, and Architecture"), Prentice Hall, New Jersey, 1989. Frey, D. y R. Adams, "!%@:: Un directorio de Direcciones de Correo Electrónico y Redes"("!%@:: A Directory of Electronic Mail Addressing and Networks"), O'Reilly y Asociados, Newton, MA, Agosto de 1989. Krol, E., "The Hitchhikers Guide to the Internet", RFC 1118, Universidad de Illinois **Urbana**, Septiembre de 1989. LaQuey, T, Editor, "Directorio de Redes de Ordenador de Usuarios"("Users' Directory of Computer Networks"), Digital Press, Bedford, MA, 1990. Malkin, G., y A. Marine, "FYI on Questions and Answers - Answers to Commonly asked "New Internet User" Questions", RFC 1206, FYI 4, FTP Software, Inc., SRI, Febrero de 1991. Postel, J., Editor, "IAB Estándares de Protocolo Oficiales" ("IAB Official Protocol Standards"), RFC 1140,Tabla de Actividades de Internet, Mayo de 1990. Quarterman, J., "Matrix: Computer Networks and Conferencing Systems Worldwide", Digital Press, Bedford, MA, 1989. Reynolds, J., y J. Postel, "Assigned Numbers", RFC 1060, USC/Instituto de Ciencias de la Información, Marzo de 1990. Socolofsky, T., y C. Kale, "Un tutorial TCP/IP" ("A TCP/IP Tutorial"), RFC 1180, Spider Systems Limited, Enero de 1991. Stevens, W., "UNIX Network Programming", ISBN 0-13-949876-1, Prentice Hall, Englewood Cliffs, NJ, 1990. Stine, R., Editor, "FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices" RFC 1147, FYI 2, Sparta, Inc., Abril de 1990. 12. Referencias N. del T.: Los títulos originales de los documentos no han sido omitidos para su mejor localización posterior. [1] Cerf, V., y K. Mills, "Explicando la Función de GOSIP" ("Explaining the Role of GOSIP"), RFC 1169, IAB, NIST, Agosto de 1990. [2] Mockapetris, P., "Nombres de Dominio - Conceptos e Instalaciones" ("Domain Names - Concepts and Facilities"), RFC 1034, USC/Instituto de Ciencias de la Información, Noviembre de 1987. [3] Rose, M., and K. McCloghrie, "Estructura e Identificación de Gestores de Información para Inter-redes basadas en TCP-IP" ("Structure and Identification of Management Information for TCP/IP-based Internets"), RFC 1155, Funcionamiento International de Sistemas , Hughes LAN Systems, Mayo de 1990. [4] McCloghrie, K., y M. Rose, "Administración de Bases de Información para Administración de Red de Inter-redes basadas en TCP-IP" ("Management Information Base for Network Management of TCP/IP-based internets"), RFC 1156, Hughes LAN Systems, Funcionamiento International de Sistemas, Mayo de 1990. G. Malkin [Pág. 12] RFC 1207 FYI P/R - Para Usuarios de Internet ExperimentadosFebrero 1991 [5] Case, J., M. Fedor, M. Schoffstall, y J. Davin, "Un Protocolo para la Administración Simple de Red" ("A Simple Network Management Protocol (SNMP)", RFC 1157, Investigación SNMP, Funcionamiento International de Sistemas, Laboratorio de Informática del MIT, Mayo de 1990. [6] Rose, M., Editor, "Gestión de Base de Información para la Administración de Red de Inter-redes basadas en TCP-IP: MIB-II" ("Management Information Base for Network Management of TCP/IP-based internets: MIB-II"), RFC 1158, Funcionamiento International de Sistemas, Mayo de 1990. [7] Postel, J., y J. Reynolds, "Especificación del Protocolo TELNET" ("TELNET Protocol Specification"), RFC 854, USC/Instituto de Ciencias de la Información, Mayo de 1983. [8] Romkey, J., "Un No-Estándar para la Transmisión de Datagramas IP en Lineas Serie: SLIP" ("A Nonstandard for Transmission of IP Datagrams over Serial Lines: SLIP"), RFC 1055, Junio de 1988. [9] Perkins, D., "El Protocolo Punto-a-Punto: Una propuesta para la Transmisión de Datagramas Multi-Protocolo En Enlaces Punto-a-Punto" ("The Point-to-Point Protocol: A Proposal for Multi-Protocol Transmission of Datagrams Over Point-to-Point Links"), RFC 1171, CMU, Julio de 1990. [10] Perkins, D., y R. Hobby, "El Protocolo Punto-a-Punto (PPP) Opciones Iniciales de Configuración" ("The Point-to-Point Protocol (PPP) Initial Configuration Options"), CMU, UC Davis, Julio de 1990. [11] Reynolds, J., y J. Postel, "Números Asignados" ("Assigned Numbers"), RFC 1060, USC/Instituto de Ciencias de la Información, Marzo de 1990. [12] Stine, R., Editor, "FYI sobre un Catálogo de Herramientas de Administración de Redes: Herramientas para Monitorear y Depurar Inter-redes TCP-IP y Dispositivos Interconectados" ("FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices") RFC 1147, FYI 2, Sparta, Inc., Abril de 1990. [13] Braden, R., Editor, "Requisitos de los Servidores de Internet -- Niveles de Comunicación" ("Requirements for Internet Hosts -- Communication Layer"), RFC 1122, Fuerza de Trabajo de Ingeniería de Internet, Octubre de 1989. 13. Consideraciones de Seguridad Las consideraciones de seguridad publicadas no están discutidas en este memorándum. 14. Direcciones de los Autores Gary Scott Malkin FTP Software, Inc. 26 Princess Street Wakefield, MA 01880 Teléfono: (617) 246-0900 EMail: gmalkin@ftp.com April N. Marine SRI International Network Information Systems Center 333 Ravenswood Avenue, EJ294 Menlo Park, CA 94025 Teléfono: (415) 859-5318 EMail: APRIL@nic.ddn.mil Joyce K. Reynolds USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292-6695 G. Malkin [Pág. 13] RFC 1207 FYI P/R - Para Usuarios de Internet ExperimentadosFebrero 1991 Teléfono: (213) 822-1511 EMail: jkrey@isi.edu Traducción al castellano: Fernando Cerezal López Madrid - España Email: nabla17@hush.com Teléfono: (+34) 669 255798 G. Malkin [Pág. 14]