-> Aviso:

-> Esta página está alojada de forma temporal en r00thouse

-> El presente contenido puede incluir datos que no están ligados ni administrados por r00thouse,

-> y posiblemente sea necesario un traslado.

Introducción al proyecto

La gente va despertando de su letargo en materia de independencia tecnológica. Múltiples voluntarios se han unido a la tediosa tarea de montar infraestructura para crear (y mantener) redes libres, desde federadas hasta descentralizadas. La completa descentralización trae algunos problemas: uno de los más graves es la colisión de direcciones.

Imagínense que dos proyectos de redes distribuidas (uno en La Paz y otro en Santa Cruz, por poner un ejemplo), donde un grupo piense en sí mismo como "el pionero" ignorando la existencia del otro, sienten sus bases por separado; las dos redes crecerán y se harán muy fuertes. Al encontrarse los dos grupos, se darán cuenta que comparten (más o menos) los mismos ideales, y se cooperarán mutuamente: se enlazarán.

Casualmente utilizan los mismos rangos de direcciones, y tendrán que negociar de maneras poco ortodoxas ("a la moneda" o con "fu manchú") quien se queda y quién se traslada. Y trasladar una red grande a otras direcciones no es fácil.

Y de paso, una red habrá sentado buenas bases (protocolos de ruteo moderno [si la red es mesh], soporte IPv6 completo, rangos de IP definidos estrictamente, posibilidad de peering iBGP, etc) y la otra, pues, tendrá que trabajar extra.

Y de ahí viene la idea: no queremos [obligar a] tomar decisiones sobre los proyectos de los distintos grupos voluntarios.

Sólo queremos mencionar recomendaciones muy básicas, y mostrar datos del funcionamiento de las redes libres en Bolivia; información estrictamente importante para que todos convivan en paz y en armonía, mirando hacia el futuro.

Recomendaciones organizativas de la sig. Política

Las siguientes recomendaciones están diseñadas para una gran flexibilidad: no todos los proyectos estarán de acuerdo en utilizar los mismos protocolos, las mismas herramientas, los mismos servicios, etc.

Recomendaciones básicas de direccionamiento

Sobre las asignaciones de direcciones IPv4

Siguendo el estándar de facto de freenetworks.org y guifi.net, la presente recomendación regulará los siguientes rangos de direcciones:

10.0.0.0/8 [10.0.0.1 - 10.255.255.0]
172.16.0.0/12 [172.16.0.1 - 172.31.255.255]

Se sigue el siguiente esquema para asignar:

Sobre las asignaciones de direcciones IPv6

La presente recomendación regulará los siguientes rangos de direcciones:

fd4f::/16 [Bolivia, tránsito estándar]

Se sigue el siguiente esquema para asignar: [cod priv país]:[cod red interna/región]:[cod ubic]:[cod final]::

El código país en rango privado se define: (0xfc00 [inicio de rango privado] + (0x24f [cod pais 591 en hex] - 0x100 [offset]) = 0xfd4f)

El código final y el código de ubicación lo define cada red interna. Pueden ser aleatorios, ordenados o importados de algún otro lugar (ej. correspondencia geográfica, códigos postales, catastro, etc)

Sobre las asignaciones de Identificadores de Sistema Autónomo

AS 65400 - AS 65534 (del rango original 64512 - 65534)
4200020000 - 4200029999 (del rango original 4200000000 - 4294967294)

Sobre las restricciones en la asignaciones de direcciones IPv4

Para asegurar compatibilidad completa con redes privadas ajenas (no-mesh, no-comunitarias, [no-]etc..), los siguientes rangos no se podrán reservar por ningún equipo (aunque sean incluidas en la máscara de red):
- 10.0.0.0/16 [10.0.0.1 - 10.0.255.255]
- 192.168.0.0/16

Consideraciones extras

La asignación de rangos IPv4 que se especifica acá es incompatible con las asignaciones que utilizan otras iniciativas. Creemos que, para el momento en que las demás iniciativas terminen de desarrollarse*, y sea posible interactuar con redes fuera de América del Sur, el protocolo IPv4 haya sido reemplazado por su contraparte IPv6, y por lo tanto, declarar estas rutas conflictivas como obsoletas.

* (añadir soporte IPv6, asignación de 4-bit AS, etc)

Recomendaciones básicas sobre autoridades y administración

Para posibilitar la interacción entre redes distintas, necesitamos definir un nivel de jerarquía.

Autoridad de rango
- Propietario de rango

Autoridad de rango

Es el grupo/equipo que gestiona la iniciativa de la red. Ejemplo: "Hacklab Lago Titicaca"

Usualmente se le entrega un sólo identificador de Sistema Autónomo (AS) y un rango grande de direcciones a esta red (/17): este grupo/equipo administrará interiormente estas direcciones como crea conveniente. De todas maneras, se recomienda comunicar esas decisiones internas al Registro del Portal.

El grupo/equipo podrá solicitar más rangos de direcciones mientras los que administre se vayan ocupando.

Propietario de rango

Es el grupo/equipo/institución/particular que administra un pequeño rango de IPs: este rango es asignado por la Autoridad de rango.

Ejemplo: el "Colegio Foobar" forma parte de la red libre del "Hacklab Lago Titicaca". Este colegio desea implantar servicios y conectividad fácil a sus estudiantes, y necesita un rango de direcciones IP públicas. El "Hacklab" deberá sugerirle cierto rango de direcciones IP públicas.

Se recomienda asignar a este propietario, rangos de direcciones IP pequeños (/29, /28, /27) a menos que se vea necesario asignaciones más grandes (/26, /25). El grupo/equipo/institución/particular deberá poder solicitar más rangos de direcciones mientras los que administre se vayan ocupando.

Recomendaciones técnicas de la sig. Política

Tecnología para la interacción entre redes distintas

Para asegurar la interoperabilidad entre redes, producto de distintas iniciativas, se sugiere utilizar:

Para la interconexión entre redes distintas
- Distintos rangos de direcciones IPs entre redes
- Administración compartida (o al sorteo) de [al menos] un Punto de Intercambio entre redes
  - Soporte completo de ruteo manual (IPv4, IPv6)
  - Soporte completo de [i]BGP (IPv4, IPv6)

Registro público

El registro de la red (actualmente llamada "La Otra Red") se encuentra en: [1]