Network Working Group G. Minshall Solicitud de Comentarios: 1419 Novell, Inc. M. Ritter Apple Computer, Inc. Marzo de 1993 Traducci—n: Ing. Lucas E. Alberione Apple Computer, Inc. Mayo de 2003 SNMP sobre AppleTalk Estado de este Memorando Este RFC especifica un seguimiento de est‡ndares de protocolos de IAB para la comunidad de Internet y solicita su discusi—n y sugerencias para mejoras. RefiŽrase a la edici—n actual del documento "IAB Official Protocol Standards" para consultas sobre el estado de estandarizaci—n de este protocolo. La distribuci—n de este memorando es ilimitada. Introducci—n Este memorando describe el mŽtodo por el cual el Protocolo Simple de Administraci—n de Red (Simple Network Management Protocol - SNMP), como se especifica en [1], pueda ser utilizado sobre protocolos AppleTalk, en vez de sobre la pila de protocolos de Internet UDP/IP. Esta especificaci—n es de utilidad para los elementos que posean soporte para AppleTalk y que no posean el mismo soporte para TCP/IP. Debe notarse que si un elemento de red soporta pilas de protocolos mœltiples, entre ellos UDP, dicho protocolo debe ser el utilizado. SNMP ha sido exitoso en lo referente a la administraci—n de elementos de red de tipo Internet que soportan como m’nimo a UDP, el protocolo sin conexiones de capa de transporte de Internet. Como fue dise–ado originalmente, SNMP tiene la capacidad de operar sobre cualquier mecanismo de transporte razonable (no necesariamente un protocolo de transporte) que soporte el flujo bidireccional y el direccionamiento. Varios elementos de tipo No-Internet est‡n presentes en las redes. Algunos de estos elementos est‡n equipados con protocolos AppleTalk. Una manera de utilizar SNMP para la administraci—n de estos elementos radica en la definici—n de un mŽtodo de transmisi—n de un mensaje SNMP dentro de una unidad de datos AppleTalk. Este RFC es el producto del Grupo Trabajo de Internet de SNMP sobre Multi-Protocolos de la Internet Engineering Task Force (IETF). 1. Antecedentes El equivalente AppleTalk de UDP (y de IP) es DDP (Datagram Delivery Protocol - Protocolo de Entrega de Datagramas). El campo encabezado de DDP incluye (al menos, de manera conceptual) nœmeros de red y de socket de origen y destino. De manera adicional, los datagramas DDP incluyen un "tipo de protocolo" en su campo encabezado, el cual puede ser utilizado para la demultiplexaci—n de paquetes. La porci—n de datos de un datagrama DDP puede contener desde cero hasta 586 octetos. El Protocolo AppleTalk de Enlace de Nombres (Name Binding Protocol - NBP) es un protocolo distribuido de asociaci—n de nombres a direcciones. Los nombres NBP se estructuran de la forma "objeto:tipo@zona" (object:type@zone), en donde "zona" es, a secas, determinada por la red en donde reside dicha entidad; "tipo" es la clase de la entidad; y "objeto" es cualquier cadena que haga que "objeto:tipo@zona" sea œnico en la interred AppleTalk. Generalmente, "objeto" tambiŽn ayuda al usuario final a determinar quŽ instancia de un tipo de servicio espec’fico est‡ siendo accesado. Los nombres NBP son sensibles a mayœsculas o minœsculas. Cada campo del nombre NBP ("objeto", "tipo y "zona") est‡ limitado a 32 octetos. Los octetos, generalmente, consisten de caracteres ASCII que pueden ser interpretados por humanos. 2. Especificaci—n Las SOLICITUDES SNMP (SNMP REQUESTS) encapsuladas de acuerdo a este est‡ndar ser‡n enviadas al socket DDP nœmero 8; dichas solicitudes contendr‡n un tipo de protocolo DDP 8. Los octetos de datos del datagrama DDP ser‡n un mensaje SNMP est‡ndar, como se define en [1]. Las RESPUESTAS SNMP (SNMP REQUESTS) encapsuladas de acuerdo con este est‡ndar deber‡n ser enviadas al nœmero de socket DDP que origin— la correspondiente solicitud SNMP; contendr‡n un tipo de protocolo DDP 8. Los octetos de datos del datagrama DDP ser‡n un mensaje SNMP est‡ndar, como se define en [1]. (Nota: como se indica en [1], secci—n 4.1, la direcci—n *origen* de una RESPUESTA PDU ser‡ la misma que la direcci—n *destino* de la correspondiente SOLICITUD PDU.) Un elemento de red que sea capaz de responder a SOLICITUDES SNMP sobre AppleTalk debe anunciar esta capacidad a travŽs del Protocolo de Asociaci—n de Nombres AppleTalk utilizando un tipo NBP "Agente SNMP" (SNMP Agent) (hex 53, 4E, 4D, 50, 20, 41, 67, 65, 6E, 74). Una estaci—n de administraci—n de red que sea capaz de recibir un DESVêO SNMP (SNMP TRAP) debe anunciar esta capacidad a travŽs del Protocolo de Asociaci—n de Nombres AppleTalk utilizando un tipo NBP "Manejador de Desv’os SNMP" (SNMP Trap Handler) (hex 53, 4E, 4D, 50, 20, 54, 72, 61, 70, 20, 48, 61, 6E, 64, 6C, 65, 72). Los DESVêOS SNMP encapsulados de acuerdo a este est‡ndar debe ser enviados al de socket DDP nœmero 9; dichas solicitudes contendr‡n un tipo de protocolo DDP 8. Los octetos de datos del datagrama DDP se convertir‡n en un mensaje SNMP est‡ndar, como se define en [1]. El campo agent-addr del desv’o-PDU (trap-PDU) debe ser rellenado con una Direcci—n de Red (NetworkAddress) con todos ceros (la direcci—n IP desconocida). As’, para identificar el emisor del desv’o, el nombre y el valor del Objeto NBP (nbpObject) y de la Zona NBP (nbpZone) con valores iguales a "SNMP Agent" (agente SNMP) deber’an ser incluidos en los enlaces de variables (variable-bindings) en cualquier desv’o que sea enviado [3]. El nombre NBP para el agente y el manejador de desv’os deber’a ser estable - no deber’a cambiar m‡s a menudo que la direcci—n IP de un sistema final TCP/IP t’pico. Se sugiere que el nombre NBP sea almacenado en algœn dispositivo de almacenamiento estable (PRAM, disco local, etc.). 3. Discusi—n sobre el Direccionamiento AppleTalk 3.1 Introducci—n La suite de protocolos AppleTalk tiene ciertas caracter’sticas no manifestadas en la suite TCP/IP. Su estrategia de asignaci—n de nombres œnica y su asignamiento din‡mico de direcciones pueden causar problemas en estaciones administrativas SNMP (SNMP management stations) que deseen administrar redes AppleTalk. Los nodos finales TCP/IP tienen asociadas direcciones IP que los distinguen de otros nodos. Los nodos finales AppleTalk, en general, no tienen dicha caracter’stica. La direcci—n de red, relativamente estable, puede cambiar ante cada reinicio (o de manera m‡s frecuente). As’, el prop—sito es que un "nombre" (en contraposici—n a "direcci—n") para un sistema final es utilizado como atributo de identificaci—n. Este es el equivalente, cuando se trata con nodos finales TCP/IP, a utilizar el nombre de dominio. Dado que el mapeo (nombre DNS, direcci—n IP) es m‡s estable que el mapeo (nombre NBP, direcci—n DDP), no se requiere que el mapeo (nombre DNS, direcci—n IP) exista (por ejemplo, anfitriones sin nombre de anfitri—n, s—lo con una direcci—n IP). En contraste, se requiere que todos los nodos AppleTalk que implementen esta especificaci—n respondan a bœsquedas NBP (NBP lookups) y confirmen (por ejemplo, implementen trozos de protocolo NBP), lo cual garantiza que existir‡ el mapeo (nombre NBP, direcci—n DDP). En la determinaci—n del nombre SNMP para el registro en un agente, se sugiere que el nombre SNMP sea un nombre que estŽ asociado con otros servicios de red ofrecidos por la m‡quina. En un sistema Macintosh, por ejemplo, se sugiere que el nombre del sistema (el "Nombre Macintosh" para el Sistema 7.0, el cual es utilizado para anunciar el intercambio de archivos, comunicaciones entre programas y, posiblemente, otros servicios) sea utilizado como el campo "objeto" del nombre NBP. Este nombre tiene significando en AppleTalk y est‡ estrechamente relacionado al concepto de red de una identidad de sistema dada. Las bœsquedas NBP, la cuales son utilizadas para convertir nombre NBP en direcciones DDP, pueden cuasar gran cantidad de tr‡fico de red y consumir recursos de CPU. Hay que tener en cuenta, tambiŽn, que la capacidad de efectuar bœsquedas NBP esta estrechamente relacionada con ciertos problemas de red (tales como inconsistencias en tablas, etc.), los cuales no previenen comunicaciones AppleTalk directas entre una estaci—n de administraci—n y un agente. As’, se recomienda que las bœsquedas NBP no sean utilizadas de manera frecuente con el principal prop—sito de crear un cachŽ de mapeos del tipo nombre-a-direcci—n. Esos mapeos en cachŽ deber’an ser utilizados por solicitudes SNMP futuras. Se recomienda que las estaciones de administraci—n SNMP mantengan dichos cachŽs entre reinicios. Esto puede ayudar a minimizar el tr‡fico de red, reducir la carga de CPU en la red y permitir la detecci—n de (cierta cantidad de) problemas de red cuando el mecanismo b‡sico de transformaci—n de nombre-a-direcci—n estŽ da–ado. 3.2 C—mo Adquirir Nombres NBP: Una estaci—n administrativa puede tener un lista preconfigurada de nombres de agentes a administrar. Dicha estaci—n puede permitir la interacci—n de un operador, el cual es presentado con una lista de agentes administrables obtenida (a travŽs de NBP), para la selecci—n de agentes que deber’an ser administrados por dicha estaci—n. Finalmente, una estaci—n administrativa puede administrar a sus agentes en un grupo de zonas o redes. Un agente debe ser configurado con el nombre de una estaci—n administrativa espec’fica (o de un grupo de ellas) antes del env’o de desv’os SNMP. En el caso de la ausencia de informaci—n de configuraci—n, un agente NO DEBE generar ningœn desv’o SNMP. En particular, un agente NUNCA DEBE iniciar una bœsqueda NBP "comod’n" (wildcard NBP lookup) para encontrar una estaci—n administrativa que reciba un desv’o. Todas las bœsquedas NBP generadas por un agente deben ser enteramente especificadas. N—tese, sin embargo, que esto no aplica a utilidades de configuraci—n que podr’an estar asociadas con un agente. Tal utilidad puede permitir a un usuario navegar a travŽs de la red para seleccionar una (o varias) estaciones administrativas que reciban desv’os SNMP del agente. 3.3 Cu‡ndo Convertir Nombres NBP en Direcciones: Cuando agentes o estaciones administrativas SNMP utilicen un registro de la cachŽ para direccionar un paquete SNMP, deber’an tratar de confirmar el mapeo, si Žste no ha sido confirmado en T1 segundos. Este tiempo de vida de registro de cachŽ, T1, tiene un valor por defecto m’nimo de 60 segundos. Este valor deber’a ser configurable. Una estaci—n administrativa puede decidir preparar sus nombres almacenados en cachŽ antes del env’o de cualquier solicitud SNMP a un agente dado. En general, se espera que una estaci—n administrativa desee mantener ciertos mapeos "m‡s actualizados" que otros. En particular, esos nodos que representan la infraestructura de la red (ruteadores, etc.) pueden ser considerados como "m‡s importantes" por la estaci—n administrativa. N—tese, sin embargo, que una estaci—n administrativa que ha estado funcionando durante un per’odo de tiempo prolongado, que est‡ inicializando y leyendo un archivo de configuraci—n que contiene un nœmero de nombre NBP, no deber’a intentar preparar toda su cachŽ de una sola vez. En cambio, deber’a hacer sobre un per’odo de tiempo extendido (quiz‡s un orden de prioridad predeterminado o configurado). Cada resoluci—n podr’a, de hecho, ser una bœsqueda "comod’n" en una zona dada. Un agente NUNCA deber’a preparar su cachŽ. Deber’a realizar bœsquedas NBP (o confirmar) s—lo cuando necesite enviar un desv’o SNMP a una estaci—n administrativa dada. Un agente no tiene la necesidad de confirmar un registro de cachŽ en respuesta a una solicitud. 3.4 C—mo Convertir Nombres NBP en Direcciones: Si la œnica informaci—n disponible es el nombre NBP, entonces, una bœsqueda NBP deber’a ser efectuada para la conversi—n de dicho nombre en una direcci—n DDP. Sin embargo, si existe informaci—n "a–eja", puede ser utilizada como un indicio para realizar una confirmaci—n NBP (la cual env’a un paquete unicast a la direcci—n de red que se presume que es el objetivo de la bœsqueda de nombres) para corroborar si dicha informaci—n "a–eja" es todav’a v‡lida. Un mapeo de nombre BNP a direcci—n DDP tambiŽn puede ser confirmado impl’citamente utilizando solamente transacciones SNMP. Si una estaci—n administrativa est‡ enviando un mensaje de solicitud get-request, puede agregar una solicitud en el mismo paquete, para los nbpObjeto (nbpObject) y nbpZona (nbpZone) del destino, correspondientes al nbpEntrada (nbpEntry) con el valor nbpTipo (nbpType) igual a "Agente SNMP" (SNMP Agent) [3]. La direcci—n Ddp de origen puede ser obtenido de la respuesta y utilizado con los (nbpObject) y nbpZona (nbpZone) devueltos para confirmar el registro de cachŽ. En lo anterior, para mensajes set-request, existe una condici—n que puede ocurrir cuando una solicitud SNMP es dirigida al agente incorrecto (porque el nodo antiguo fall— y un nuevo nodo empez— a funcionar con la misma direcci—n DDP). Esto es problem‡tico porque el agente equivocado podr’a generar un paquete de respuesta que la estaci—n administrativa podr’a no distinguir de una respuesta originada por el agente correcto. En el futuro, cuando la seguridad SNMP sea implementada, cada paquete ser‡ autenticado en el destino y la respuesta deber’a confirmar, de manera impl’cita, la validez del registro de cachŽ utilizado y prevenir esta condici—n. 3.5 Lo que sucede si NBP est‡ da–ado: Bajo ciertas circunstancias, puede haber conectividad entre una estaci—n administrativa y un agente, pero los procesos NBP requeridos para convertir un nombre NBP en una direcci—n DDP podr’an estar da–ados. Ejemplos de estas fallas podr’an causar este mensaje solicitud de reenv’o: NBP FwdReq (remite la bœsqueda NBP a la red local) da–ado en un ruteador de la red que contiene al agente; un mecanismo de solicitud de difusi—n NBP (NBP BrRq) da–ado, en un ruteador de la red que contiene a la estaci—n administrativa (por ejemplo, debido a un error de configuraci—n de una tabla de zonas), o NBP da–ado en el nodo de destino. Una estaci—n administrativa que est‡ dedicada a la administraci—n de AppleTalk deber’a elegir aliviar alguna de esta fallas implementando la parte del ruteador de NBP en la estaci—n administrativa misma. Por ejemplo, la estaci—n administrativa ya conoce todas las zonas de la interred AppleTalk y las redes en la que cada zona aparece. Dada una bœsqueda NBP fallida, la estaci—n administrativa podr’a enviar un NBP FwdReq hacia la red en la que el agente fue localizado por œltima vez. Si eso falla, la estaci—n podr’a enviar un paquete de bœsqueda (NBP LkUp) como una multidifusi—n dirigida (DDP) a cada nœmero de red en dicha red. Si lo anterior falla, este enfoque combinado resolver‡ el caso donde el mecanismo BrRq a NBP FwdReq del ruteador o el mecanismo NBP FwdReq a NBP LkUp del ruteador remoto estŽn da–ados. 4. Reconocimientos Mucho del material de este memorando es copiado de [4], [5] y[6]. El Grupo de Trabajo Apple-IP actu— de manera instrumental en la definici—n de este documento. Su trabajo y soporte es muy apreciado. 5. Referencias [1] Case, J., Fedor, M., Schoffstall, M., y J. Davin, "A Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, Mayo de 1990. [2] Sidhu, G., Andrews, R., y A. Oppenheimer, "Inside AppleTalk (Second Edition)", Addison-Wesley, 1990. [3] Waldbusser, S., "AppleTalk Management Information Base", RFC 1243, Carnegie Mellon University, Agosto de 1991. [4] Schoffstall, M., Davin, C., Fedor, M., y J. Case, "SNMP over Ethernet", RFC 1089, Rensselaer Polytechnic Institute, MIT Laboratory for Computer Science, NYSERNet, Inc., University of Tennessee at Knoxville, Febrero de 1989. [5] Bostock, S., "SNMP over IPX", RFC 1420, Novell, Inc., Marzo de 1993. [6] Piscitello, D., "Guidelines for the Specification of Protocol Support of the SNMP", Trabajo en Curso. 6. Consideraciones de Seguridad Las consideraciones de seguridad se discuten en la secci—n 3.4 7. Domicilio del Autor Greg Minshall Novell, Inc. 1340 Treat Blvd, ste. 500 Walnut Creek, CA 94596 TelŽfono: 510 947-0998 Fax: 510 947-1238 EMail: minshall@wc.novell.com Mike Ritter Apple Computer, Inc. 10500 North De Anza Boulevard, MS: 35-K Cupertino, California 95014 TelŽfono: 408 862-8088 Fax: 408 862-1159 EMail: MWRITTER@applelink.apple.com 8. Datos del Traductor Ing. Lucas E. Alberione Apple Computer, Inc. Cork, Republic of Ireland Email: alberione.lucas@euro.apple.com alberione@myrealbox.com