Diferencia entre revisiones de «Criterios de asignación de direcciones IPv4»

Revisión de 16:53 13 nov 2011

Las asignaciones de direcciones IPv4 se realizan siguiendo los criterios que originalmente se establecieron en http://freenetworks.org y http://redlibre.net para permitir que mediante direcciones RFC 1597 se pueda crecer al máximo en las zonas «sin hilos» sin pisarnos ni con internet, ni con las diferentes comunidades y colectivos que hacen red, posibilitando que se puedan conectar entre ellas y facilitando así al mçaximo la capacidad de interconexión e interoperabilidad de redes cuando coincidimos en un mismo territorio o haya posibilidades de conectividad.

Estos criterios se han ido aplicando en las herramientas de gestión que hay en guifi.net. La gestión de este aspecto técnico es muy FEIXUC no sólo para los usuarios, sino también para los técnicos y administradores, de manera que conviene hacerlo de manera automática, con un autoservicio desasistido (minimizando la intervención de administradores de red humanos a la hora de hacer las asignaciones) y procurando que la gestión sea lo más eficaz posible. Puesto que guifi.net va creciendo y se van adoptando nuevas tecnologías, conviene actualizar estos criterios para homogeneizarlos al máximo y extraer el máximo de sus posibilidades en el futuro próximo, mientras no se adopte de forma generalizada un nuevo formato como es ahora el IPv6.

Puede haber redes ya existentes que no implementen estos criterios. En estos casos se hará lo posible para direccionarlas igualmente. En cualquier caso, y sobre todo de cara al futuro, conviene serguir extos criterios, aunque pueden causar que inevitablemente impidan el direccionamiento directo con otras redes vecinas.

En primer lugar, los criterios de asignación en función de los usos:

• Capa pública. Son aquellas que eventualmente tiene sentido que se publiquen más allá de la propia zona o comunidad sin utilizar ningún tipo de NAT. Corresponden por tanto a usuarios, servidores, aplicaciones o lo que sea que tenga sentido que disponga de una dirección única de nivel 3 alcanzando el número máximo de redes abiertas. Para estos usos se prevé el uso del rango de direcciones 10.0.0.0 - 10.255.255-255.255.

• Capa de gestión. Son aquellas direcciones que una red necesita para funcionar, pero que no se quiere que traspasen diferentes redes o comunidades. Por ejemplo, las que se utilizan para dispositivos internos, encaminadores (routers), enlaces, funcionamiento interno de protocolos (BATMAN, OLSR...). Estas direcciones se pueden reutilizar entre áreas o zonas diferentes que se gestionen de forma separada. En aquellos puntos donde se conecten se tienen que hacer los filtros oportunos que impidan que este tipo de direcciones se propaguen a las tablas de rutas que publica cada red. Para estos usos se prevé el uso del rango de direcciones 172.16.0.0 - 172.31.255.255.

• Capa privada. Son las que corresponden a las redes locales privadas que pueden estar conectadas, normalmente trás una NAT, a las redes abiertas. El uso típico es la red privada que hay tras un cortafuegos. Para este uso se prevé el uso del rango de direcciones 192.168.0.0 - 192.168.255.255.

Formas de asignación:

• Reservas de rangos para zonas. El rango de direcciones que se utiliza en cada zona para cada uno de los diferentes usos, el administrador lo puede asignar directamente en la página de la zona correspondiente. En caso de que nadie lo haga, se asignará automáticamente en el momento en que se deban asignar direcciones, reservando los rangos de entre los que estén libres en su zona de rango superior, permitiendo así que se puedan hacer las correspondientes reservas sin la intervención de administradores.
• Asignación automática de rangos de direcciones a las zonas.
• Una zona recibirá automáticamente un rango /24 de 255 direcciones. En caso de que la zona requiera más direcciones, para procurar la maxima contigüidad sin perder direcciones, se asignará sucesivamente una /23 y después una /22 hasta la /21, lo que hace un total de 3.832 direcciones útiles, y ampliaciones sucesivas en grupos de 2.046 direcciones.
• Asignación automática de direcciones públicas a las aplicaciones, nodo o servidores dentro de las zonas.
• Zonas en modo de infraestructura. Cada nodo que disponga de punto de acceso y esté en modo infraestructura recibirá un rango /27 de su zona (30 direcciones). Eventualmente se pueden recibir más si se le asignan, o se pueden asignar números de direcciones diferentes si lo hace un administrador. En un principio se reservan 30 dado que aunque potencialmente pueden gestionar un número superior de conexiones, lo que se pretende es que en condiciones normales, y en casos en que las conexiones son estables y utilizan el mismo canal, no tengan que compartir frecuencia y punto de acceso con un número elevado de nodos, maximizando así su rendimiento.
• Zonas en modo ad-hoc. Dado que los protocolos lo soportan (BATMAN, OLSR...), aquellos nodos que lo requieran, recibirán una dirección pública única dentro del rango global asignado a la zona. Cuando desde un nodo se quiera disponer de un rango de direcciones para conectar diversos dispositivos o servidores, el nodo se le podrá asignar un rango, que por defecto será un /28 (14 direcciones), pudiéndose asignar manualmente otros rangos.
• Asignación de direcciones en la capa de gestión. Simplemente se asignarán direcciones únicas, con la máscara correspondiente según el caso del tipo de zona. Estas direcciones pueden ser duplicadas cuando la zona es diferente. Por ejemplo, en zonas en modo infraestructura las direcciones de enlace se asignan en subredes de tipo /30, en zonas en modo ad-hoc se asigna típicamente una /16 y entonces se asignan dentro de esta /16 las direcciones una a una en el momento de dar de alta cada dispositivo de red, en función de sus características y de los protocolos que haya.
• Las direcciones privadas no se gestionan ni se reservan en ninguna herramienta de gestión sino que es responsabilidad del usuario gestionarlas.

Más allá de las zonas en modo infraestructura o en modo ad-hoc, se prevé también implantar zonas destrás de NATs, para aquellos casos en los que se quiera precindir de la capacidad de conexión entre zonas y coordinar las direcciones públicas. De todos modos se recomienda para estas zonas que se gestionen también utilizando direcciones fuera del rango de direcciones públicas, porque esto eventualemente crearía «sombras» y dificultaría la conectividad, incluso cuando se hace NAT.