Política Común para Convivencia de Redes Libres

-> 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.

Se reciben contribuciones y se puede dialogar en el pad: [[1]]

---

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 IP

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

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

Sobre las asignaciones de Identificadores de Sistema Autónomo

1. AS 65500 - AS 65534 (del rango original 64512 - 65534)
2. 4242420000 - 4242429999 (del rango original 4200000000 - 4294967294)

Sobre las restricciones en la asignaciones de direcciones IP

• Para asegurar compatibilidad completa con redes 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]

Consideraciones extras

• La asignación de rangos IPv4 que se especifica acá es incompatible con las recomendaciones de 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: este grupo/equipo administrará interiormente estas direcciones como crea conveniente. De todas maneras, se recomienda comunicar esas decisiones internas a este Registro Público (opcional).

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?) a menos que se vea necesario asignaciones más grandes. 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

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

(Estos datos son ficticios y puramente demostrativos. Por lo tanto, no se reconoce ningún valor a estos)

// Reimplementar esto con tablas, mientras tanto

// Se necesita un script simple (¿php? ¿python? ¿sqlite?) que maneje esto automáticamente

Registros IPv4

• 10.1.0.0/22 [LaPaz-Libre / HackLab La Paz - r00thouse] 10.1.0.0 - 10.1.3.254 (1022 hosts)
  • 10.1.0.0/25 [LaPaz-Libre / HackLab La Paz - r00thouse] 10.1.0.0 - 10.1.0.62 (126 hosts)
  • 10.1.0.65/29 [Luis Fernando Mita] 10.1.0.65 - 10.1.0.70 (6 hosts)
  • 10.1.0.73/29 [Fundación Augusto Ratón] 10.1.0.73 - 10.1.0.78 (6 hosts)
• 10.1.4.0/23 [Red Ciudadana Libre - RCL LA PAZ] 10.1.4.0 - 10.1.5.255 (510 hosts)
  • (registros no públicos)
• 10.1.6.0/24 [HackLab Lago Titicaca] 10.1.6.0 - 10.1.6.255 (254 hosts)
  • (registros no públicos)

Registros IPv6

(...)