Simon Mudd

C/Hermanos García Noblejas 5, Esc 1, 2B Madrid 28037 España/Spain sjmudd@pobox.com

Joaquín Béjar García

C/Barberán y Collar 22, 1º D Alcalá de Henares 28805 España/Spain shuodata@terra.es

Ángel Moncada Fernández

Paseo de la Estación 1, 1º C Alcalá de Henares 28807 España/Spain c4n99@hotmail.com

2001 Simon Mudd y MadridWireless 2002 Simon Mudd, Ángel Moncada "c4n", Joaquín Béjar "ShuoData" $Author: sjmudd $ $Date: 2005/03/28 10:12:34 $ $Revision: 1.1 $ Redistribution and use in source (SGML DocBook) and 'compiled' forms (SGML, HTML, PDF, PostScript, RTF and so forth) with or without modification, are permitted provided that the following conditions are met: Redistributions of source code (SGML DocBook) must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. Redistributions in compiled form (transformed to other DTDs, converted to PDF, PostScript, RTF and other formats) must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS DOCUMENTATION IS PROVIDED BY THE AUTHORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Se ha aumentado enormemente el interés en las redes inalámbricas en los últimos años, especialmente desde hace poco ya que el coste del hardware ha bajado y su disponibilidad ha mejorado de manera significativa. Este documento intenta marcar las pautas generales que cada grupo wireless en España podría seguir para conseguir un diseño adecuado de sus propias redes y para permitir la fácil conexión con las redes de otros grupos. If there is interest in me producing a version of this document in English then please send me a note. Este documento especifica unas recomendaciones de los entandares a utilizar para la construcción de las distintas redes wireless en España. La distribución de este documento está permitido sin limitación. Se pide comentarios y sugerencias para la mejora de este documento. Se puede encontrar la última versión de este documento en http://www.pobox.com/~sjmudd/wireless/network-structure. Este documento intenta dar información sobre la estructura de las redes wireless, las cuestiones de como se forman los nodos y sus clientes y el enrutamiento de tráfico IP entre diferentes nodos llevados por una persona o un grupo. Teniendo en cuenta que distintos grupos están trabajando con el mismo fin, de montar redes wireless, el documento también intenta dar información sobre las maneras de conectar los grupos entre sí y las posibles conexiones con Internet. Este documento podría usarse como base para la implementación de redes wireless en zonas o ciudades con el mínimo de modificaciones. El uso de unas normas y estructuras de redes comunes simplifica las tareas de interconexión de estas redes y minimiza los labores de gestión comunes en cada red. Cada grupo wireless será compuesto de una red de redes inalámbricas conectadas entre sí para crear una red metropolitana (MAN) en la zona de su ubicación. Existen varios protocolos de comunicación inalámbrico de los cuales 802.11a, 802.11b, 802.11g y AX25 son ejemplos. En la actualidad 802.11b parece ser el más común debido en parte al coste y acceso al hardware. Cada red wireless estará compuesta de varios PCs o otros aparatos que se comunican directamente utilizando el protocolo IP. Se llamará a esta red un nodo. Dentro de cada nodo habrá al menos un host configurado para conectarse de la manera más conveniente a otros nodos de la red de su grupo. Los nodos pueden ser interconectados por enlaces de radio u otros medios. Se puede usar el termino nodo también para referirse al host que gestiona su propia red. Los clientes de esta red, la gente que se conectará desde sus casas o oficinas conectarán a los nodos, así formando la red completa. Los nodos sin clientes forman la infraestructura de cada grupo. Tipos de Nodo Tipos de Nodos de una red wireless. En este documento se habla exclusivamente del uso de IP versión 4, ya que en este momento se requiere una infraestructura mínima de red y es más fácil formar una red utilizando un protocolo y herramientas ya probados. No obstante, sería posible implementar una red IPv6 al mismo tiempo que la red IPv4 sin llegar a influir. También es cierto que el futuro de las redes y de Internet es IPv6 y ya existen redes complejas y en producción basadas exclusivamente en IPv6. La recomendación sobre la metodología de asignación de direcciones IPv6 experimentales queda por definirse. Para montar una red wireless se requiere el uso de unas direcciones IP de uso común. El direccionamiento IP que se podría utilizar y como se podría repartir tanto a nivel global (de los distintos grupos wireless en España), como a nivel grupo wireless o a nivel de un nodo de un grupo en concreto se explica en las siguientes secciones. Cada grupo wireless necesita de un rango de direcciones IP para posibilitar la conexión de los nodos con los equipos de los clientes, la conexión de los nodos entre sí y finalmente para posibilitar la conexión con otros grupos wireless, otros entes externos y Internet. Varios grupos wireless internacionales que ya han montado sus propias redes wireless han empezado a usar direcciones IPs privadas por la facilidad de usar estas direcciones IP sin tener que consultar a nadie y para evitar pagar por ellas. Al pedir direcciones IP oficiales existe un compromiso de conectar estas direcciones IP a Internet y de justificar el número pedido y su uso, algo a menudo díficil para proyectos un proyecto nuevo. En este momento no se considera necesario esta petición de direcciones IPs públicas aunque no se descarta la posibilidad en el futuro. Los tres grupos de direcciones IP reservados para uso privado son: 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 El grupo RedLibre ha planteado un uso de direcciones IP en todo España utilizando la red 10.0.0.0/8, dividiendo este rango entre diferentes provincias y ciudades. Ver http://www.redlibre.net/direccionamiento.php para más información. En principio su planteamiento parece correcto y se puede aplicar. Es necesario asegurar que las direcciones IP de un grupo no coinciden con las de otro porque así se haría imposible la interconexión de los grupos. Se recomienda que si un grupo nuevo necesita de un grupo de direcciones IP que habla con el resto de los grupos wireless en España para conseguir un rango de direcciones que evitará conflictos en el futuro. Un ejemplo de esto es el caso de Madrid, donde RedLibre, MadridWireless y AlcalaWireless necesitan de direcciones IP que no llevan conflictos. RedLibre había planteado la asignación de direcciones en Madrid utilizando el rango 10.0.0.0-10.15.0.0, inicialmente para sus propias redes. Sin embargo había adaptado este planteamiento para que otros grupos podrían utilizar un subrango de direcciones IP, de mutuo acuerdo y los dos grupos no se interferirán entre sí. De esta manera cualquier red wireless que pueda aparecer en España o en una ciudad grande se asegura un rango de direcciones IP propias y libres permitiendo además la futura conexión entre estas. Este punto es muy importante. Recientemente ha llegado a mi atención una propuesta mundial de direcciones IP por diferentes grupos wireless. Esta propuesta de direccionamiento tiene conflictos con la propuesta del grupo Red Libre por lo que queda pendiente ver como mejor resolver esta situación. Como se verá más adelante también será necesario asignar direcciones IP para la conexión de los nodos entre sí, para formar el backbone de la red de un grupo wireless. En este caso se usará el rango de direcciones IP 172.16.0.0/12. Se usará otro subrango, todavía sin definir de las direcciones IP 172.16.0.0/12 para la asignación de puntos de interconexión entre diferentes grupos. En el caso de que un grupo agotara del bloque de direcciones IP antes acordado y necesite una posterior asignación de direcciones el grupo debe volver a hablar con el resto de los grupos para acordar un nuevo bloque de direcciones que podría usar, siguiendo el esquema propuesto por RedLibre o otro acordado entre los distintos grupos si no hay inconveniente. La asignación local de las IPs a cada nodo, es decir, el direccionamiento privado que cada nodo utilizará dentro de un grupo, estará centralizado en unos miembros de cada grupo wireless. Estos miembros decidirán los procedimientos de asignación de IPs a un nodo y los requisitos que los nodos deben cumplir para darse de alta. A cada nodo se le asignará un bloque de direcciones que vienen del bloque global de direcciones IP mencionado en la sección anterior. Cada nodo consistirá de un bloque de al menos 32 direcciones, de las cuales 30 serán útiles. En principio una dirección será utilizada por el propio nodo/router dejando las direcciones restantes disponibles para otros fines como por ejemplo la asignación a clientes. Al considerar el alcance habitual de las señales que se estará utilizando este rango de direcciones probablemente será más que suficiente. Los bloques de 32 direcciones estarán compuestas de la siguiente forma: 10.x.y.0 Dirección IP de la red 10.x.y.1 Dirección IP del router o nodo 10.x.y.2-30 Direcciones IP de los clientes del nodo 10.x.y.31 Dirección IP de broadcast La mascara de red en este caso sería 255.255.255.224. Cada red de clase C, 10.x.y.0/24, se compondrá de 8 sub-redes cuyo último dígito termina en .0, .32, .64, .96, .128, .160, .192 y .224. La asignación a clientes de las direcciones IP 2-30, podría realizarse de cualquier manera, pero lo más practico en una red wireless sería la asignación dínamica utilizando el protocolo DHCP, asignado por el nodo/router. La ventaja del uso del protocolo DHCP para el cliente es que en el momento de asignarle la dirección IP al cliente también se le puede dar información adicional como: la dirección IP del router dentro de la red las direcciones IP de los servidores de nombres a utilizar el nombre del dominio de la red, o su nodo Así se minimiza las necesidades de configuración de su equipo. La asignación de bloques de 32 direcciones IP puede ser insuficiente en zonas urbanas con mucha densidad de población, por lo que será necesario considerar la asignación de bloques de 64, 128 y hasta 256 direcciones IP, cada bloque con su dirección de red y mascara de red apropiadas. En este sentido se recomendaría la asignación de estos bloques grandes solo cuando se le considera necesario, aunque en principio sería una decisión local de cada grupo. La estructura del bloque de direcciones grande debe ser la misma que se ha visto en la sección anterior, con la diferencia que se amplia el número de direcciones IP que se asignan a los clientes. Se plantea la utilidad de utilizar el DNS para nombrar cada dirección IP relacionada con el nodo, de permitir la traducción de un nombre de host a un IP y viceversa. En principio cada grupo wireless será responsable por su propio dominio y la asignación de nombres a las direcciones IP de sus nodos. Si se ofrece un servicio de este tipo se recomienda que el servidor DNS para este dominio también será disponible en Internet. En este documento se representará el nombre de dominio utilizado de manera genérica como ${GROUP}, pero podría ser por ejemplo: redlibre.net, madridwireless.net o un subdominio de un dominio gestionado por el grupo correspondiente. Todas los nodos y clientes se podrían nombrar de una forma parecida para facilitar su identificación: Primero se dará un nombre a cada nodo: NODE="nodo". El nombre del nodo debe ser corto. Sería conveniente que cada grupo tenga una página web pública con información de sus nodos y la configuración y ubicación de cada uno. De esta manera los posibles clientes podrían localizar el nodo más cercano. Dentro de cada nodo se nombrará todos los hosts/nodos/clientes como un subdominio de ${NODE}.${GROUP}, de la forma: "nombre".${NODE}.${GROUP}. Los nombres recomendados a incluir en el DNS serán los siguientes: Nombre Descripción Dirección IP network la dirección de la red 10.x.y.0 router el router principal del nodo 10.x.y.1 client1 la dirección ip de primer cliente del nodo 10.x.y.2 ... client29 la dirección ip del último cliente del nodo 10.x.y.62 broadcast la dirección de broadcast de la red 10.x.y.63 netmask el netmask de la red 255.255.255.224 Debemos destacar que el alta de esta información en el DNS es para un motivo sencillo: la ayuda con la identificación del tráfico IP dentro de la red. Es muy útil. Se podría asignar en el DNS otros nombres de host, y está posibilidad será opcional y cuestión del gestor del nodo correspondiente si es un subdominio de su nodo o del gestor de DNS global si es un nombre "global". Por ejemplo la asignación del nombre www.nodo23.madridwireless.net será cuestión del gestor del nodo23 de MadridWireless, y la signación del nombre www.madridwireless.net, como es lógico, del administrador de madridwireless.net. A la vez que existírá un relacion nombre -> ip, también se configurará un servidor de nombres para permitir la resolución inversa: ip -> nombre. Este uso es muy cómodo para la resolución de problemas y para identificar la fuente de tráfico IP en la red. Así que hará falta unos registros del tipo: 0.0.64.10.in-addra.arpa. IN PTR network.${NODE}.${GROUP}. 1.0.64.10.in-addra.arpa. IN PTR router.${NODE}.${GROUP}. ... El servidor de nombres para resolver la direcciones inversas está todavía pendiente de definir. Debemos indicar que en el caso de la resolución del DNS inversa, podría ser necesario disponer de un servidor DNS común que sea capaz de resolver direcciones ip a nombres para más que un grupo. Es una situación diferente a la resolución "normal" donde cada grupo lo puede gestionar de manera independiente. [Se podría delegar el DNS inverso también: es algo que se debe estudiar en el futuro si esta opción conviene más.] Se surgiere que NO se modifique el DNS inverso, al menos para los nombres estándar: network, router y broadcast para cada nodo. Para facilitar la gestión de estos multiples nombres se plantea el uso de unas herramientas web o email, como el robot del dominio ampr.org. Ver abajo para una explicación de su funcionamiento. Los pasos a realizar para pedir el alta de un nodo nuevo en los distintos grupos wireless estarán determinados en otro documento y hará falta contactar con el grupo correspondiente. El alta de un nodo iniciará un proceso de creación de los nombres recomendables en el DNS. Al ser posible se hará en tiempo real, y de no ser así se intentará actualizar la información de manera diaria. Al realizar un alta de un nodo sería útil tener los siguientes datos: name: Nombre de nodo (alfanumerico, utilizable en el DNS) description: Descripción de nodo (texto libre) admin: Nombre de Gestor de nodo password: password encryptado para actualizar datos email: Email de gestor de nodo tel: Teléfono de gestor de nodo (*) location: Ubicacion del nodo: formato libre, pero sugeriendo "zona, ciudad, código postal, pais" frequency: Frecuencia/canal utilizado type: tipo de nodo (AP/Ad-hoc) comments: observaciones (*) ip-range: rango ips dns-delegated: dns delegado: si/no, (inicialmente no) dns-main: servidor dns principal: direccion ip (*) dns-secondary: servidor dns secundario: direccion ip (*) links: lista de nombres de los nodos con conexión directa (*) internet: enlace con Internet (si/no) (*) created: fecha/hora alta de nodo deleted: fecha/hora baja de nodo [normalmente sin datos] change-last: fecha/hora ultimo cambio de datos "del nodo" change-by: persona/email ultimo cambio de datos "del nodo" change-num: número de cambio (número secuencial de cambio) Los campos marcados con (*) serían opcionales. Toda esta información se podría guardar dentro del propio DNS, sin tener que utilizar bases de datos externos, dando cada campo el nombre indicado y asignándolo a un registro de tipo TXT. Sin embargo por motivos de privacidad puede que no toda información se hace pública y al ser así haría guardarla en algúna base de datos. Por ejemplo sabiendo que hay un nodo23 para grupo ${GROUP} el comando dig txt admin.nodo23.${GROUP} nos daría: admin.nodo23.${GROUP} IN TXT "Simon Mudd" Al modificar cualquier información correspondiente al nodo se modificaría los últimos 3 campos. Con los datos indicados arriba se podría generar la siguiente información DNS de manera automática: (1) Información del dominio Los registros de dirección IP, como se ha indicado anteriormente. network.${NODE}.${GROUP} IN A 10.x.y.0 router.${NODE}.${GROUP} IN A 10.x.y.1 cliente1.${NODE}.${GROUP} IN A 10.x.y.2 ... cliente29.${NODE}.${GROUP} IN A 10.x.y.62 broadcast.${NODE}.${GROUP} IN A 10.x.y.63 netmask.${NODE}.${GROUP} IN A 255.255.255.224 (2) Información inversa X registros tipo PTR para permitir la resolución del hostname desde el IP: z.y.x.10.in-addra.arpa. IN PTR xxx.${NODE}.${GROUP}. Dada la posibilidad de existir muchos nodos en un grupo wireless y de tener enlaces con otros grupos con intereses parecidos la gestión de las rutas entre las diferentes redes será bastante compleja. Básicamente existen dos maneras de enrutar a otros hosts fuera del nodo local y son utilizando enrutamiento estático o enrutamiento dinámico. Cada método tiene ventajas e inconvenientes, pero cuando una red crece finalmente el enrutamiento dinámico es la única manera factible de gestionar la red. Por este motivo se plantea la necesidad de utilizar protocolos de enrutamiento dínamico en vez de usar rutas estáticas en todos los nodos. Existen programas para llevar el enrutamiento dinámico en la mayoría de los sistemas operativos, por lo que no debe ser complicado instalarlos en un nodo. Para sistemas UNIX existe un programa, zebra, que puede gestionar los protocolos de enrutamiento estáticos mencionados en este documento. Además zebra es software gratuito con licencia GPL. Hay que destacar que el uso de estos protocolos será transparente al usuario final y será exclusivamente un tema para los gestores de nodos en caso que el nodo conecte a otros. Desde el punto de vista del cliente el enrutamiento será resuelto mediante la configuración DHCP automática cuando el cliente conecta al nodo. Como no es obligatorio que un nodo conecta a otros, el uso de estos protocolos y el enrutamiento dínamico no es obligatorio. En algunos casos una ruta estática puede ser suficiente para realizar la conexión. Para realizar la conexión entre dos nodos se utilizará otro rango de direcciones IP, distintas a las direcciones de la propia red de un grupo wireless (10.x.x.x), utilizando conexiones punto-a-punto. Las IPs usadas para estas conexiones serán del bloque 172.16.0.0/12, empezando por 172.16.64.0/30 y continuando con 172.16.64.4/30, 172.16.64.8/30, ... según el número de enlaces usados. Siendo los enlaces punto a punto la mascara de red será 255.255.255.252 y contendrá 2 direcciones IP útiles (las direcciones IP de los dos extremos). Debido al gran número de redes que podrían existir dentro de cada grupo wireless el enrutamiento entre los distintos nodos será bastante complejo. Para resolver este problema será necesario utilizar un protocolo de enrutamiento dinámico de tipo IGP (Interior Gateway Protocols) como RIP (Routing Information Protocol) o OSPF (Open Shortest Path First), el último siendo un protocolo más complejo y sofisticado. Si la red de un grupo está compuesto de un número reducido de nodos se podría contemplar el uso de enrutamiento estático. El uso del enrutamiento dínamico evitará las modificaciones manuales y asegurará que la conexión a nuevos nodos sea inmediata en toda la red. Por este motivo se recomienda su uso cuando sea posible. Por los mismos motivos elaborados anteriormente con las direcciones IP de los clientes, el uso de las direcciones IP 172.16.0.0/12 utilizadas para interconectar los nodos dentro de un grupo wireless NO deben coincidir con direcciones IP utilizadas por otros grupos wireless. Si esto ocurriera no afectaría al enrutamiento entre las direcciones IP de los clientes, pero sí imposibilitaría la depuración de tráfico que se mueva de la red de un grupo a la red de otro, y por lo tanto no se recomienda en absoluto. Será necesario elaborar otro documento que explica la configuración mínima necesaria para poner en marcha un programa como zebra que enruta utilizando los protocolos IGP como RIP o OSPF, aunque debido a la flexibilidad que ofrece el segundo protocolo se preferiría el uso de OSPF. Se puede plantear el uso del mismo tipo de protocolos (IGP) para conectar con redes externas a un grupo wireless pero probablemente sería más apropiado el uso de protocolos EGP (Exterior Gateway Protocol). Este es el procedimiento habitual al menos en el Internet. Siempre que se plantea la conexión con sistemas externos a un grupo wireless en otras ciudades, países o zonas hay que asegurarse de que no haya conflictos de direcciones IP o de otro tipo importante. El enrutamiento con estas zonas probablemente debe realizarse a través de protocolos EGP como BGP (Border Gateway Protocol) y será una cuestión de estudiar en el futuro. La ventaja de este enfoque es que cada sistema será autónomo y no será necesario conocer las rutas internas de sistemas externos, solo los puntos de acceso a ellos y las redes contenidas allí dentro. Las direcciones utilizadas para la interconexión de diferentes grupos quedar por definirse. Lo más apropiado sería la asignación de un rango de direcciones explícitamente para este fin y probablemente utilizando un rango de las direcciones IP 172.16.0.0/12. Este rango puede ser bastante reducido porque no se espera un gran número de interconexiones entre los diferentes grupos. Se tendrá que elaborar un documento de configuración para explicar la mejor forma de configurar un nodo que actúa de enlace a otros grupos. En cualquier caso si un grupo wireless se considera como sistema autónomo (AS) se le asignaría un numero usando algún código que identifique la localización. Como será habitual la mayoría de los casos el grupo no tendrá un número AS propio. Se recomienda que el grupo que necesita de un nuevo número AS contacte con los otros grupos wireless y se asigna un número no utilizado dentro del rango de AS privados recomendados en el RFC 1930. Este rango de números AS es 64512-65534. Sería útil tener un registro de los números AS asignados y utilizados por los distintos grupos wireless en un lugar público. El número AS en sí no es importante, simplemente es un identificador de cada sistema autónomo. De la misma manera que hay que evitar duplicados de direcciones IP es imprescindible que un nuevo grupo no usa un número de AS ya asignado, porque esto llegará a confundir los routers de manera considerable. Open Shortest Path first (OSPF) es un protocolo de routing link-state no propietario, esto quiere decir principalmente dos cosas: Primero que es de libre uso y suele estar soportados por la mayoría de los equipos destinados a ofrecer servicios a la red y Segundo el ser un link-state quiere decir que a diferencia de RIP o IGRP que son Distance-vector, no mandan continuamente la tabla de rutas a sus vecinos sino que solo lo hacen cuando hay cambios en la topología de red, de esta forma se evita el consume de ancho de banda innecesario. En un cambio de topología OSPF envía el cambio inmediatamente de forma que la convergencia de la red es mas rápida que en los distance-vector donde depende de timers asignados, de forma que en un link-state el tiempo de convergencia puede ser de 4 o 5 segundos según la red en RIP puede se de 180 segundos. La topología de OSPF esta basada en areas conectadas de forma jerárquica. El sistema autónomo de OSPF puede ser fraccionado en diferentes areas y todas las areas estas conectadas al área de Backbone o área 0 representada en la siguiente figura: Open Shortest Path First Open Shortest Path First (OSPF) Los router que forman parte de la red con OSPF se les denomina según su situación y su función dentro de la red de la siguiente forma: Internal router: Un router con todas las redes directamente conectadas a la misma área. Estos solo mantienen una copia del algoritmo de routing. Area Border Router: ABRs es un router que une un área al area 0 comparte la información entre las dos area y gestiona que redes se tiene que compartir entre ellas. Backbone Routers: Son los routers que pertenecen al area 0 y responsable de la propagación de las redes entre distintas areas. Autonomous System Boundary Routers: Son routers conectados a otros AS o Internet. También suele ser el router que intercambia entre protocolos de routing IGP y EGP. En el siguiente dibujo podemos observar las distintas formas en que podríamos conectar las areas o nodo a nivel de routing a partir de redes wireless. También se ha incluido una opción por VPN que resultaría muy útil sobre todo en la unión de distintas redes wireless entre ciudades o cuando la distancia entre dos nodos resulta muy larga y es necesaria la comunicación por medio de Internet. De esta forma se definiría un área 0 donde se situaría el nodo principal y preferiblemente con la salida a Internet con mayor ancho de banda, y a donde se conectarían las demás redes. En el caso de que existan nodos que no se puedan unir directamente al área 0 normalmente o por VPN se utilizará un virtual-link para unirla al área 0. En ocasiones puede que existan casos en que por cierto APs o ciertos sistemas operativos no se soporte OSPF, en tal caso el se podrá utilizar otro protocolo como RIP siempre que sea classless es decir versión 2 en el caso de RIP o EIGRP en el caso de Cisco IGRP. A pesar de todo el ABR deberá soportar OSPF para no perder la concordancia en el resto de la red. Sera importante a la hora de unir redes completas utilizar sumarización de redes siempre que sea posible y evitar que se solape el direccionamiento. En Redlibre se puede ver el direccionamiento de una clase A asignada a las distintas ciudades y provincias dentro de España. El protocolo Border Gateway Protocol (BGP) está definido en el RFC1771 y actualmente está en su versión número 4. Es el protocolo más popular de los protocolos EGP y se utiliza casi sin cambios desde el año 1995. La función de BGP es similar a la función de un router IGP como OSPF que aprende las rutas más óptimas para llegar al resto de los nodos y redes dentro de un sistema autónomo (AS). La diferencia es que BGP trabaja con redes de diferentes sistemas autónomos, publicando sus propias redes y determinando a través de que otro sistema autónomo se puede llegar a un tercero. BGP también tiene varias funciones de filtrado para permitir informar o no sobre las rutas que tiene y a que router externo AS lo dice. Debido a esta funcionalidad se recomienda el uso de BGP para interconectar distintos grupos wireless, en vez de seguir el uso de un protocolo IGP como OSPF. Hasta ahora se ha hablado de las direcciones IP que se utilizarán dentro de la red para conectar los clientes, los nodos y los distintos grupos. También se ha hablado del enrutamiento entre estos componentes, pero solamente en cuanto a los protocolos utilizados y no la forma de interconectar los distintos nodos. La interconexión de nodos en una red compuesta de más de cinco nodos puede realizarse de muchas maneras. En cuanto el número de nodos aumente también va aumentando las posibles maneras de interconectar la red. Sin embargo una estructura aleatoria no es la más indicada por muchos motivos. Normalmente cuando se diseña una red se estudia de antemano su tráfico, el número de máquinas conectadas, las necesidades de los usuarios y varias cosas más para organizar la estructura para dar el mejor servicio posible. Las redes wireless al crecer de una manera no controlada requerirán un diseño o ajuste posterior para que se estructura mantenga cierta orden. Los siguientes puntos son los que se debe tener en cuenta cuando diseñamos una red: Evitar la congestión en un punto único de la red. Reducir el número de saltos entre un nodo y otro. Intentar tener multiples enlaces a la red a través de distintos nodos. Si uno falla se puede usar el otro. Si además se utiliza enrutamiento dinamico este cambio será transparente. Utilizar herramientas para monitorizar la red y así poder prevenir problemas futuros. Separar el tráfico de clientes con el tráfico con otros nodos. Evitar en cuanto sea posible las configuraciones manuales y utilizar configuraciones estándar para los diferentes componentes instalados. Utilizar enlaces entre nodos con el mayor velocidad de transmisión posible (por radio). Mantener una buena comunicación entre los gestores de los nodos. Normalmente la gente que lleva la red en una compañía gestión toda la red: en el caso de una red wireless cada gestor gestiona su nodo por lo que la comunicación entre gestores es muy importante para minimizar el tiempo necesario para resolver problemas que podrían surgir. Será importante durante las primeras fases de crecimiento de la red discutir la adición de nuevos nodos y el mejor punto de conexión como decidir en una herramientas de monitorización de varios aspectos de la red que se podría utilizar para comparar el comportamiento de sus diferentes partes. Hasta ahora se ha hablado de las redes wireless como las únicas redes que existían. Realmente muchos de los potenciales gestores de nodos tendrán su nodo conectado a otras redes, como una red interna de empresa o de casa, o quizá a Internet. En este sentido la información que se mueve fuera de las redes de radio podría necesitar protección por una de varias razones. Puede ser que el gestor no quiere que alguien entre en su propia red interna, pero no le importa ofrecer el servicio radio y los enlaces a otros nodos sin problema. Para solucionar este tipo de problema la única solución razonable es la de poner un firewall, una técnica claramente explicada en varios sitios en Internet, cuyo objetivo es simplemente filtrar el tráfico que está pasando entre las distintas redes de un nodo, filtrando y dejando pasar o no la información que parece oportuno. Partiendo de la base de que queremos montar un firewall, tenemos que tener en cuenta varias cosas, para poder ponerlo en marcha. Hay varias soluciones posibles, algunas son dependiente del sistema operativo utilizado y además hay soluciones comerciales que funcionan en distintos sistemas operativos. En linux hay varias opciones que dependerán de la versión del kernel instalado: las principales siendo IPCHAINS y IPTABLES. FreeBSD y las otras versiones de BSD tienen ipfw. La ventaja de estas opciones es que vienen con el propio sistema operativo aunque no siempre están soportados por el kernel instalado por defecto. Ver los manuales correspondientes para más información. Un enlace para configurar un firewall con IPTABLES en linux es http://www.boingworld.com/workshops/linux/iptables-tutorial/iptables-tutorial/iptables-tutorial.html También existen varios documentos HOWTO para Linux que explican la configuración de un firewall. Hay que seguir una serie de normas en la configuración de un firewall, es decir, a partir de un diseño del nodo hay que tener en cuenta varios factores entre ellos: los distintos interfaces a que el firewall está conectado las distintas redes y las direcciones ip asociadas conectadas al firewall La deseabilidad que el tráfico desde una red a otra pasa a través un interfaz en concreto Los distintos servicios IP permitidos o denegados (http, smtp, dns, ping) usando tcp, udp, icmp, etc. Si es necesario convertir la dirección ip al salir del interfaz (NAT) a otra distinta Un firewall va a tener habitualmente las siguientes conexiones/redes a tratar: Direcciones ip de la red de su nodo Direcciones ip de la red de su grupo wireless Direcciones ip de la(s) red(es) de enlace a otro(s) nodo(s) Direcciones ip de su red interna Un enlace a Internet (que usa el resto de las direcciones IP) Solamente viendo la matriz de posibles conexiones entre una red y otra, y teniendo en cuenta que tenemos que tratar tráfico ip en los dos sentidos (de ida y vuelta), nos damos cuenta que la configuración de un firewall es bastante compleja. La mayoría de las configuraciones de un firewall permiten que no solo podemos decidir si aceptar o denegar el tráfico a través del firewall, pero también podemos guardar en un log los intentos de hacer pasar tráfico IP que está prohibida. La política que hay que seguir con los logs que genera el firewall es mantenerlos por un tiempo determinado, quizá 3 meses, por si acaso ocurriera algún incidente tener un registro de lo ocurrido. Se debería comentar que un nodo no debería filtrar tráfico cuya fuente y destino es de su propia red wireless, porque esto obstruiría el correcto funcionamiento de la red. Si un grupo wireless decide conectarse a otro grupo entonces tampoco debería estar filtrado el tráfico con el otro grupo wireless. Si varios nodos tienen configurados un firewall se les debería avisar con tiempo suficiente para poder cambiar la configuración de su firewall antes de confirmar la interconectividad con el otro grupo. Una recomendación a hacernos, es la utilización de un IDS (Detector de Intrusión) ya que facilitaría las cosas al tener que detectar un intento de ataque, bien desde nuestra red wireless o desde otras redes wireless externas. Existen varios IDS que se podría utilizar entre ellos es el snort http://www.snort.org y la política a seguir sobre los logs del IDS sería la misma que se aplica en el caso de los firewalls. Mucha gente está interesada en las redes wireless como medio barato de acceder a Internet usando la conexión de otro. En principio se puede ofrecer la conexión a Internet desde un nodo pero tenemos que tener en cuenta que todos las conexiones de esta manera requerirán la modificación de la dirección IP de origen (un proceso que se llama NAT) al menos cuando se usan direcciones IP privadas. En estos casos tampoco será posible conectar desde Internet "hacía dentro" por el mismo motivo: las direcciones IP de las redes wireless no son públicas y desde Internet no se puede enrutar a una red privada. No obstante la conexión a Internet, incluso con NAT, permite el uso de un montón de servicios como DNS, correo, web, ftp entre otros. Debemos también hacer constar que la velocidad máxima de las redes wireless 802.11b permite hasta un 11Mb/s algo bastante superior a la velocidad típica de una conexión a Internet desde casa que incluso con ADSL no suele pasar de 256kb/s de entrada. Así que los que deciden ofrecer acceso a Internet podrían ver su conexión saturada por los usuarios wireless si no toman medidas oportunas. Finalmente se menciona que no solo existirá la posibilidad de tener acceso a Internet sino que este servicio podría estar ofrecido en varios puntos de la red wireless. La gestión de las múltiples rutas dentro de la red hacia la ruta por defecto puede complicarse mucho y haría faltar determinar la mejor forma de su gestión. Quality of Service va aquí Una manera de evitar el mantenimiento manual de información del DNS sería usar un robot que permite la actualización de la información de manera remota. Se podría "controlar" el robot vía email, o quizá vía web y sería algo que haría falta estudiar en más detalle. Un ejemplo que se usa en la actualidad es el robot del dominio ampr.org, que gestiona la actualización de los nombres de host e IPs, todo vía email. Se envía un email a la dirección email del robot enviando comandos en un formato determinado. Basado en el robot DNS del dominio ampr.org he escrito uno algo más sofisticado, que permite los siguientes comandos: Añadir una dirección IP, registro de correo, gestor de nombres, registro de texto o cname nuevo nombre ADD A 1.2.3.4 nombre ADD CNAME otro-nombre nombre ADD MX prioridad nombre-mx nombre ADD NS servidor.de.nombres nombre ADD TXT "algún texto" Borrar los mismos datos nombre DEL A 1.2.3.4 nombre DEL CNAME otro-nombre nombre DEL MX prioridad nombre-mx nombre DEL NS servidor.de.nombres nombre DEL TXT "algún texto" Visualizar la información guardada nombre INFO nombre ? Después de realizar cualquier modificación el robot confirme sus acciones y finalmente manda un mensaje al originador del mensaje con los resultados de sus acciones. El formato tal y como se usa en ampr.org no funcionaría para un grupo wireless por varios motivos: Cada grupo wireless funciona de manera independiente - haría falta un robot por dominio. Probablemente sería necesario asignar un password al gestor de un nodo y solo permitirle modificar datos de su nodo. Haría falta tener unos passwords que permiten la modificación de datos globales (de un grupo wireless), limitando estos accesos a un grupo de personas que tiene control global sobre el dominio. Lo ideal sería que este robot estuviera alimentado de manera automática a través de una aplicación que asignara direcciones IP nuevas a un nodo y que generara los datos nuevos a incluir en el DNS. Como el robot ya existe si alguien está interesado en utilizarlo que me mandan un email a sjmudd@pobox.com. Actualmente una vez que se modifican los datos guardados se actualizará el fichero utilizado por el servidor de nombres y este actualiza los datos en seguida. Su uso requiere de perl y poco más para que funcione correctamente. Los siguientes enlaces da información de hardware que se podría usar para ser un nodo o un cliente en un grupo wireless. http://www.3com.com http://www.cisco.com http://www.orinocowireless.com http://www.stechcomm.com La siguiente lista incluye algunos de los grupos que están trabajando en wireless dentro de España y el resto del mundo. La siguiente lista de grupos y sus URLs indica el mejor sitio para empezar de encontrar información sobre cada grupo. La mayoría de los grupos mantienen listas de correo y hay cierta duplicidad de tráfico entre las distintas listas. Alcalá Wireless http://www.alcalawireless.com Barcelona Wireless http://www.barcelonawireless.net MadridWireless http://www.madridwireless.net Málaga Wireless http://malagawireless.xphera.net http://www.palamos.net http://www.pucelawireless.net Redlibre http://www.redlibre.net Santiago de Compostela Wireless http://www.scqwireless.com Sevilla Wireless http://www.sevillawireless.net Zaragoza Wireless http://www.zaragozawireless.net CanadaWireless http://www.canada-wireless.net IrishWan http://www.irishwan.org BC Wireless http://www.bcwireless.net http://www.nora-wireless.net http://www.nycwireless.net http://www.seattlewireless.net France Wireless http://www.la-grange.net/2001/02/openwireless.html Open Wireless Network Forum http://www.opennetworks.rg3.net http://www.freenetworks.org http://www.personalteco.net BGP, Border Gateway Protocol RFC 1771 RIP, Routing Internet Protocol Version 1, RFC 1058 Version 2, RFC 2453 OSPF, Open Shortest Path First Version 2, RFC 2328 DHCP, Dynamic Host Control Protocol RFC 2131 R. Droms, "Dynamic Host Configuration Protocol", 3/97. http://www.dhcp.org Zebra, A routing software package for TCP/IP networks http://www.zebra.org Wireless Router HOWTO http://www.rage.net/wireless/wireless-howto.html Building Wireless Community Networks O'Reilly and Associates, January 2002 Rob Flickenger ISBN 0-596-00204-1 Designing Large-Scale LANs O'Reilly and Associates, January 2002 Kevin Dooley ISBN 0-596-00150-9 El protocolo 802.11b http://standards.ieee.org/getieee802/portfolio.html?agree=ACCEPT