Guifi.net - Wiki Hispano - Contribuciones del usuario [es]

Manifiesto Tecnosoberano

2022-01-15T10:45:18Z

Al: Página creada con «El siguiente apartado es una propuesta a identificar las tecnologías que respetan lo que deberían ser todos los derechos de las usuarias y, por lo tanto fomentarla y, pre...»

El siguiente apartado es una propuesta a identificar las tecnologías que respetan lo que deberían ser todos los derechos de las usuarias y, por lo tanto fomentarla y, pretende ser, con la colaboración de las hacktivistas, una guía para las comunidades críticas con la tecnología en nuestros tiempos.

== Características deseables para tecnologías empoderadoras ==
El concepto de lo que significa software libre sigue siendo el definido en el año 1984 con la primera licencia de software libre. Las dos actualizaciones en la licencia que se han escrito mantienen la esencia que es garantizar la libertad a las usuarias para usar, modificar, distribuir copias exactas o modificadas de los programas.
Lo que ha cambiado es el propio concepto de software. En un ejemplo paradigmático podemos ver que la Free Software Foundation en marzo de 2016 empezó a tener en cuenta que muchos códigos Javascript iban mucho más allá de simplemente ofrecer funciones estéticas y se podían considerar software en sí mismos. Al intentar comprobar si muchos de esos programas podían ser usados, modificados, distribuidos y distribuir sus modificaciones identificaron que muchos de ellos no son libres<ref>https://www.gnu.org/philosophy/javascript-trap.es.html</ref>.
Por otro lado, como hacktivistas lo que aspiramos es a que las tecnologías no solo sean basadas en software libre, sino que, además, sean empoderadoras. Es decir la libertad en el software es un requisito indispensable para que una tecnología facilite un empoderamiento y, por lo tanto, un cambio social ético, pero ese requisito no es el único. Por ejemplo, el software libre corriendo en un servicio/servidor que espía a sus usuarias sin que éstas tengan opción de impedirlo (y, muchas veces, ni siquiera de conocerlo) es práctica común hoy día. La forma práctica que tenemos de impedirlo<ref>La forma teórica es comprobar que los programas que están corriendo en máquinas que no controlamos llevan la licencia GPL actualizada, la versión 3, con la clausula Affero, que puso a disposición la Free Software Foundation en 2007 cuando se identifió el problema y empezaba a a ser habitual encontrarlo.</ref> es correr tú tu software, de forma autónoma y autogestionada en tu propio servidor y securizarlo –en el caso que sea una tecnología que funciona según el modelo cliente/servidor– o tu propio dispositivo personal como computadora, teléfono,... –en el caso que sea una tecnología que funciona según el modelo P2P–, utilizando tu propia red y/o sistemas de cifrado y, para permitirte la interconexión con otras personas u organizaciones en otros servicios/servidores, utilizar formatos y protocolos estandarizados sobre los cuales poder decidir cuáles contenidos distribuyes al mundo, cuáles a tus contactos y cuáles no distribuyes en absoluto.
Vamos a extraer de lo anteriormente dicho las características que son requisitos indispensables para considerarlas tecnologías recomendables para el cambio social ético, empoderadoras:
Software Libre, Autonomía, Seguridad, Privacidad, Estandarización, Control sobre los contenidos. Y una forma transversal de valorarlas es preguntarse cómo de próxima y apropiada es la tecnología que estamos utilizando.

Pasemos brevemente a describir cada una de estas características.

=== Software Libre ===
Para una descripción detallada de qué es software libre:
https://www.gnu.org/philosophy/free-sw.es.html
Lo que sí que debemos mirar es cada software que corre la tecnología en concreto, es decir, comprobar que es Software Libre tanto del lado del cliente como del lado del servidor,
Por ejemplo, Telegram es software libre del lado del cliente, pero no del lado del servidor, por lo tanto, ya solo por este motivo no es una tecnología recomendable para el empoderamiento.
Para valorar si un programa libre es próximo y apropiado, a parte de comprobar que mantenga las 4 libertades debemos comprobar si puede ser ejecutado en hardware popular y/o económico o, por el contrario, necesita ser ejecutado en hardware muy potente y/o específico. Debemos comprobar si tiene documentación y ésta es entendible al colectivo al cual está dirigido el programa o si por el contrario la documentación es escasa o nula o es demasiado complicada o no está escrita en los idiomas que entienden las usuarias a los cuales va dirigido. Además, si se trata de un programa de uso social y/o que puede crear dependencia debemos comprobar también si la organización que hay detrás tiene unos valores éticos en términos de inclusión, igualdad, etc...<ref>Según estudios, existe un marcado sesgo de género en la aceptación o no de contribuciones externas llevadas a cabo por mujeres en ciertos proyectos de software libre que pueden ser identificados. Terrell et al. 2017 https://web.eecs.umich.edu/~weimerw/2019-481F/readings/genderpull.pdf</ref> De todas formas todas estas comprobaciones y las valoraciones que se extraen son útiles en tanto en cuanto haya que tomar decisiones en cuanto a cuál utilizar entre dos o más programas libres, no así si solo existe un programa software libre y su alternativa es uno privativo. Recordemos que, aun si el programa no es próximo y apropiado, puede llegar a serlo, dado que, al ser libre, la comunidad puede suplir estas carencias por sí misma.<ref>Ejemplo paradigmático fue el de la comunidad de Wikipedia en español, la cual al comprobar la deriva que llevaba Wikipedia hacia potencialmente convertirse en una punto com financiada con publicidad inicialmente llevó a cabo un fork el cual presionó a convertirse en una fundación sin ánimo de lucro https://es.digitaltrends.com/tendencias/rebelion-espanola-wikipedia-facebook/ </ref>

=== Autonomía ===
La autonomía en el campo de la tecnología social es la capacidad que tiene una persona o una organización voluntariamente constituida por sus miembros de tomar y ejecutar decisiones sin intervención ni influencia externa.
Esas decisiones incluyen cuestiones de infraestructura (qué hardware utilizar, dónde, qué redes,...), de funcionalidad (qué programas y de qué manera se utilizarán), de diseño, organizativas, etcétera...
Esas decisiones incluyen la capacidad de los miembros de una organización a abandonar la organización o la infraestructura y poder replicar la tecnología tal como la utilizaban en otra organización y/o infraestructura.
Por ejemplo, el conocido servicio de Signal está sustentado por software libre del lado del cliente. Y también publica como software libre una versión del servidor pero no es exactamente la que se utiliza en el servicio<ref>https://www.world-today-news.com/signal-messenger-is-no-longer-open-source/ </ref>, pero sobretodo no provee autonomía a sus usuarias dado que le requiere la intervención externa de usar un número de teléfono, el cual depende de una tecnología no basada en software libre, ni que, a su vez provee autonomía, ni privacidad.
Por supuesto, podrían abandonar la infraestructura y tomar el software publicado y hacer su propio sistema tecnológico totalmente autónomo, pero al no poder contectarse con el otro el sentido de ellos quedría en entredicho al tratarse este de una tecnología ideada para la comunicación con el mayor número de personas posible.
Las tecnologías históricas de Internet (como la web o el correo electrónico) funcionan según el modelo cliente-servidor y han requerido históricamente ordenadores más potentes de los que podían disponer personas particulares en sus casas y por eso un mismo servidor ha mantenido a muchas usuarias (muchas páginas web de muchas usuarias o muchas cuentas de correo eléctronico). En ese contexto, la gestión de esos servidores por parte de movimientos sociales han propiciado, en algunos casos, la creación de asambleas para administrar esos servidores, en otros casos ha sido llevado a cabo por personas que se han ofrecido a centralizar la administración de esos servidores, lo cual ha supuesto que no fueran realmente autogestionados por los miembros, incluso que las personas erigidas en administrarlos usaran su poder de forma jerárquica en algún momento. En estos casos podemos identificar una relación inversa entre la proximidad y la verdadera autonomía de las que disponen las personas y organizaciones que utilizan estas tecnologías. Ciertamente Internet facilita poder utilizar tecnologías que se pueden encontrar a mucha distancia física y lógica de las personas y también, en poco tiempo, puede producir cientos de miles de usuarias. Podríamos decir que una característica transversal a todas es preguntarse cómo de próxima es una tecnología hacias las personas que las están utilizando.
Otra manera de valorar cuánto de autonomía provee una tecnología en concreto es preguntarse si puede ser utilizada íntegramente en una Red Libre<ref>Utilizamos aquí la forma más difundida en español para hacer referencia a las redes de telecomunicaciones digitales TCP-IP creadas y pertenecientes a las usuarias (habitualmente a partir de las tecnologías WiFi). Otros nombres menos populares son “Red Ciudadana”, “Red Comunitaria”, “Red WiFi”, una combinación de estos adjetivos o la forma inglesa “Community Network”.</ref>. Cualquier servidor software libre puede instalarse en una Red Libre y por lo tanto las capacidades comunicativas pueden ser utilizadas independientemente de si las cualidades de conexión a la red de redes internet son precarias, intermitentes o incluso inexistentes. No es así de cualquier paquete de Software como Servicio. Ya sea del estilo de Instagram o Google Maps o el mencionado Signal.
Otra forma de conseguir autonomía en tecnología de comunicaciones es en base a las tecnologías P2P (Peer to Peer, entre pares) en la que directamente el programa que provee la comunicación y los datos están gestionado por cada persona y no por una organización (cada persona que tenga un dispositivo que soporte el programa). Es la tecnología de comunicación entre pares (normalmente el protocolo) la que hace las funciones de “organización” de forma ya previamente definida como conjunto de “normas”. Este caso, pues, es mucho más deseable en términos de autonomía dado que impide la corrupción o la supeditación de miembros a una asamblea.

=== Seguridad ===
La seguridad es el conjunto de tecnologías (o partes de tecnologías) que proporcionan protección para la información de las usuarias de manera que mantengan sus principios de disponibilidad, integridad y confidencialidad.

=== Privacidad ===
La privacidad (o la intimidad) en tecnología social son las características y habilidades que tiene una tecnología para preservar a una persona u organización del resto y que permitan a éstas expresarse selectivamente, es decir, permitir mantener la confidencialidad.
La confidencialidad es la propiedad de la información por la que se garantiza que esté accesible únicamente a personal autorizado a acceder a dicha información.
La seguridad es un requisito para el éxito de la privacidad.

=== Estandarización (por consenso) ===
En tecnología social la estandarización es el proceso por el cual se crea un modelo (por ejemplo un formato o un protocolo) en base a una necesidad y a partir del modelo se crean o se adaptan tecnologías que se adecuen a él.
Decimos que una tecnología está estandarizada cuando existe ese modelo. Hay varias formas de crear el modelo, definimos la estandarización por consenso en contraposición a la estandarización de facto. La estandarización es por consenso cuando se lleva a cabo a partir de una comunidad abierta a la participación de las personas y las organizaciones interesadas. La estandarización de facto es la que se produce cuando es un software en concreto el que acaba definiendo un modelo.
El resultado de un proceso de estandarización en tecnología social es la creación de estándares de protocolos o formatos sobre los cuales se pueden construir varias tecnologías (por ejemplo softwares) que van a permitir la interconexión entre ellas.
Es deseable que una tecnología tenga ya realizado un estándar por consenso (por ejemplo el correo electrónico) o esté en proceso de estandarización (si es muy nueva) porque nos garantiza por un lado que nuevas versiones de un mismo software serán compatibles con versiones anteriores y, por otro, que varios softwares se puedan comunicar entre ellos. Así las usuarias no son dependientes de un software en concreto o se pueden crear el suyo propio desde cero.
A su vez, permite y facilita procesos también deseables como la federación y, por todo ello repercute en el grado de autonomía y, por lo tanto, en el empoderamiento.

=== Control sobre los contenidos ===
En el campo de las tecnologías de la información y la comunicación los contenidos son los datos estructurados como información semántica (blogs, redes sociales, mensajería,…). El control de esta información es una moneda de cambio actual entre las grandes corporaciones de internet. Muchos servicios “gratuitos” piden que la usuaria acepte como condición de uso del servicio que el control de los contenidos pasen a ser gestionados por dicho servicio. Otros servicios se mantienen por siempre bajo control de las usuarias. Por ejemplo decimos que la comunidad de editores de Wikipedia tiene control sobre los contenidos porque puede hacer uso, modificación, copia y distribución de copias modificadas de los contenidos libremente y sin perder la autoría. El control sobre los contenidos bajo los cuales hay garantizada la privacidad permite decidir a la persona u organización creadora de un contenido (un artículo o un mensaje) cuándo y a quién hacer público ese mensaje. Por ejemplo con un servidor de archivos instalado por la propia usuaria en su espacio físico y con acceso por clave asimétrica es la usuaria la que decide a quién, cuándo y cuáles le da acceso a esos archivos.

== Proximidad, género, raza, alteridad,... Acceso al Conocimiento ==
A pesar de que el software libre, en el contexto de la ética hacker, cuestiona las formas de hacer y los valores del capitalismo, y aunque sus fundamentos son colaborativos y no competitivos, algunas de sus comunidades viven tensiones al estar inmersas en complejas relaciones de poder. Así pues, se observan relaciones de poder y meritocracias puntuales que pueden convertirse en jerarquías de larga duración. De igual forma, es evidente el desarrollo más veloz en los proyectos de software libre que obtienen más financiamiento o que les son más beneficiosos a la industria capitalista en la que se inscriben<ref>Un ejemplo de ello es el programa de modelado y animación 3D, Blender, el cual es software libre y que tuvo un desarrollo muy veloz debido al financiamiento de la industria del entretenimiento estadounidense, particularmente cine y videojuegos.</ref>.
El alejamiento de las mujeres del dominio de la técnica y por lo tanto, el despojo de cierto saber-hacer continúa hasta nuestros días, tanto fuera como dentro de la hegemonía tecnológica. Esto incluye el campo de la computación en general, las tecnologías de la comunicación. Pero incluso la participación de las mujeres en el movimiento de software libre es considerablemente menor que en el de software privativo, ya que “solo el 2% de las personas que trabajan en el desarrollo de tecnologías son mujeres, mientras que en la industria del software privativo, el porcentaje es de 28%” (Baroni, 2013:125). Si bien resulta paradójico que la participación de las mujeres que escriben código sea menor en un espacio aparentemente progresista, también es cierto que las reflexiones feministas han evidenciado que esto sucede en prácticamente todos los movimientos que pretenden la transformación social, aunque estos incorporen discursos de equidad de género. Asimismo, personas con identidades diversas, afrodescendientes, indígenas, transgénero, del área rural, etcétera, se encuentran ausentes o con poca participación.
En el contexto de este trabajo, las mujeres hacker son aquellas que desarrollan, diseñan y mantienen tecnología computacional dentro de las comunidades de software libre, mujeres en condición de excepcionalidad —y que gozan de ciertos privilegios, probablemente vinculados a su clase o raza— que a pesar del supuesto alejamiento tecnológico, marginalidad de saberes com plejos y desvalorización del saber-hacer del que hablé al principio, aunado a su poca participación en este...

== Dos ejemplos sobre gobernanza ==
{{en desarrollo}}
redes distribuidas a partir de software de enrutamiento dinámico (libremesh) vs guifi.net
retroshare vs servidores autogestionados

== Anotación sobre economía, gasto energético y hardware ==
{{en desarrollo}}
hablar de la blockchain
exceden el propósito de este manifiesto

== Propuesta: la identidad tecnosoberana ==
Lo que empezó como una broma ha mutando en herramienta útil y seria al generarse el corpus teórico de este documento.
Declararse tecnosoberano o tecnosoberana es llevar a cabo no solo un compromiso personal con la crítica hacia la tecnología y ser consciente de las repercusiones sociales y políticas de las tecnologías que estás utilizando sino que, además, y dado que estamos inmersas en relaciones sociales, económicas y políticas mediadas por tecnologías, en esta mediación podemos verbalizar que vamos a procurar llevar a cabo en medida de lo posible el uso de tecnologías que reúnan las características de libertad, autonomía, seguridad, privacidad, estandarización y control sobre los contenidos que son éticas y empoderadoras.
Ser tecnosoberano o tecnosoberana no es ni una imposición ni siquiera una identidad inmutable, tampoco, más allá de los propósitos de seguir y alimentar la broma, un dogma. Pero sí que es ponerle nombre identitario a un conjunto de prácticas que ya hace tiempo<ref>Por ejemplo nos encontramos el “Pringao HowTo” del año 2000 aprox</ref> que se están llevando a cabo en colectivos y personas y que muchas veces quedan injustamente invisibilizadas en las interaciones sociales, políticas y económicas bajo el aluvión de populares tecnologías privativas.
Ser tecnosoberano o tecnosoberana es utilizar, difundir y participar en el desarrollo únicamente de tecnologías digitales que tengan las seis características empoderadoras. Al mismo tiempo es visibilizar la importancia del uso crítico de la tecnología y participar de la creación de un ecosistema cómodo para la interacción de personas tecnosoberanas.

== El porqué del nombre ==
Un movimiento identitario necesita un nombre que quede anclado a campos semánticos anteriores, con fuerza y que permita recordarse fácilmente. El movimiento del software libre ha sido y sigue siendo la piedra angular de muchos movimientos por la soberanía y el empoderamiento y progresivamente va incluyendo también defensas por la autonomía9, la seguridad10, la privacidad11, la estandarización12 y el control sobre los contenidos13. Por ello la palabra softwarelibrana, freesoftwarer y similares fueron valoradas en un borrador de este documento, pero fueron descartadas por dos motivos: por ser larga y dificilmente traducible y porque el movimiento por la soberanía tecnológica adquirió un recorrido añadir trayectoria histórica del movimiento por la soberanía tecnológica. El problema de la expresión tecnosoberana es que, para ser concreta debería llevar a cabo el "apellido" digital, ya que es concretamente de las tecnologías digitales de las que estamos hablando, ya que son las más asequibles para obtener soberanía14. En cuanto a la creación del adjetivo que acaba de la misma manera que otras identidades conocidas y relativamente respetadas como “vegano” evoca que se es tecnosoberano o tecnosoberana no solo porque se utilice únicamente software libre (como los veganos no los son solo porque únicamente comen vegetales, si no porque eso entra dentro de una filosofía de vida que tiene que ver en evitar el sufrimiento animal). La identidad tecnosoberana no es descrita únicamente por utilizar solo software libre, sino es precisamente la suma de las 6 características. {{en desarrollo}}

== Notas ==
<references />
==Notes==
<references />

LibreMesh

2018-02-10T22:59:52Z

Al: /* Cómo escoger la versión de firmware a instalar */

'''LibreMesh''' es una iniciativa llevada adelante por miembros de redes comunitarias de diferentes continentes que se organizan para unificar esfuerzos en el desarrollo de herramientas útiles para facilitar el despliegue de Redes Libres para cualquier comunidad del mundo.

La herramienta principal es el [http://libremesh.org/ firmware LibreMesh]: basado en [[OpenWrt]] y [[LEDE]] estandariza la creación de comunidades WiFi y provee de [[roaming]] a las comunidades ya existentes.

Otras herramientas son:

*[http://docs.altermundi.net/LibreNet6 Librenet6]: un mesh tunnel broker para proveer IPv6 globales a las redes libres
*[https://chef.altermundi.net/ Chef]: creador de firmwares a medida para comunidades
*[https://github.com/libremap Libremap] (en colaboración con Freifunk): representación de nodos según su ubicación geográfica con actualización de calidades de enlace a tiempo real.

Las herramientas se pueden utilizar por separado o todas juntas, actualmente estamos trabajando en la integración automatizada del uso de todas ellas.

Este proyecto nació como un esfuezo para fusionar algunos proyectos de firmware preexistentes:

* AlterMesh (de AlterMundi, Argentina)
* qMp (de guifi.net, Catalunya)
* eigenNet (de eigenLab, Ninux, Italia)

Y con el apoyo de algunas organizaciones existentes:

* the Free Network Foundation (de USA)
* the Guifi.net Foundation (de Catalunya)

Si quieres colaborar con el proyecto [https://lists.libremesh.org/mailman/listinfo/lime-dev utiliza la lista de correo de desarrolladores] o la [https://lists.libremesh.org/mailman/listinfo/lime-users de usuarios]

== Cómo escoger la versión de firmware a instalar ==
A partir del Chef puedes escoger una de estas versiones según tus necesidades, si en tu zona no se está usando ninguna todavía, se recomienda usar la última estable:
{| class="wikitable" style="text-align: center;"
!rowspan="2"| Version and Download
!rowspan="2"| Release date:
!rowspan="2"| Based on
!colspan="5"| Supported routing protocols
!rowspan="2"| Default interface mode for links
!rowspan="2"| Internet Detection
!rowspan="2"| Centralized DNS
!rowspan="2"| Distributed DNS
!rowspan="2"| Anygw
!rowspan="2"| Web interface
!rowspan="2"| Backward compatibility
!rowspan="2"| Librenet6 (Tinc)
!rowspan="2"| Networks using it
|-
! BATMAN-Adv
! BMX6
! BGP
! OLSR (v1, v2, v6)
! BABEL
|-
! 36140
|
|
| y
| n
| n
| n
| n
| IBSS (ad-hoc)
| y
| y
| n
| n
|
|
| [http://docs.altermundi.net/LibreNet6/Setup Manually configured]
|
|-
! 15.04 (44952)
|
|
| y
| y
| n
| n
| n
| IBSS (ad-hoc)
| n
| n
| n
| y
|
|
| [http://docs.altermundi.net/LibreNet6/Setup Manually configured]
|
|-
! 15.07rc1
|
|
| y
| y
| n
| n
| n
| IBSS (ad-hoc)
| n
| n
| y
| y
|
|
| [http://docs.altermundi.net/LibreNet6/Setup Manually configured]
|
|-
! 15.07final
|
|
| y
| y
| n
| n
| n
| IBSS (ad-hoc)
| y
| y
| y
| y
|
|
| [http://docs.altermundi.net/LibreNet6/Setup Manually configured]
|
|-
! 16.07 Community Chaos
|
| OpenWrt 15.05.1 Chaos Calmer
| y
| y
| available
| available
| n
| IBSS (ad-hoc)
| y
| y
| y
| y
| basic
| break
| [http://docs.altermundi.net/LibreNet6/Setup Manually configured]
|
|-
! [http://downloads.libremesh.org/dayboot_rely/17.06/targets/ 17.06 Dayboot Rely]
| 2017-09-24
| LEDE
| y
| y
| available
| available
| n
| mesh point (802.11s)
| y
| y
| y
| y
| basic (Spanish supported)
| break
| [http://docs.altermundi.net/LibreNet6/Setup Manually configured]
|
|-
! 18.XX
| 2018-XX-XX
|
| y
| y
| available
| available
|
| mesh point (802.11s)
| y
| y
| y
| y
|
|
| [https://github.com/libremesh/lime-packages/issues/99 Maybe by default]
|
|}

''[[/Changelog|Mas sobre el Changelog]]''

El splash se puede instalar de la siguiente manera:
''en desarrollo''

El reconocimiento de nombres dentro de batctl se habilita de la siguiente manera:
''en desarrollo''

== Enlaces externos ==
* [http://libremesh.org Página oficial]

[[Categoría:MANET]]

LibreMesh/Changelog

2018-02-10T22:26:16Z

Al:

== Changelog 17.06 ''Dayboot Rely'' ==
* based on LEDE 17.01.2
* build everything using LEDE SDK, via new lime-sdk cooker (instead of lime-build)
* use ieee80211s instead of adhoc
* reintroduced <code>firewall</code> package (to keep closer to upstream)
* lime-system: fix ieee80211s proto, correctly construct ifnames
* lime-system: sanitize hostname (transform everything into alphanumeric and dash)
* lime-system: new proto static
* lime-system: new wifi mode client
* lime-system: set <code>dnsmasq force=1</code> to ensure dnsmasq never bails out
* lime-system: explicitly populate <code>/etc/config/lime</code> with calculated values
* lime-webui: enable i18n, finally webinterface is available in Spanish
* lime-webui: Major rework by NicoPace, thanks!
** bmx6 node graph now uses colors in a clever way
** simple way to add "system notes" that are shown along with /etc/banner and webui
** luci-app-lime-location: fix google maps api key
** new read-only view: switch ports status
** alert luci-mod-admin users that their changes might get overwritten by lime-config
** fix batman-adv status webui
* new package available to install <code>lighttpd</code> instead of <code>uhttpd</code> (needed for an upcoming android app)
* added a <code>lime-sysupgrade</code> command: does a sysupgrade but only preserving libremesh configuration file
* added a <code>lime-apply</code> command: basically calls reload_config, but also applies hostname system-wide without rebooting
* lime-hwd-ground-routing: ground routing now supports untagged ports too
* lime-proto-anygw: unique mac based on ap_ssid (using <code>%N1</code>, <code>%N2</code>)
* lime-proto-anygw: integrate better into <code>/etc/config/dhcp</code> instead of <code>/etc/dnsmasq.d/</code>
* lime-proto-wan: allow link-local traffic over wan (useful for local <code>ping6</code> and <code>ssh</code>, without global exposure)
** lime-proto-batadv: set <code>batadv gw_mode=client</code> by default to counteract rogue DHCP servers
** lime-proto-bmx6: introduce <code>bmx6_pref_gw</code> option, adds priority (x10) to a specific bmx6 gateway
** lime-proto-bmx6: don't tag bmx6 packets over ethernet and so use at least <code>mtu=1500</code> everywhere
* lime-proto-bmx6: avoid autodetected wan interface use vlan for bmx6
* bmx6: doesn't flood log with some spurious warnings anymore (<code>syslog=0</code>)
* bmx6: sms plugin now enabled by default
* bmx6: daemon is now supervised by procd, so it is restarted in case of crashes
* bmx6: doesn't <code>configSync</code> by default anymore (no more "uci pending changes" because of auto-gw-mode)
* new bmx6hosts tool: maintain an <code>/etc/hosts</code> that resolves fd66: <-> hostnames.mesh
* watchping: convert to procd and add reload triggers
* safe-reboot: fix, use <code>/overlay/upper</code> instead of <code>/overlay</code>
* safe-reboot: add </code>discard<code> action
* ath9k: debugged some hangs (interface is deaf) and workaround it, with new package <code>smonit</code>
* set wifi default <code>distance</code> parameter to 1000 metres and make it configurable through webui
* alfred: fix bat-hosts facter, check for errors and don't nuke <code>/etc/bat-hosts</code> in case of failure
* introduce new lime-basic-noui metapackage
* new packages separated: lime-docs and lime-docs-minimal
* various Makefile dependency problems fixed

== Changelog 16.07 ''Community Chaos'' ==
* Based on OpenWrt Chaos Calmer 15.05.1
* Removed <code>firewall</code> package (which is included by default in vanilla OpenWrt/LEDE), since it's not really being used in LibreMesh setup. It can always be installed on a case-by-case basis using <code>opkg</code>.
* Removed <code>odhcpd</code> since we're not using it at the moment (we use <code>dnsmasq</code>)
* Removed <code>odhcp6c</code> since we're not using it at the moment (we still haven't solved how to deal with native IPv6 coming over WAN, i.e. propagate a delegated prefix over the mesh in a reasonable way)
* New default packages: <code>lime-hwd-openwrt-wan</code> and <code>lime-proto-wan</code>. This checks if there's a WAN port, and automatically configures as "wan" proto (<code>lime-proto-wan</code>). The "wan" proto let's you assign in <code>/etc/config/lime</code>, for example, 802.1ad VLANs over the WAN port.
* New default package: <code>lime-hwd-ground-routing</code>. Allows you to configure 802.1q VLANs on embedded switches, so that you can separate specific ports and put
* New default package: <code>bmx6-auto-gw-mode</code>, so that when a node detects (with watchping) it can ping 8.8.8.8 over WAN port, a bmx6 tunIn is created on-the-fly, and Internet is shared to the rest of the clouds.
* Workaround for an spurious log message caused by BATMAN-Adv (<code>br-lan</code>: received packet on bat0 with own address as source address"): a <code>dummy0" interface is created and added to <code>bat0</code>, with a slightly different MAC address
** https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2014-March/011839.html
* New available packages: <code>lime-proto-bgp</code>, allows to do BGP with bird daemon; and <code>lime-proto-olsr</code>, <code>-olsr2</code> and <code>-olsr6</code>, which add support for all versions of [[OLSR]].
* Some new settings possible in <code>/etc/config/lime-defaults</code>
** <code>wireless.htmode</code> lets you preset the htmode for any wireless radio (or <code>htmode_2ghz</code> and <code>htmode_5ghz</code> for specific bands)
** <code>wireless.distance</code> is the equivalent, for setting distance (and <code>distance_2ghz</code> / <code>_5ghz</code>)

Libremesh

2018-02-10T17:31:54Z

Al: Página redirigida a LibreMesh

#Redirect [[LibreMesh]]

LibreMesh/Changelog

2018-02-10T17:30:51Z

Al: Al movió la página Libre-mesh/Changelog a LibreMesh/Changelog

Changelog 17.06

* based on LEDE 17.01.2
* build everything using LEDE SDK, via new lime-sdk cooker (instead of lime-build)
* use ieee80211s instead of adhoc
* reintroduced "firewall" package (to keep closer to upstream)
* lime-system: fix ieee80211s proto, correctly construct ifnames
* lime-system: sanitize hostname (transform everything into alphanumeric and dash)
* lime-system: new proto static
* lime-system: new wifi mode client
* lime-system: set dnsmasq force=1 to ensure dnsmasq never bails out
* lime-system: explicitly populate /etc/config/lime with calculated values
* lime-webui: enable i18n, finally webinterface is available in Spanish
* lime-webui: Major rework by NicoPace, thanks!
* bmx6 node graph now uses colors in a clever way
* simple way to add "system notes" that are shown along with /etc/banner and webui
* luci-app-lime-location: fix google maps api key
* new read-only view: switch ports status
* alert luci-mod-admin users that their changes might get overwritten by lime-config
* fix batman-adv status webui
* new package available to install lighttpd instead of uhttpd (needed for an upcoming android app)
* added a lime-sysupgrade command: does a sysupgrade but only preserving libremesh configuration file
* added a lime-apply command: basically calls reload_config, but also applies hostname system-wide without rebooting
* lime-hwd-ground-routing: ground routing now supports untagged ports too
* lime-proto-anygw: unique mac based on ap_ssid (using %N1, %N2)
* lime-proto-anygw: integrate better into /etc/config/dhcp instead of /etc/dnsmasq.d/
* lime-proto-wan: allow link-local traffic over wan (useful for local ping6 and ssh, without global exposure)
* lime-proto-batadv: set batadv gw_mode=client by default to counteract rogue DHCP servers
* lime-proto-bmx6: introduce bmx6_pref_gw option, adds priority (x10) to a specific bmx6 gateway
* lime-proto-bmx6: don't tag bmx6 packets over ethernet and so use at least mtu=1500 everywhere
* lime-proto-bmx6: avoid autodetected wan interface use vlan for bmx6
* bmx6: doesn't flood log with some spurious warnings anymore (syslog=0)
* bmx6: sms plugin now enabled by default
* bmx6: daemon is now supervised by procd, so it is restarted in case of crashes
* bmx6: doesn't "configSync" by default anymore (no more "uci pending changes" because of auto-gw-mode)
* new bmx6hosts tool: maintain an /etc/hosts that resolves fd66: <-> hostnames.mesh
* watchping: convert to procd and add reload triggers
* safe-reboot: fix, use /overlay/upper instead of /overlay
* safe-reboot: add "discard" action
* ath9k: debugged some hangs (interface is deaf) and workaround it, with new package "smonit"
* set wifi default "distance" parameter to 1000 metres and make it configurable through webui
* alfred: fix bat-hosts facter, check for errors and don't nuke /etc/bat-hosts in case of failure
* introduce new lime-basic-noui metapackage
* new packages separated: lime-docs and lime-docs-minimal
* various Makefile dependency problems fixed

Changelog 16.07
* Based on OpenWrt Chaos Calmer 15.05.1
* Removed "firewall" package (which is included by default in vanilla OpenWrt/LEDE), since it's not really being used in LibreMesh setup. It can always be installed on a case-by-case basis using opkg.
* Removed "odhcpd" since we're not using it at the moment (we use dnsmasq)
* Removed "odhcp6c" since we're not using it at the moment (we still haven't solved how to deal with native IPv6 coming over WAN, i.e. propagate a delegated prefix over the mesh in a reasonable way)
* New default packages: "lime-hwd-openwrt-wan" and "lime-proto-wan". This checks if there's a WAN port, and automatically configures as "wan" proto (lime-proto-wan). The "wan" proto let's you assign in /etc/config/lime, for example, 802.1ad VLANs over the WAN port.
* New default package: "lime-hwd-ground-routing". Allows you to configure 802.1q VLANs on embedded switches, so that you can separate specific ports and put
* New default package: "bmx6-auto-gw-mode", so that when a node detects (with watchping) it can ping 8.8.8.8 over WAN port, a bmx6 tunIn is created on-the-fly, and Internet is shared to the rest of the clouds.
* Workaround for an spurious log message caused by BATMAN-Adv ("br-lan: received packet on bat0 with own address as source address"): a "dummy0" interface is created and added to bat0, with a slightly different MAC address
** https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2014-March/011839.html
* New available packages: "lime-proto-bgp", allows to do BGP with bird daemon; and "lime-proto-olsr", "-olsr2" and "-olsr6", which add support for all versions of OLSR.
* Some new settings possible in /etc/config/lime-defaults
** wireless.htmode lets you preset the htmode for any wireless radio (or htmode_2ghz and htmode_5ghz for specific bands)
** wireless.distance is the equivalent, for setting distance (and distance_2ghz / _5ghz)

Libre-mesh

2018-02-10T17:30:51Z

Al: Al movió la página Libre-mesh a LibreMesh

#REDIRECCIÓN [[LibreMesh]]

Libre-mesh/Changelog

2018-02-10T17:30:51Z

Al: Al movió la página Libre-mesh/Changelog a LibreMesh/Changelog

#REDIRECCIÓN [[LibreMesh/Changelog]]

LibreMesh

2018-02-10T17:30:50Z

Al: Al movió la página Libre-mesh a LibreMesh

'''LibreMesh''' es una iniciativa llevada adelante por miembros de redes comunitarias de diferentes continentes que se organizan para unificar esfuerzos en el desarrollo de herramientas útiles para facilitar el despliegue de Redes Libres para cualquier comunidad del mundo.

La herramienta principal es el [http://libremesh.org/ firmware LibreMesh]: basado en [[OpenWrt]] y [[LEDE]] estandariza la creación de comunidades WiFi y provee de [[roaming]] a las comunidades ya existentes.

Otras herramientas son:

*[http://docs.altermundi.net/LibreNet6 Librenet6]: un mesh tunnel broker para proveer IPv6 globales a las redes libres
*[https://chef.altermundi.net/ Chef]: creador de firmwares a medida para comunidades
*[https://github.com/libremap Libremap] (en colaboración con Freifunk): representación de nodos según su ubicación geográfica con actualización de calidades de enlace a tiempo real.

Las herramientas se pueden utilizar por separado o todas juntas, actualmente estamos trabajando en la integración automatizada del uso de todas ellas.

Este proyecto nació como un esfuezo para fusionar algunos proyectos de firmware preexistentes:

* AlterMesh (de AlterMundi, Argentina)
* qMp (de guifi.net, Catalunya)
* eigenNet (de eigenLab, Ninux, Italia)

Y con el apoyo de algunas organizaciones existentes:

* the Free Network Foundation (de USA)
* the Guifi.net Foundation (de Catalunya)

Si quieres colaborar con el proyecto [https://lists.libremesh.org/mailman/listinfo/lime-dev utiliza la lista de correo de desarrolladores] o la [https://lists.libremesh.org/mailman/listinfo/lime-users de usuarios]

== Cómo escoger la versión de firmware a instalar ==
A partir del Chef puedes escoger una de estas versiones según tus necesidades:
{| class="wikitable" style="text-align: center;"
!rowspan="2"| LibreMesh v.
!rowspan="2"| Descargable en:
!rowspan="2"| Based on
!colspan="4"| Supported routing protocols
!rowspan="2"| Default interface mode for links
!rowspan="2"| Internet Detection
!rowspan="2"| Centralized DNS
!rowspan="2"| Distributed DNS
!rowspan="2"| Anygw
!rowspan="2"| Web interface
!rowspan="2"| Backward compatibility
!rowspan="2"| Networks using it
!
|-
! BATMAN-Adv
! BMX6
! BGP
! OLSR (v1, v2, v6)
|-
! 36140
|
|
| y
| n
| n
| n
| IBSS (ad-hoc)
| y
| y
| n
| n
|
|
|
|-
! 15.04 (44952)
|
|
| y
| y
| n
| n
| IBSS (ad-hoc)
| n
| n
| n
| y
|
|
|
|-
! 15.07rc1
|
|
| y
| y
| n
| n
| IBSS (ad-hoc)
| n
| n
| y
| y
|
|
|
|-
! 15.07final
|
|
| y
| y
| n
| n
| IBSS (ad-hoc)
| y
| y
| y
| y
|
|
|
|-
! 16.07 Community Chaos
|
| OpenWrt 15.05.1 Chaos Calmer
| y
| y
| available
| available
| IBSS (ad-hoc)
| y
| y
| y
| y
|
| break
|
|-
! ''17.06 Dayboot Rely''
| http://downloads.libremesh.org/dayboot_rely/17.06/targets/
| LEDE
| y
| y
| available
| available
| mesh point (802.11s)
| y
| y
| y
| y
|
| break
|
|}

''[[/Changelog|Mas sobre el Changelog]]''

El splash se puede instalar de la siguiente manera:
''en desarrollo''

El reconocimiento de nombres dentro de batctl se habilita de la siguiente manera:
''en desarrollo''

== Enlaces externos ==
* [http://libremesh.org Página oficial]

[[Categoría:MANET]]

LibreMesh

2016-08-08T02:40:57Z

Al: /* Cómo escoger la versión de firmware a instalar */

'''Libre-mesh''' es una iniciativa llevada adelante por miembros de redes comunitarias de diferentes continentes que se organizan para unificar esfuerzos en el desarrollo de herramientas útiles para facilitar el despliegue de Redes Libres para cualquier comunidad del mundo.

La herramienta principal es el [https://dev.libre-mesh.org/projects/libre-mesh firmware Libre-mesh]: basado en [[OpenWrt]] estandariza la creación de comunidades WiFi y provee de [[roaming]] a las comunidades ya existentes.

Otras herramientas son:

*[https://dev.libre-mesh.org/projects/librenet6 Librenet6]: un mesh tunnel broker para proveer IPv6 globales a las redes libres
*[https://colectivo.altermundi.net/projects/chef Chef]: creador de firmwares a medida para comunidades
*[https://github.com/libremap Libremap] (en colaboración con Freifunk): representación de nodos según su ubicación geográfica con actualización de calidades de enlace a tiempo real.

Las herramientas se pueden utilizar por separado o todas juntas, actualmente estamos trabajando en la integración automatizada del uso de todas ellas.

Este proyecto nació como un esfuezo para fusionar algunos proyectos de firmware preexistentes:

* AlterMesh (de AlterMundi, Argentina)
* qMp (de guifi.net, Catalunya)
* eigenNet (de eigenLab, Ninux, Italia)

Y con el apoyo de algunas organizaciones existentes:

* the Free Network Foundation (de USA)
* the Guifi.net Foundation (de Catalunya)

Si quieres colaborar con el proyecto [https://lists.libre-mesh.org/mailman/listinfo/dev utiliza la lista de correo]

== Cómo escoger la versión de firmware a instalar ==
A partir del Chef puedes escoger una de estas versiones según tus necesidades:
{| class="wikitable" style="text-align: center;"
!rowspan="2"| Libre-mesh v.
!rowspan="2"| Descargable en:
!rowspan="2"| Based on
!colspan="4"| Supported routing protocols
!rowspan="2"| Default interface mode for links
!rowspan="2"| Internet Detection
!rowspan="2"| Centralized DNS
!rowspan="2"| Distributed DNS
!rowspan="2"| Anygw
!rowspan="2"| Web interface
!rowspan="2"| Backward compatibility
!rowspan="2"| Networks using it
!
|-
! BATMAN-Adv
! BMX6
! BGP
! OLSR (v1, v2, v6)
|-
! 36140
|
|
| y
| n
| n
| n
| IBSS (ad-hoc)
| y
| y
| n
| n
|
|
|
|-
! 15.04 (44952)
|
|
| y
| y
| n
| n
| IBSS (ad-hoc)
| n
| n
| n
| y
|
|
|
|-
! 15.07rc1
|
|
| y
| y
| n
| n
| IBSS (ad-hoc)
| n
| n
| y
| y
|
|
|
|-
! 15.07final
|
|
| y
| y
| n
| n
| IBSS (ad-hoc)
| y
| y
| y
| y
|
|
|
|-
! 16.07 Community Chaos
|
| OpenWrt 15.05.1 Chaos Calmer
| y
| y
| available
| available
| IBSS (ad-hoc)
| y
| y
| y
| y
|
| break
|
|-
! ''1X.XX D* D*''
|
| LEDE
| y
| y
| available
| available
| mesh point (802.11s)
| y
| y
| y
| y
|
| break
|
|}

''[[/Changelog|Mas sobre el Changelog]]''

El splash se puede instalar de la siguiente manera:
''en desarrollo''

El reconocimiento de nombres dentro de batctl se habilita de la siguiente manera:
''en desarrollo''

== Enlaces externos ==
* [https://libre-mesh.org Página oficial]

[[Categoría:MANET]]

LibreMesh

2016-08-08T02:38:15Z

Al: /* Cómo escoger la versión de firmware a instalar */

'''Libre-mesh''' es una iniciativa llevada adelante por miembros de redes comunitarias de diferentes continentes que se organizan para unificar esfuerzos en el desarrollo de herramientas útiles para facilitar el despliegue de Redes Libres para cualquier comunidad del mundo.

La herramienta principal es el [https://dev.libre-mesh.org/projects/libre-mesh firmware Libre-mesh]: basado en [[OpenWrt]] estandariza la creación de comunidades WiFi y provee de [[roaming]] a las comunidades ya existentes.

Otras herramientas son:

*[https://dev.libre-mesh.org/projects/librenet6 Librenet6]: un mesh tunnel broker para proveer IPv6 globales a las redes libres
*[https://colectivo.altermundi.net/projects/chef Chef]: creador de firmwares a medida para comunidades
*[https://github.com/libremap Libremap] (en colaboración con Freifunk): representación de nodos según su ubicación geográfica con actualización de calidades de enlace a tiempo real.

Las herramientas se pueden utilizar por separado o todas juntas, actualmente estamos trabajando en la integración automatizada del uso de todas ellas.

Este proyecto nació como un esfuezo para fusionar algunos proyectos de firmware preexistentes:

* AlterMesh (de AlterMundi, Argentina)
* qMp (de guifi.net, Catalunya)
* eigenNet (de eigenLab, Ninux, Italia)

Y con el apoyo de algunas organizaciones existentes:

* the Free Network Foundation (de USA)
* the Guifi.net Foundation (de Catalunya)

Si quieres colaborar con el proyecto [https://lists.libre-mesh.org/mailman/listinfo/dev utiliza la lista de correo]

== Cómo escoger la versión de firmware a instalar ==
A partir del Chef puedes escoger una de estas versiones según tus necesidades:
{| class="wikitable" style="text-align: center;"
!rowspan="2"| Libre-mesh v.
!rowspan="2"| Descargable en:
!rowspan="2"| Based on OpenWrt v.
!colspan="4"| Supported routing protocols
!rowspan="2"| Default interface mode for links
!rowspan="2"| Internet Detection
!rowspan="2"| Centralized DNS
!rowspan="2"| Distributed DNS
!rowspan="2"| Anygw
!rowspan="2"| Web interface
!rowspan="2"| Backward compatibility
!rowspan="2"| Networks using it
!
|-
! BATMAN-Adv
! BMX6
! BGP
! OLSR (v1, v2, v6)
|-
! 36140
|
|
| y
| n
| n
| n
| IBSS (ad-hoc)
| y
| y
| n
| n
|
|
|
|-
! 15.04 (44952)
|
|
| y
| y
| n
| n
| IBSS (ad-hoc)
| n
| n
| n
| y
|
|
|
|-
! 15.07rc1
|
|
| y
| y
| n
| n
| IBSS (ad-hoc)
| n
| n
| y
| y
|
|
|
|-
! 15.07final
|
|
| y
| y
| n
| n
| IBSS (ad-hoc)
| y
| y
| y
| y
|
|
|
|-
! 16.07 Community Chaos
|
| 15.05.1 Chaos Calmer
| y
| y
| available
| available
| IBSS (ad-hoc)
| y
| y
| y
| y
|
| break
|
|-
! ''1X.XX D* D*''
|
| LEDE
| y
| y
| available
| available
| mesh point (802.11s)
| y
| y
| y
| y
|
| break
|
|}

''[[/Changelog|Mas sobre el Changelog]]''

El splash se puede instalar de la siguiente manera:
''en desarrollo''

El reconocimiento de nombres dentro de batctl se habilita de la siguiente manera:
''en desarrollo''

== Enlaces externos ==
* [https://libre-mesh.org Página oficial]

[[Categoría:MANET]]

LibreMesh

2016-08-08T02:05:13Z

Al: /* Cómo escoger la versión de firmware a instalar */

'''Libre-mesh''' es una iniciativa llevada adelante por miembros de redes comunitarias de diferentes continentes que se organizan para unificar esfuerzos en el desarrollo de herramientas útiles para facilitar el despliegue de Redes Libres para cualquier comunidad del mundo.

La herramienta principal es el [https://dev.libre-mesh.org/projects/libre-mesh firmware Libre-mesh]: basado en [[OpenWrt]] estandariza la creación de comunidades WiFi y provee de [[roaming]] a las comunidades ya existentes.

Otras herramientas son:

*[https://dev.libre-mesh.org/projects/librenet6 Librenet6]: un mesh tunnel broker para proveer IPv6 globales a las redes libres
*[https://colectivo.altermundi.net/projects/chef Chef]: creador de firmwares a medida para comunidades
*[https://github.com/libremap Libremap] (en colaboración con Freifunk): representación de nodos según su ubicación geográfica con actualización de calidades de enlace a tiempo real.

Las herramientas se pueden utilizar por separado o todas juntas, actualmente estamos trabajando en la integración automatizada del uso de todas ellas.

Este proyecto nació como un esfuezo para fusionar algunos proyectos de firmware preexistentes:

* AlterMesh (de AlterMundi, Argentina)
* qMp (de guifi.net, Catalunya)
* eigenNet (de eigenLab, Ninux, Italia)

Y con el apoyo de algunas organizaciones existentes:

* the Free Network Foundation (de USA)
* the Guifi.net Foundation (de Catalunya)

Si quieres colaborar con el proyecto [https://lists.libre-mesh.org/mailman/listinfo/dev utiliza la lista de correo]

== Cómo escoger la versión de firmware a instalar ==
A partir del Chef puedes escoger una de estas versiones según tus necesidades:
{| class="wikitable" style="text-align: center;"
!rowspan="2"| Libre-mesh v.
!rowspan="2"| Descargable en:
!rowspan="2"| Based on OpenWrt v.
!colspan="4"| Supported protocols
!rowspan="2"| Internet Detection
!rowspan="2"| Centralized DNS
!rowspan="2"| Distributed DNS
!rowspan="2"| Anygw
!rowspan="2"| Web interface
!rowspan="2"| Backward compatibility
!rowspan="2"| Networks using it
!
|-
! BATMAN-Adv
! BMX6
! BGP
! OLSR (v1, v2, v6)
|-
! 36140
|
|
| y
| n
| n
| n
| y
| y
| n
| n
|
|
|
|-
! 15.04 (44952)
|
|
| y
| y
| n
| n
| n
| n
| n
| y
|
|
|
|-
! 15.07rc1
|
|
| y
| y
| n
| n
| n
| n
| y
| y
|
|
|
|-
! 15.07final
|
|
| y
| y
| n
| n
| y
| y
| y
| y
|
|
|
|-
! 16.07
|
| 15.05.1 Chaos Calmer
| y
| y
| available
| available
| y
| y
| y
| y
|
| break
|
|}

''[[/Changelog|Mas sobre el Changelog]]''

El splash se puede instalar de la siguiente manera:
''en desarrollo''

El reconocimiento de nombres dentro de batctl se habilita de la siguiente manera:
''en desarrollo''

== Enlaces externos ==
* [https://libre-mesh.org Página oficial]

[[Categoría:MANET]]

Manual de Libre-mesh para guiferos

2016-08-08T01:59:34Z

Al: /* ¿Por qué tengo tantas interfaces de red? */

Este es un manual para entender cómo funciona [[Libre-mesh]] de forma práctica. Es de nivel técnico medio, está orientado a personas con conocimientos prácticos de redes inalámbricas, especialmente para personas que no están familiarizadas con el funcionamiento de los protocolos de enrutamiento dinámico [[BMX6]] y [[BATMAN-adv]], pero sí con [[BGP]] tal como se usa en Guifi.net.

=== Desarrollo de Libre-mesh ===

==== ¿Cómo tenéis organizado el desarrollo? ====

==== Entonces: ¿qué me recomendáis para montar una red con Libre-mesh en mi zona ahora? ====

==== ¿Cuál es la relación entre qMp y Libre-mesh? ====

=== Primer arranque ===

==== ¿Qué hace el router en el primer arranque después de flashearlo? ====
El script [https://github.com/libre-mesh/lime-packages/blob/master/packages/lime-system/files/etc/uci-defaults/91_lime-config /etc/uci-defaults/91_lime-config] es llamado por OpenWrt en el primer arranque. Entonces [https://github.com/libre-mesh/lime-packages/blob/master/packages/lime-system/files/usr/bin/lime-config /usr/bin/lime-config] genera los archivos de configuración para:

system:
* Le pone un nombre de máquina (<code>hostname</code>) en base a los tres últimos hexadecimales de la MAC
* Arranca el servidor web

wireless:
* Elimina la configuración de wireless que trae por defecto OpenWrt
* Detecta los dispositivos wireless ([[radio]]s) que tiene el router y si estos son capaces de funcionar a 5GHz y en modos ad-hoc y ap
* Crea el essid a partir de la los tres últimos hexadecimales de la MAC más .lime
* Configura los canales por cada una de las radios

network:
* Elimina la configuración de red que trae por defecto OpenWrt
* Detecta las interfaces de red que tiene el router
* Configura la primera IPv4
* Configura la primera IPv6
* Activa rp_filter (ignora paquetes que no son para su red) [http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html más información]
* Configura los protocolos BATMAN-adv y BMX6

firewall:
* crea un cortafuegas donde todos los paquetes son aceptados <ref>Hasta la versión 16.07 se eliminaba el cortafuegos por defecto de OpenWrt y se creaba otro, a partir de la 16.07 incluida el cortafuegos ya no se pone dentro de los paquetes.</ref>
* crea una regla que comprime el MSS al ancho del MTU que está definido en las interaces

Este script se borra él mismo después del primer arranque (aunque todavía puedes verlo en la ROM <code>/rom/etc/uci-defaults/91_lime-config</code> )

<references />

=== Comandos ===

==== ¿Cómo puedo comprobar que los nodos están enlazados y los protocolos están funcionando bien? ====

=== Contenido de los nodos ===

==== ¿Por qué tengo tantas interfaces de red? ====
Desde la linea de comandos del router si hacemos <code>ip address show</code> (que es la forma sustitutiva de hacer un <code>ifconfig</code>) vemos un listado de 23 interfaces de red en la versión 15.07 y 26 en la versión 16.07.

Si nos da palo contarlas nos puede salir el resultado con este comando:
echo $(($(ip link show|wc -l)/2))

Esas interfaces tienen funciones varias. Pasamos a explicar a continuación todas las existentes en la versión 26.07.

===== Interfaces =====
Nota: el .11 en el nombre de la interfaz virutal corresponde a la vlan

Manual de Libre-mesh para guiferos

2016-08-08T01:30:05Z

Al: /* ¿Qué hace el router en el primer arranque después de flashearlo? */

Este es un manual para entender cómo funciona [[Libre-mesh]] de forma práctica. Es de nivel técnico medio, está orientado a personas con conocimientos prácticos de redes inalámbricas, especialmente para personas que no están familiarizadas con el funcionamiento de los protocolos de enrutamiento dinámico [[BMX6]] y [[BATMAN-adv]], pero sí con [[BGP]] tal como se usa en Guifi.net.

=== Desarrollo de Libre-mesh ===

==== ¿Cómo tenéis organizado el desarrollo? ====

==== Entonces: ¿qué me recomendáis para montar una red con Libre-mesh en mi zona ahora? ====

==== ¿Cuál es la relación entre qMp y Libre-mesh? ====

=== Primer arranque ===

==== ¿Qué hace el router en el primer arranque después de flashearlo? ====
El script [https://github.com/libre-mesh/lime-packages/blob/master/packages/lime-system/files/etc/uci-defaults/91_lime-config /etc/uci-defaults/91_lime-config] es llamado por OpenWrt en el primer arranque. Entonces [https://github.com/libre-mesh/lime-packages/blob/master/packages/lime-system/files/usr/bin/lime-config /usr/bin/lime-config] genera los archivos de configuración para:

system:
* Le pone un nombre de máquina (<code>hostname</code>) en base a los tres últimos hexadecimales de la MAC
* Arranca el servidor web

wireless:
* Elimina la configuración de wireless que trae por defecto OpenWrt
* Detecta los dispositivos wireless ([[radio]]s) que tiene el router y si estos son capaces de funcionar a 5GHz y en modos ad-hoc y ap
* Crea el essid a partir de la los tres últimos hexadecimales de la MAC más .lime
* Configura los canales por cada una de las radios

network:
* Elimina la configuración de red que trae por defecto OpenWrt
* Detecta las interfaces de red que tiene el router
* Configura la primera IPv4
* Configura la primera IPv6
* Activa rp_filter (ignora paquetes que no son para su red) [http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html más información]
* Configura los protocolos BATMAN-adv y BMX6

firewall:
* crea un cortafuegas donde todos los paquetes son aceptados <ref>Hasta la versión 16.07 se eliminaba el cortafuegos por defecto de OpenWrt y se creaba otro, a partir de la 16.07 incluida el cortafuegos ya no se pone dentro de los paquetes.</ref>
* crea una regla que comprime el MSS al ancho del MTU que está definido en las interaces

Este script se borra él mismo después del primer arranque (aunque todavía puedes verlo en la ROM <code>/rom/etc/uci-defaults/91_lime-config</code> )

<references />

=== Comandos ===

==== ¿Cómo puedo comprobar que los nodos están enlazados y los protocolos están funcionando bien? ====

=== Contenido de los nodos ===

==== ¿Por qué tengo tantas interfaces de red? ====
Desde la linea de comandos del router si hacemos <code>ip address show</code> (que es la forma sustitutiva de hacer un <code>ifconfig</code>) vemos un listado de 23 interfaces de red.

Si nos da palo contarlas nos puede salir el resultado con este comando:
echo $(($(ip link show|wc -l)/2)

Esas interfaces tienen funciones varias.

===== Interfaces =====
Nota: el .11 en el nombre de la interfaz virutal corresponde a la vlan

LibreMesh

2016-08-08T00:52:33Z

Al: /* Cómo escoger la versión de firmware a instalar */

'''Libre-mesh''' es una iniciativa llevada adelante por miembros de redes comunitarias de diferentes continentes que se organizan para unificar esfuerzos en el desarrollo de herramientas útiles para facilitar el despliegue de Redes Libres para cualquier comunidad del mundo.

La herramienta principal es el [https://dev.libre-mesh.org/projects/libre-mesh firmware Libre-mesh]: basado en [[OpenWrt]] estandariza la creación de comunidades WiFi y provee de [[roaming]] a las comunidades ya existentes.

Otras herramientas son:

*[https://dev.libre-mesh.org/projects/librenet6 Librenet6]: un mesh tunnel broker para proveer IPv6 globales a las redes libres
*[https://colectivo.altermundi.net/projects/chef Chef]: creador de firmwares a medida para comunidades
*[https://github.com/libremap Libremap] (en colaboración con Freifunk): representación de nodos según su ubicación geográfica con actualización de calidades de enlace a tiempo real.

Las herramientas se pueden utilizar por separado o todas juntas, actualmente estamos trabajando en la integración automatizada del uso de todas ellas.

Este proyecto nació como un esfuezo para fusionar algunos proyectos de firmware preexistentes:

* AlterMesh (de AlterMundi, Argentina)
* qMp (de guifi.net, Catalunya)
* eigenNet (de eigenLab, Ninux, Italia)

Y con el apoyo de algunas organizaciones existentes:

* the Free Network Foundation (de USA)
* the Guifi.net Foundation (de Catalunya)

Si quieres colaborar con el proyecto [https://lists.libre-mesh.org/mailman/listinfo/dev utiliza la lista de correo]

== Cómo escoger la versión de firmware a instalar ==
A partir del Chef puedes escoger una de estas versiones según tus necesidades:
{| class="wikitable" style="text-align: center;"
!rowspan="2"| Libre-mesh v.
!rowspan="2"| Descargable en:
!rowspan="2"| Based on OpenWrt v.
!colspan="4"|Supported protocols
!rowspan="2"| Internet Detection
!rowspan="2"| Centralized DNS
!rowspan="2"| Distributed DNS
!rowspan="2"| Anygw
|-
! BATMAN-Adv
! BMX6
! BGP
! OLSR (v1, v2, v6)
|-
! 36140
|
|
| y
| n
| n
| n
| y
| y
| n
| n
|-
! 15.04 (44952)
|
|
| y
| y
| n
| n
| n
| n
| n
| y
|-
! 15.07rc1
|
|
| y
| y
| n
| n
| n
| n
| y
| y
|-
! 15.07final
|
|
| y
| y
| n
| n
| y
| y
| y
| y
|-
! 16.07
|
| 15.05.1 Chaos Calmer
| y
| y
| available
| available
| y
| y
| y
| y
|}

''[[/Changelog|Mas sobre el Changelog]]''

El splash se puede instalar de la siguiente manera:
''en desarrollo''

El reconocimiento de nombres dentro de batctl se habilita de la siguiente manera:
''en desarrollo''

== Enlaces externos ==
* [https://libre-mesh.org Página oficial]

[[Categoría:MANET]]

LibreMesh

2016-08-08T00:50:53Z

Al: /* Cómo escoger la versión de firmware a instalar */

'''Libre-mesh''' es una iniciativa llevada adelante por miembros de redes comunitarias de diferentes continentes que se organizan para unificar esfuerzos en el desarrollo de herramientas útiles para facilitar el despliegue de Redes Libres para cualquier comunidad del mundo.

La herramienta principal es el [https://dev.libre-mesh.org/projects/libre-mesh firmware Libre-mesh]: basado en [[OpenWrt]] estandariza la creación de comunidades WiFi y provee de [[roaming]] a las comunidades ya existentes.

Otras herramientas son:

*[https://dev.libre-mesh.org/projects/librenet6 Librenet6]: un mesh tunnel broker para proveer IPv6 globales a las redes libres
*[https://colectivo.altermundi.net/projects/chef Chef]: creador de firmwares a medida para comunidades
*[https://github.com/libremap Libremap] (en colaboración con Freifunk): representación de nodos según su ubicación geográfica con actualización de calidades de enlace a tiempo real.

Las herramientas se pueden utilizar por separado o todas juntas, actualmente estamos trabajando en la integración automatizada del uso de todas ellas.

Este proyecto nació como un esfuezo para fusionar algunos proyectos de firmware preexistentes:

* AlterMesh (de AlterMundi, Argentina)
* qMp (de guifi.net, Catalunya)
* eigenNet (de eigenLab, Ninux, Italia)

Y con el apoyo de algunas organizaciones existentes:

* the Free Network Foundation (de USA)
* the Guifi.net Foundation (de Catalunya)

Si quieres colaborar con el proyecto [https://lists.libre-mesh.org/mailman/listinfo/dev utiliza la lista de correo]

== Cómo escoger la versión de firmware a instalar ==
A partir del Chef puedes escoger una de estas versiones según tus necesidades:
{| class="wikitable" style="text-align: center;"
!rowspan="2"| Libre-mesh v.
!rowspan="2"| Descargable en:
!rowspan="2"| Based on OpenWrt v.
!colspan="4"|Supported protocols
!rowspan="2"| Internet Detection
!rowspan="2"| Centralized DNS
!rowspan="2"| Distributed DNS
!rowspan="2"| Anygw
|-
! BATMAN-Adv
! BMX6
! BGP
! OLSR (v1, v2, v6)
|-
! 36140
|
|
| y
| n
| n
| n
| y
| y
| n
| n
|-
! 15.04 (44952)
|
|
| y
| y
| n
| n
| n
| n
| n
| y
|-
! 15.07rc1
|
|
| y
| y
| n
| n
| n
| n
| y
| y
|-
! 15.07final
|
|
| y
| y
| n
| n
| y
| y
| y
| y
|-
! 16.07
|
| 15.05.1 Chaos Calmer
| y
| y
| y
| y
| y
| y
| y
| y
|}

''[[/Changelog|Mas sobre el Changelog]]''

El splash se puede instalar de la siguiente manera:
''en desarrollo''

El reconocimiento de nombres dentro de batctl se habilita de la siguiente manera:
''en desarrollo''

== Enlaces externos ==
* [https://libre-mesh.org Página oficial]

[[Categoría:MANET]]

LibreMesh/Changelog

2016-08-08T00:28:47Z

Al: Página creada con «Changelog 16.07 * Based on OpenWrt Chaos Calmer 15.05.1 * Removed "firewall" package (which is included by default in vanilla OpenWrt/LEDE), since it's not really being use...»

Changelog 16.07
* Based on OpenWrt Chaos Calmer 15.05.1
* Removed "firewall" package (which is included by default in vanilla OpenWrt/LEDE), since it's not really being used in LibreMesh setup. It can always be installed on a case-by-case basis using opkg.
* Removed "odhcpd" since we're not using it at the moment (we use dnsmasq)
* Removed "odhcp6c" since we're not using it at the moment (we still haven't solved how to deal with native IPv6 coming over WAN, i.e. propagate a delegated prefix over the mesh in a reasonable way)
* New default packages: "lime-hwd-openwrt-wan" and "lime-proto-wan". This checks if there's a WAN port, and automatically configures as "wan" proto (lime-proto-wan). The "wan" proto let's you assign in /etc/config/lime, for example, 802.1ad VLANs over the WAN port.
* New default package: "lime-hwd-ground-routing". Allows you to configure 802.1q VLANs on embedded switches, so that you can separate specific ports and put
* New default package: "bmx6-auto-gw-mode", so that when a node detects (with watchping) it can ping 8.8.8.8 over WAN port, a bmx6 tunIn is created on-the-fly, and Internet is shared to the rest of the clouds.
* Workaround for an spurious log message caused by BATMAN-Adv ("br-lan: received packet on bat0 with own address as source address"): a "dummy0" interface is created and added to bat0, with a slightly different MAC address
** https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2014-March/011839.html
* New available packages: "lime-proto-bgp", allows to do BGP with bird daemon; and "lime-proto-olsr", "-olsr2" and "-olsr6", which add support for all versions of OLSR.
* Some new settings possible in /etc/config/lime-defaults
** wireless.htmode lets you preset the htmode for any wireless radio (or htmode_2ghz and htmode_5ghz for specific bands)
** wireless.distance is the equivalent, for setting distance (and distance_2ghz / _5ghz)

LibreMesh

2016-08-08T00:13:26Z

Al:

'''Libre-mesh''' es una iniciativa llevada adelante por miembros de redes comunitarias de diferentes continentes que se organizan para unificar esfuerzos en el desarrollo de herramientas útiles para facilitar el despliegue de Redes Libres para cualquier comunidad del mundo.

La herramienta principal es el [https://dev.libre-mesh.org/projects/libre-mesh firmware Libre-mesh]: basado en [[OpenWrt]] estandariza la creación de comunidades WiFi y provee de [[roaming]] a las comunidades ya existentes.

Otras herramientas son:

*[https://dev.libre-mesh.org/projects/librenet6 Librenet6]: un mesh tunnel broker para proveer IPv6 globales a las redes libres
*[https://colectivo.altermundi.net/projects/chef Chef]: creador de firmwares a medida para comunidades
*[https://github.com/libremap Libremap] (en colaboración con Freifunk): representación de nodos según su ubicación geográfica con actualización de calidades de enlace a tiempo real.

Las herramientas se pueden utilizar por separado o todas juntas, actualmente estamos trabajando en la integración automatizada del uso de todas ellas.

Este proyecto nació como un esfuezo para fusionar algunos proyectos de firmware preexistentes:

* AlterMesh (de AlterMundi, Argentina)
* qMp (de guifi.net, Catalunya)
* eigenNet (de eigenLab, Ninux, Italia)

Y con el apoyo de algunas organizaciones existentes:

* the Free Network Foundation (de USA)
* the Guifi.net Foundation (de Catalunya)

Si quieres colaborar con el proyecto [https://lists.libre-mesh.org/mailman/listinfo/dev utiliza la lista de correo]

== Cómo escoger la versión de firmware a instalar ==
A partir del Chef puedes escoger una de estas versiones según tus necesidades:
{| class="wikitable" style="text-align: center;"
! Libre-mesh v.
! Descargable en:
! Based on OpenWrt v.
! BATMAN-Adv
! BMX6
! Internet Detection
! Centralized DNS
! Distributed DNS
! Anygw
|-
| 36140
|
|
| y
| n
| y
| y
| n
| n
|-
| 15.04 (44952)
|
|
| y
| y
| n
| n
| n
| y
|-
| 15.07rc1
|
|
| y
| y
| n
| n
| y
| y
|-
| 15.07final
|
|
| y
| y
| y
| y
| y
| y
|-
| 16.07
|
| Chaos Calmer 15.05.1
| y
| y
| y
| y
| y
| y
|}

El splash se puede instalar de la siguiente manera:

El reconocimiento de nombres dentro de batctl se habilita de la siguiente manera:

== Enlaces externos ==
* [https://libre-mesh.org Página oficial]

[[Categoría:MANET]]

Manual de Libre-mesh para guiferos

2016-08-08T00:05:44Z

Al: Página creada con «Este es un manual para entender cómo funciona Libre-mesh de forma práctica. Es de nivel técnico medio, está orientado a personas con conocimientos prácticos de red...»

Este es un manual para entender cómo funciona [[Libre-mesh]] de forma práctica. Es de nivel técnico medio, está orientado a personas con conocimientos prácticos de redes inalámbricas, especialmente para personas que no están familiarizadas con el funcionamiento de los protocolos de enrutamiento dinámico [[BMX6]] y [[BATMAN-adv]], pero sí con [[BGP]] tal como se usa en Guifi.net.

=== Desarrollo de Libre-mesh ===

==== ¿Cómo tenéis organizado el desarrollo? ====

==== Entonces: ¿qué me recomendáis para montar una red con Libre-mesh en mi zona ahora? ====

==== ¿Cuál es la relación entre qMp y Libre-mesh? ====

=== Primer arranque ===

==== ¿Qué hace el router en el primer arranque después de flashearlo? ====
El script [https://github.com/libre-mesh/lime-packages/blob/master/packages/lime-system/files/etc/uci-defaults/91_lime-config /etc/uci-defaults/91_lime-config] es llamado por OpenWrt en el primer arranque. Entonces [https://github.com/libre-mesh/lime-packages/blob/master/packages/lime-system/files/usr/bin/lime-config /usr/bin/lime-config] genera los archivos de configuración para:

system:
* Le pone un nombre de máquina (<code>hostname</code>) en base a los tres últimos hexadecimales de la MAC
* Arranca el servidor web

wireless:
* Elimina la configuración de wireless que trae por defecto OpenWrt
* Detecta los dispositivos wireless ([[radio]]s) que tiene el router y si estos son capaces de funcionar a 5GHz y en modos ad-hoc y ap
* Crea el essid a partir de la los tres últimos hexadecimales de la MAC más .lime
* Configura los canales por cada una de las radios

network:
* Elimina la configuración de red que trae por defecto OpenWrt
* Detecta las interfaces de red que tiene el router
* Configura la primera IPv4
* Configura la primera IPv6
* Activa rp_filter (ignora paquetes que no son para su red) [http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html más información]
* Configura los protocolos BATMAN-adv y BMX6

firewall:
* crea un cortafuegas donde todos los paquetes son aceptados <ref>Hasta la versión 16.07 se eliminaba el cortafuegos por defecto de OpenWrt y se creaba otro, a partir de la 16.07 incluida el cortafuegos ya no se pone dentro de los paquetes.</ref>
* crea una regla que comprime el MSS al ancho del MTU que está definido en las interaces

Este script se borra él mismo después del primer arranque.

<references />

=== Comandos ===

==== ¿Cómo puedo comprobar que los nodos están enlazados y los protocolos están funcionando bien? ====

=== Contenido de los nodos ===

==== ¿Por qué tengo tantas interfaces de red? ====
Desde la linea de comandos del router si hacemos <code>ip address show</code> (que es la forma sustitutiva de hacer un <code>ifconfig</code>) vemos un listado de 23 interfaces de red.

Si nos da palo contarlas nos puede salir el resultado con este comando:
echo $(($(ip link show|wc -l)/2)

Esas interfaces tienen funciones varias.

===== Interfaces =====
Nota: el .11 en el nombre de la interfaz virutal corresponde a la vlan

LibreMesh

2016-08-07T22:02:09Z

Al:

'''Libre-mesh''' es una iniciativa llevada adelante por miembros de redes comunitarias de diferentes continentes que se organizan para unificar esfuerzos en el desarrollo de herramientas útiles para facilitar el despliegue de Redes Libres para cualquier comunidad del mundo.

La herramienta principal es el [https://dev.libre-mesh.org/projects/libre-mesh firmware Libre-mesh]: basado en [[OpenWrt]] estandariza la creación de comunidades WiFi y provee de [[roaming]] a las comunidades ya existentes.

Otras herramientas son:

*[https://dev.libre-mesh.org/projects/librenet6 Librenet6]: un mesh tunnel broker para proveer IPv6 globales a las redes libres
*[https://colectivo.altermundi.net/projects/chef Chef]: creador de firmwares a medida para comunidades
*[https://github.com/libremap Libremap] (en colaboración con Freifunk): representación de nodos según su ubicación geográfica con actualización de calidades de enlace a tiempo real.

Las herramientas se pueden utilizar por separado o todas juntas, actualmente estamos trabajando en la integración automatizada del uso de todas ellas.

Este proyecto nació como un esfuezo para fusionar algunos proyectos de firmware preexistentes:

* AlterMesh (de AlterMundi, Argentina)
* qMp (de guifi.net, Catalunya)
* eigenNet (de eigenLab, Ninux, Italia)

Y con el apoyo de algunas organizaciones existentes:

* the Free Network Foundation (de USA)
* the Guifi.net Foundation (de Catalunya)

Si quieres colaborar con el proyecto [https://lists.libre-mesh.org/mailman/listinfo/dev utiliza la lista de correo]

== Cómo escoger la versión de firmware a instalar ==
A partir del Chef puedes escoger una de estas versiones según tus necesidades:
{|
! Libre-mesh v.
! Descargable en:
! BATMAN-Adv
! BMX6
! Internet Detection
! Centralized DNS
! Distributed DNS
! Anygw
|-
| 36140
|
| y
| n
| y
| y
| n
| n
|-
| 15.04 (44952)
|
| y
| y
| n
| n
| n
| y
|-
| 15.07rc1
|
| y
| y
| n
| n
| y
| y
|-
| 15.07final
|
| y
| y
| y
| y
| y
| y
|-
| 16.07
|
| y
| y
| y
| y
| y
| y
|}

El splash se puede instalar de la siguiente manera:

El reconocimiento de nombres dentro de batctl se habilita de la siguiente manera:

== Enlaces externos ==
* [https://libre-mesh.org Página oficial]

[[Categoría:MANET]]

Telefonía Guifi.net

2016-07-10T19:37:52Z

Al: Al movió la página Telefonia Guifi.net a Telefonía Guifi.net: Error ortográfico

Página de gestión del proyecto '''Telefonía Guifi.net''', siguiendo el esquema de [[Telefonía IP con Asterisks federados]].

El fin es coordinar las centralitas, para interconectarlas y poder alcanzar la comunicación dentro de la red.

Servidores Asterisk en funcionamiento:

{| class="wikitable" style="background:Gainsboro; color:black"
|-
!colspan="6" style="background:SlateGray"|01 - Álava
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|02 - Albacete
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|03 - Alicante
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|04 - Almería
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|05 - Ávila
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|06 - Badajoz
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
|xx
|Servicio de telefonía IP
|
|Operativo
|
|[[Extensiones#7006|7006]]
|-
!colspan="6" style="background:SlateGray"|07 - Illes Balears
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|08 - Barcelona
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
|xx
|Centraleta Asterisk en Igualada Centre
|10.145.3.126
|En construccion
|
|[[Extensiones#7008|7008]]
|-
|xx
|Servidor Veu IP Barcelona
|10.139.7.4
|Operativa, sin federar
|
|[[Extensiones#7008|7008]]
|-
|xx
|Centraleta telefònica del Serrat
|10.138.0.5
|Operativa, sin federar
|
|[[Extensiones#7008|7008]]
|-
|xx
|VoIP Cerdanyola
|10.20.0.2
|Configurándose, y en pruebas. Sin federar
|
|[[Extensiones#7008|7008]]
|-
|xx
|Centralita VoIP Terrasa
|10.139.61.69
|Proyectado
|
|[[Extensiones#7008|7008]]
|-
|xx
|HW-Kemet Asterisk
|10.35.126.99
|Configurándose, y en pruebas. Sin federar
|
|[[Extensiones#7008|7008]]
|-
!colspan="6" style="background:SlateGray"|09 - Burgos
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|10 - Cáceres
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|11 - Cádiz
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|12 - Castellón
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
|xx
|Guifinet Maestrat PBX
|10.90.94.229
|Operativa sin federar
|
|-
!colspan="6" style="background:SlateGray"|13 - Ciudad Real
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|14 - Córdoba
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|15 - Coruña
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|16 - Cuenca
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|17 - Girona
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
|xx
|Servidor Veu IP Crepuscle
|10.139.162.17
|Operativa, sin federar
|
|[[Extensiones#7017|7017]]
|-
!colspan="6" style="background:SlateGray"|18 - Granada
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|19 - Guadalajara
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|20 - Gipuzkoa
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|21 - Huelva
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|22 - Huesca
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|23 - Jaén
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|24 - León
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|25 - Lleida
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|26 - La Rioja
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|27 - Lugo
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|28 - Madrid
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|29 - Málaga
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|30 - Murcia
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|31 - Navarra
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|32 - Ourense
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|33 - Asturias
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|34 - Palencia
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|35 - Las Palmas
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|36 - Pontevedra
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|37 - Salamanca
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|38 - S.C. Tenerife
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|39 - Cantabria
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|40 - Segovia
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|41 - Sevilla
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|42 - Soria
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|43 - Tarragona
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
|xx
|SigertatxuVeu
|10.140.218.166
|Operativa, sin federar
|
|[[Extensiones#7043|7043]]
|-
!colspan="6" style="background:SlateGray"|44 - Teruel
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|45 - Toledo
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|46 - Valencia
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
|01
|Asterisk Valencia01
|10.229.4.69
|Operativa y federada
|
|[[Extensiones#704601|704601]]
|-
!colspan="6" style="background:SlateGray"|47 - Valladolid
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|48 - Bizkaia
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|49 - Zamora
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|50 - Zaragoza
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|51 - Ceuta
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
!colspan="6" style="background:SlateGray"|52 - Melilla
|-
!style="background:Silver"|Nº
!style="background:Silver"|Nombre
!style="background:Silver"|Ip
!style="background:Silver"|Estado
!style="background:Silver"|Comentarios
!style="background:Silver"|Ext.
|-
|}

Sip Router (Kamailio)

{| class="wikitable" style="background:Gainsboro; color:black"
|-
!style="background:SlateGray"|Servidor
!style="background:SlateGray"|Rutas
|-
|
|
|-
|}

FAQ's

[[Categoría:Telefonía]]

Telefonia Guifi.net

2016-07-10T19:37:52Z

Al: Al movió la página Telefonia Guifi.net a Telefonía Guifi.net: Error ortográfico

#REDIRECCIÓN [[Telefonía Guifi.net]]

Telefonía Guifi.net

2016-07-10T19:37:36Z

Al:

Proyecto de Fin de Carrera

2016-01-08T13:24:28Z

Al: /* Acabados */

[[Archivo:Graduate_award.svg|right|200px]]

A menudo<ref name="trastos">https://lists.guifi.net/pipermail/guifi-rdes/2011-November/022033.html</ref><ref>https://lists.guifi.net/pipermail/guifi-usuaris/2012-March/018092.html</ref><ref>https://lists.guifi.net/pipermail/guifi-webdev/2012-March/001769.html</ref>, estudiantes o investigadores contactan con la comunidad de Guifi.net porque desean realizar proyectos de investigación, '''Proyectos de Fin de Carrera''' (PFC) o de final de ciclo CFGS relacionados con la red Guifi.net o que puedan ayudar a su expansión.

Los proyectos o trabajos no tienen porqué ser únicamente '''técnicos''', de informática o telecomunicaciones. Dentro de Guifi.net también tienen cabida proyectos y trabajos de carácter '''legal''', '''social''', '''psicológico''', '''publicidad''', de '''contenidos'''..., etc.

Si estás interesado/a, lo mejor es que contactes con nosotros a través de la [[lista de correo]] de desarrollo ('''guifi-dev''').

== Proyectos ==

=== En desarrollo ===


* ''No conocemos ninguno de momento. ¿Te animas a hacer el próximo?''

=== Acabados ===

{| class="wikitable sortable" 
|- style="background:#ececec;"
! Nombre
! Autor/a
! Año
! Centro de estudios
! Idioma
! Descarga
! Licencia
! Página web
! Comentario
|-
| Interoperability between classic infrastructure and Libre-Mesh networks in Guifi.net
| Gio
| 2015
| University of Pisa
| Inglés
| [http://nicolasacco.diveni.re/~gioacchino/internship-report/main.pdf PDF] [http://nicolasacco.diveni.re/~gioacchino/internship-report/main.html HTML]
| [http://creativecommons.org/licenses/by-sa/4.0/ Creative Commons by-sa]
| El trabajo se desarrolló publicándolo a tiempo real en pad y el código se subió en un git ''(enlaces pendientes)''
| Base conceptual y desarrollo técnico para construir troncales de Guifi.net usando Libre-Mesh
|-
| La liberación de subjetividades y de relaciones entre sujetos a través de mecanismos tecnológicos, culturales y organizativos
| [[Usuario:Al|Ál Cano Santana]]
| 2008
| UAB, departamento de Psicología Social, Facultad de Psicología
| Memoria en catalán, castellano e inglés
| [[bp:Archivo:Al cano santana et al-la liberacion de subjetividades y de relaciones entre sujetos a traves de mecanismos tecnologicos culturales y organizativos-03.pdf|Memoria en PDF]]
| Creative Commons by-sa y GNU FDL
| [[bp:La liberación de subjetividades y de relaciones entre sujetos a través de mecanismos tecnológicos, culturales y organizativos|El trabajo se desarrolló a tiempo real en el wiki de Blogx Populi]]
| Guifi.net no es el centro del trabajo de investigación, si no uno de los ejemplos para uno de los tres campos de análisis.
|-
| Gestión Ciudadana de la Tecnología: Una aproximación desde los Science and Technology Studies a las redes wifi y la governance urbana a través de guifi.net
| Yann Bona Beauvois
| -
| UAB, departamento de Psicología Social, Facultad de Psicología
| Español
| [[:Archivo:Gestion_Ciudadana_de_la_Tecnologia.pdf|PDF]]
| -
| [http://ddd.uab.cat/record/70077?ln=ca] [http://psicologiasocial.uab.es/athenea/index.php/atheneaDigital/article/view/849]
| -
|-
| [[Utilidades Guifi.net]] y [[GuifiManage]]
| [[Usuario:Ganon|Isidro Manzano Navaza]].
| 2012
| [http://www.escoladeltreball.org Escola del Treball de Barcelona]
| Catalan, castellano e ingles
| [https://gitorious.org/caixa-d-eines-de-guifi-net/caixa-d-eines-de-guifi-net Repositorio]
| GPL el código, CC-by los diagramas y GNU FDL la documentación.
| -
| Android - Java
|-
| PFC para mejorar la gestión y el soporte de nuevos dispositivos<ref name="trastos"/><ref>https://lists.guifi.net/pipermail/guifi-rdes/2012-June/024570.html</ref>[https://lists.guifi.net/pipermail/guifi-rdes/2012-June/024782.html] [http://terrassa.guifi.net/pfc_guifi_albertsarle/exposicio.html].
| [[Usuario:Albir|Albert Sarle]]
| 2012
| UAB
| Memoria en catalán
| [https://gitorious.org/~albertsarle/guifi/albertsarle-drupal-guifi_pfc Repositorio] [http://dl.dropbox.com/u/1834023/PFC_guifinet_AlbertSarle.pdf Memoria] [http://terrassa.guifi.net/pfc_guifi_albertsarle/exposicio.html Presentación HTML]
| -
| -
| -
|-
| PFC sobre el desarrollo del firmware [[Quick Mesh Project]] (QMP)
| [[Usuario:Hakais|Pau Escrich]]
| -
| UPC
| Memoria en inglés
| -
| -
| [http://qmp.cat/ Sitio web del proyecto] [http://upcommons.upc.edu/pfc/handle/2099.1/14103] [http://qmp.cat/documents/11 Tesis - Documentación técnica] {{en}}
| -
|-
| Sistema de servidores [[VoIP]] del proyecto guifi.net
| Tomás Velázquez García
| -
| UAB
| -
| -
| -
| [http://ddd.uab.cat/record/70278?ln=ca]
| -
|-
| Millora de la gestió d’una xarxa WiFi: Guifi.net
| Vilajoliu Galceran, Berenguer
| 2006
| UPC
| Catalán
| [http://upcommons.upc.edu/pfc/bitstream/2099.1/3798/1/53927-1.pdf Memoria en PDF]
| -
| [http://upcommons.upc.edu/pfc/handle/2099.1/3798]
| -
|-
| Wifi mesh network nodes on guifi.net
| Duran Rosich, Eduard
| 2009
| UPC
| -
| -
| -
| [http://upcommons.upc.edu/pfc/handle/2099.1/7383]
| -
|-
| Estudi i propostes de millora de la xarxa Guifi.net (I)
| Serra Pàmies, David
| 2008
| UPC
| -
| -
| -
| [http://upcommons.upc.edu/pfc/handle/2099.1/4622]
| -
|-
| Estudio y propuestas de mejora de la red GUIFI.NET (II)
| Vegas Ayora, Javier
| 2007
| UPC
| -
| -
| -
| [http://upcommons.upc.edu/pfc/handle/2099.1/4623]
| -
|-
| Scalability study of Guifi.net and mesh networks
| García Fernández, Víctor N.
| 2011
| UPC
| -
| -
| -
| [http://upcommons.upc.edu/pfc/handle/2099.1/11580]
| -
|-
| Protocolos de encaminamiento en redes inalámbricas mesh: un estudio teórico y experimental
| Albert Batiste Troyano
| 2011
| UOC / US
| Español
| [http://openaccess.uoc.edu/webapps/o2/bitstream/10609/8164/1/abatistet_TFM_0611.pdf]
| -
| -
| -
|-
| Mejora de la aplicación de mapas de Guifi.net<ref>https://lists.guifi.net/pipermail/guifi-webdev/2012-July/001830.html</ref>
| David Rubio Miguélez
| 2012
| UJI
| Español
| [http://pool.blogxpopuli.org/w/images/6/6c/20120715memoriamejoradelaaplicaciondemapasdeguifinet.pdf]
| -
| -
| -
|-
| Perspectiva psicosocial ecológica del proyecto: la red social virtual abierta, libre y neutral basada en infraestructura
| Jordi Paradís Medina
| 2012
| UAB
| Catalán
| [http://generatech.org/sites/default/files/guifinet_social_ecologic.pdf Trabajo de fin de grado en psicología]
| Creative Commons 3.0 BY-NC-SA
| [http://psicovirtual.uab.cat/treballgrau/ocs/index.php/tfgpsico/tfg12/paper/view/25]
| Visió autoetnogràfica i holística d'aquest projecte tecnosocial, que inclou la descripció d'un seguit de dificultats detectades alhora de voler formar-ne part, en general i des de una casa apartada a la muntanya del Montnegre al Maresme Nord.

|-
|[[Monitor|Servei SNPServices amb notificacio]]
|David Pérez Martorell
| 2013
|UOC
|Català
| [[Projecte Servei_de_notificació_d'alertes.odt‎]]
| Creative Commons 3.0 BY-NC-SA
|Presentacio [http://www.kaltura.com/index.php/kwidget/wid/_403921/uiconf_id/4438451/entry_id/1_hnw62y1i]
i Demostracio [http://www.kaltura.com/index.php/kwidget/wid/_403921/uiconf_id/4438451/entry_id/1_l68vxblh]
|Programes que amplien el servei SNPServices. Fa ping als nodes del grup de nodes del servidor d gràfics i informa al servidor web de incidencies. El servidor web envia correus als responsables
|-
| Estudi d'organitzacions commons i creació d'un entorn col·laboratiu per la iniciativa "Bottom up Broadband"
| Adriana Martí Hoppmann
| 2013
| UPC
| Catalán
| [http://upcommons.upc.edu/bitstream/handle/2099.1/18721/89496.pdf]
| -
| [http://upcommons.upc.edu/handle/2099.1/18721]
| Estudio de las redes comunitarias y creación de un entorno colaborativo con el CMS Drupal.
|-
| Trabajo presentación a estudiantes de la UPC
| Laura Álvarez, Ferrán Quer, Maite Intxausti
| 2014
| UPC
| Inglés & español
|
| Creative Commons 4.0 BY-SA
| https://guifi.net/ca/node/73683
|
|-
| Starting, Contributing and Empowering Community Networks in cities.
| Pedro Vílchez
| 2014
| UPF
| Inglés
| [https://github.com/pedro-nonfree/starting-community-networks-in-cities/blob/master/v2.1Community-Networks-in-cities.pdf PDF]
| Creative Commons 4.0 BY-SA
| [https://github.com/pedro-nonfree/starting-community-networks-in-cities github] [http://repositori.upf.edu/handle/10230/22884 UPF]
| Empezar comunidad guifi.net en ciudades con qMp
|-
| Real-Time Communication Network Architecture Design for Organizations with WebRTC.
| Pedro Vílchez
| 2015
| UPF
| Inglés
| [https://github.com/pedro-nonfree/guifi-webrtc/blob/master/buildthesismemory/thesis.pdf PDF]
| Creative Commons 4.0 BY-SA
| [https://github.com/pedro-nonfree/guifi-webrtc github]
| Arquitectura en tiempo real para guifi.net con WebRTC
|-
|Estudi i muntatge d'una illa de guifi.net
|Joan Francesc Arbona
| 2015
|UIB
|Català
| [http://guifisoller.qui.guifi.net:8000/TFG_IllaGuifinet_JoanArbona_Memoria.pdf Estudi i muntatge d'una illa de guifi.net]
| -
| -
|Recull de les experiències i coneixements rebuts en la construcció d'una nova illa de guifi.net a Mallorca.
|-
|Estudio, implantación y visualización de la red Guifi.net en abla
|Francisco Jesús Oliva Herrerías
|2015
|UAL
|Español
|[https://drive.google.com/file/d/0B7nqF9sE_FtnVVBfRWVRN0dabEU/view?usp=sharing Memoria del proyecto]
|
|[http://visualizacionguifi.hol.es/ Web para visualizar la red Guifi.net]
|Trabajo realizado para crear y poner en funcionamiento la primera Isla de Guifi.net en la Provincia de Almería.
|-
|}

== Ideas <ref>{{MM|url=https://lists.guifi.net/pipermail/guifi-usuaris/2012-March/018102.html|list=Usuaris}}</ref> ==
* Repetir algo de http://upcommons.upc.edu/pfc/handle/2099.1/11081 (sobre el orden "de entrada" de los paquetes ad-hoc vs infraestructura en un mismo canal)
* Plugins BGP-(OLSR/BATMAN/BMX)
* Comparación rendimiento wifi del AP-AP wds vs AP-cliente wds

=== Personas del guifibages a finales de 2009 propusieron ===
* Evaluar el rendimiento de OLSR y compararlo con otros protocolos de enrutamiento dinámico. Buscar qué significan todos los parámetros de configuración y optimizar el rendimiento en guifibages.
* Estudiar el driver madwifi y optimizar el rendimiento en las condiciones guifibages (iría ligado con el anterior en un posible proyecto: "Optimización de guifibages: madwifi + OLSR".
* Sistema de visualización en tiempo real de la calidad del enlace integrado en los mapas de Guifi.net a partir del plugin olsr-dot-draw/olsr-txtinfo.
* Creación de un testbed openwrt + mesh en la UPC: que el proyectista monte en la universidad una serie de radios dispersos por los edificios que se puedan poner en marcha, para y configurar desde un servidor "central".
* Es un tipo de "encargo" que nos hemos tomado de la [[Open Spectrum Alliance]]. Se trataría de evaluar la ocupación de las frecuencias de TV (analógica y TDT) para averiguar los "espacios en blanco" de una zona.
* [https://lists.guifi.net/pipermail/guifi-rdes/2011-November/022064.html] [https://lists.guifi.net/pipermail/guifi-rdes/2011-November/022066.html]

== Véase también ==
* [[Google Summer of Code]]
* [[Publicaciones]]

== Referencias ==
<references/>

== Enlaces externos ==
* http://guifi.net/ca/node/3496 {{ca}}
* http://guifi.net/ca/ProjectesInvestigacio {{ca}}
* [http://ddd.uab.cat/search?ln=ca&as=1&m1=a&p1=guifi&f1=title&op1=a&m2=a&p2=&f2=codititulacio&op2=a&m3=a&p3=&f3=year&action_search=Cerca&c=Dip%C3%B2sit+Digital+de+Documents+de+la+UAB&sf=&so=a&rm=&rg=10&sc=1&of=hb Depósito Digital de Documentos de la UAB: guifi]
* [http://upcommons.upc.edu/pfc/simple-search?query=guifi Trabajos académicos UPC: guifi], upcommons

[[Categoría:Material académico]]

Fibra óptica

2015-12-04T14:25:26Z

Al: /* Conocimientos técnicos */

La '''fibra óptica''' es un [[medio de transmisión]] de datos digitales. Físicamente se trata de un hilo muy fino de material transparente y económico como vidrio o materiales plásticos por el que se envían pulsos de luz que representan los datos a transmitir. La fuente de luz puede ser [[láser]] o un [[LED]].

La [[velocidad de datos]] transmitidos por fibra se miden en [[Gigabit por segundo]], siendo actualmente el medio de transmisión de datos digitales más rápido. Son el medio de transmisión por excelencia al ser inmune a las interferencias electromagnéticas. Se utiliza en kilométricos cables submarinos que unen internet y también se utilizan para cortas redes locales.

En Guifi.net el despliegue de fibra óptica consta de dos retos, el tecnológico, fácilmente asumible con unas base de conocimientos técnicos, y, el mayor, el administrativo.

= Cómo iniciar administrativamente un proyecto de fibra óptica de Guifi.net =
Para iniciar un proyecto de fibra óptica de Guifi.net has de
# identificar el territorio por donde desplegarás la fibra
# reunirte con organizaciones y personas de la zona que fácilmente apoyarían el proyecto incluso económicamente (empresas locales, asociaciones de vecinos,...)
# tener en cuenta en qué ubicación o ubicaciones conectarías el territorio con el resto de internet (buscar mucho ancho de banda o, de ser posible, a un punto de fibra de Guifi.net)
# identificar, si es posible (por ejemplo, con acceso a los datos públicos de urbanismo del ayuntamiento, de tenerlos), las canalizaciones subterráneas o aéreas por dónde desplegarías la fibra
# con el conjunto de datos recabados anteriormente redactar un proyecto a presentar al ayuntamiento, por ejemplo al concejal de urbanismo. '''Importante: incorporar en el proyecto los tubos, arquetas, etcétera que la propiedad se la queda el instalador de Guifi.net sin cederlo a ningun operador'''<ref>http://guifi.net/ca/node/30425#comment-28625</ref>
# según la nueva ley estatal que regula el [http://www.lamoncloa.gob.es/ConsejodeMinistros/Referencias/_2013/refc20130913.htm#Telecomunicaciones despliegue de redes de telecomunicaciones], el proyecto será aprobado y podrás pasar al despliegue técnico
# Finalmente se firma el convenio con el ayuntamientos (o la institución pública pertinente) donde a '''cambio de que cedan gratuitamente los conductos nos comprometemos a que la red sea abierta y con ello beneficie a todos los vecinos''', que son los propietarios reales y quienes de verdad pagamos las obras públicas con nuestros impuestos, para que puedan conectarse sin discriminaciones.<ref>http://guifi.net/ca/node/30425#comment-28625</ref>

== Algunos ejemplos de proyectos enviados a ayuntamientos ==
''Los estamos buscando, si tienes un proyecto de éxito, por favor, ¡[[Especial:SubirArchivo|súbelo]]!''
* [http://guifi.net/es/node/23288 Descripción del primer tramo de fibra en Gurb (FFTF)]

== Algunos ejemplos de convenios firmados a ayuntamientos ==
''Los estamos buscando, si tienes un proyecto de éxito, por favor, ¡[[Especial:SubirArchivo|súbelo]]!''

== Estimaciones económicas ==
En zonas rurales pero dispersas con masias aisladas, estamos calculando que como mucho cuesta 3K€ por vivienda, lo que amortizado a 12 años y su mantenimiento son 24€/mes<ref>http://guifi.net/ca/node/30425#comment-28625</ref>.

=== Desglosado ===
* 4 km de cable multifibra a 2 €/m : 8.000 €
* 4 km de cable de dos fibras a 0,5 €/m : 2.000 €
* Rack, switches, conectores... : 10.000 €
* 20 sangrados a 250 € : 5.000 €<ref>http://guifi.net/ca/node/30425#comment-28662</ref>

= Conocimientos técnicos =

[[Archivo:6504773967_6733d231aa_b.jpg|thumb|right|200px|Tubo con 720 fibras]]

== Descripción ==
'''Tipos de empalmes en fibra óptica'''
* Soldadura de fusión
* Mecánicos con conectores ópticos de precisión

'''Parámetros de catalogación de fibra óptica'''
* Atenuación (dB/km)
* Dispersión

'''Tipos de fibra'''
* Monomodo
* Multimodo
** Grados de fibra multimodo: OM1, OM2 y OM3. Ver norma ISO/IEC11801<ref>[http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=36491 ISO/IEC 11801:2002] (PDF de pago)</ref>

'''Tipos de servicio'''
* Fibra iluminada. Servicio de transmisión de datos, de conectividad. El contratante no hace falta que tenga los equipos necesarios para la comunicación, ya que estos los gestiona el dueño de la fibra óptica<ref>[http://wikitel.info/wiki/Fibra_iluminada Fibra iluminada], Wikitel</ref>
* Fibra oscura. Servicio de alquiler de fibra óptica operada por un operador externo y permite interconectar equipos como si fuera un cable. El contratante debe tener los equipos necesarios para la comunicación, ya que el dueño de la fibra óptica solo la alquila<ref>[http://wikitel.info/wiki/Fibra_oscura Fibra oscura], Wikitel</ref>

'''Más conceptos'''
* [[PON]] (Redes Ópticas Pasivas, del inglés Passive Optical Network). Red punto-multipunto sin elementos activos entre servidor y cliente. Sustituyen tramos de cable coaxial por fibra óptica monomodo y divisores eléctricos (splitters) por divisores ópticos. De esta manera se reduce la inversión y los costes de mantenimiento<ref>[http://wikitel.info/wiki/PON PON], Wikitel</ref>
* [[GPON]] (Gigabit-capable PON), son un tipo de arquitectura de red óptica pasiva (PON) que alcanza velocidades de Gbps (ofrece tasas de transferencia de hasta 1,25 Gbps en caudales simétricos y hasta 2,5 Gbps en caudales asimétricos)<ref>[http://wikitel.info/wiki/GPON GPON], Wikitel</ref>
* [[WDM]] (Wavelength Division Multiplexing). Técnica para multiplexar y poder usar longitudes de onda diferentes sobre una misma fibra
* [[Módulo OLT]] (Unidad Óptica Terminal de Línea, del inglés Optical Line Terminal). Dispositivo que transforma señales eléctricas en señales ópticas, usado principalmente en los proveedores de servicios<ref>[http://en.wikipedia.org/wiki/Optical_line_termination OLT]</ref>
* [[Módulo ONU]] (Unidad Óptica de Usuario, del inglés Optical Network Unit). Dispositivo que transforma señales ópticas en señales eléctricas, usado principalmente en la casa de los usuarios finales
* [[Módulo ONT]] (Únidad Óptica de Red, del inglés Optical Network Terminal). Dispositivo ONU que concretamente sirve a un solo usuario final
* [[Divisor óptico o splitter]]. Multiplexan la fibra óptica y permite ramificar la red<ref>[http://wikitel.info/wiki/Divisor_%C3%B3ptico Divisor Óptico], Wikitel</ref>

=== Red PON ===
Una red PON precisa los siguientes componentes:
* Módulo OLT (uno, en el nodo central)
* Divisores ópticos (tantos como queramos para expandir la red)
* Módulos ONU (tantos como viviendas)

La transmisión se realiza entre OLT y ONU usando dos longitudes de onda diferentes y superpuestas (mediante técnicas WDM), una para cada canal (ascendiente (ONU->OLT) y descendiente (OLT->ONU), subida y bajada). Para luego separar ambas longitudes de ondas es necesario usar unos filtros ópticos específicos.

GPON es una recomendación definida en la familia G.984 aprobada por el ITU-T en 2004. La familia de recomendaciones G.984 comprende G.984.1, G.984.2, G.984.3 y G.984.4<ref>[http://en.wikipedia.org/wiki/G.984 G.984]</ref>.

= Fibra óptica de Guifi.net =
A día de hoy Guifi.net ha desplegado dos tramos de fibra óptica. Ambos se encuentran en la provincia de Barcelona. uno en Gurb<ref>[http://guifi.net/node/23288 Guifi.net: Descripción del primer tramo de fibra en Gurb (FFTF)]</ref> y otro en Taradell<ref>[http://guifi.net/fibraopticataradell Guifi.net: Posant Fibra Òptica a Taradell 13/11/2010]</ref><ref>[http://guifi.net/ca/taradellfibraoptica Guifi.net: Il·luminada la Fibra Òptica de guifi.net a Taradell]</ref><ref>[http://guifi.net/image/tid/249 Galería de fotos: Fibra Òptica a Taradell]</ref>.

== Gurb ==
Operativa desde 2009. Tiene una velocidad teórica de 1Gbps.

El tendido es principalmente aéreo, usando los palos de la línea de cobre de Telefónica ya existentes, algunas fachadas y algún tramo sepultado.

Proporciona conexión a varias masías de Gurb y está conectada con la fibra óptica de la Generalitat de Cataluña.

== Taradell ==
Operativa desde el 15 de noviembre de 2010. Tiene una velocidad teórica de 100Mbps (velocidad real de 98Mbps).

Une punto a punto [[Gaufix.net]] con el Instituto de Educación Secundaria de Taradell.

En los extremos hay cajas de conexión para facilitar la expansión de la fibra óptica con enlaces a otros puntos

== Sant Bartomeu del Grau ==
Operativa desde el 22 de febrero de 2012. Tiene una velocidad teórica de 1Gbps y une ''Telecentre'' con ''Torre''.<ref>https://twitter.com/#!/gaufix/status/172381871932579840</ref>

= Convenios de uso de fibra óptica =
En agosto de [[2010]], Guifi.net firma un convenio con la Generalitat de Cataluña para llevar la fibra óptica a zonas rurales<ref>[http://blogs.guifi.net/rroca/2010/08/03/guifi-net-signa-un-conveni-amb-la-generalitat-per-estendre-fibra-optica-en-zones-rurals/ Guifi.net signa un conveni amb la Generalitat per estendre fibra òptica en zones rurals]</ref>. Este tramo va desde el punto neutro [[CATNIX]] en Girona hasta [[Gurb]].

= Preguntas frecuentes =
* ¿Qué hay que hacer para optar al [[Glosario#M|MARCo]] de Telefónica?<ref>[https://lists.guifi.net/pipermail/guifi-instal/2011-October/000791.html Preguntas Conductos de telefonica], guifi-instal</ref>
** Es necesario ser un operador de telecomunicaciones inscrito en el registro de operadores de la CMT (se recomienda hacerlo en nombre de la [[Fundación Guifi.net]] y bajos las condiciones de la XOLN). Es importante aclarar que el marco sólo se aplica cuando el conducto sea de Telefónica. Como operador público podemos pedir compartirlo (como privados no). Tener en cuenta también que la mayoría de los conductos no son de Telefónica sino de los Ayuntamientos.<ref>https://lists.guifi.net/pipermail/guifi-instal/2011-October/000792.html</ref><ref>https://lists.guifi.net/pipermail/guifi-instal/2011-October/000797.html]</ref>

= Referencias =
<references/>

= Véase también =
* Documento que recoge la propuesta de cesión del uso de la antigua fibra óptica de Caixa Laietana en [[Mataró]]: [[Archivo:Propuesta fibra Caixa Laietana Diciembre 2012.odt]]

= Enlaces externos =
* [[wikipedia:es:Fibra óptica|Fibra óptica]] en Wikipedia español
* [http://www.movistar.es/on/onTOFichaProducto?ficha=3&v_producto=64049&v_idioma=es&v_segmento=AOPN&v_pestania=3 Oferta de Acceso a Registros y Conductos (MARCo)], movistar.es
* [http://www.ftthcouncil.eu/ FTTH Council Europe]
* [http://en.wikipedia.org/wiki/Fiber_to_the_x FTTx]
* [http://wikitel.info/wiki/UA-Redes_PON_GPON_derivados UA-Redes PON GPON derivados], Wikitel
* [http://www.flickr.com/photos/11370436@N04/ Galería de Groupe Aménagement Numérique des Territoires], Flickr

; Empresas
* [http://www.optral.es/ Optral]
* [http://www.telnet-ri.es/ Telnet]
** [http://www.telnet-ri.es/fileadmin/user_upload/hojas_producto/CABLES_FO/06_PKCP.pdf Cable de Fibra Óptica anticazadores aéreo PKCP]

[[Categoría:Fibra óptica]]

[[ca:fibra òptica]]

Modelos de gestión de tramos de red libre

2015-08-19T23:32:26Z

Al: Página creada con «El concepto de red abierta, libre y neutral hace referencia a la libertad de poder conectarse, saber cómo funciona la red, poder ampliarla y poder hacer fluir contenidos l...»

El concepto de red abierta, libre y neutral hace referencia a la libertad de poder conectarse, saber cómo funciona la red, poder ampliarla y poder hacer fluir contenidos libremente todo ello manteniendo el buen funcionamiento de la red para todo el mundo. Ahora bien, dentro de este concepto hay varios modelos que las personas usuarias han desarrollado para gestionar sus tramos de red. Estos modelos conviven dentro de la red abierta, libre y neutral entramándose unos con otros y la implementación de un modelo u otro depende tan sólo de la voluntad de las usuarias en función de sus intereses, recursos, tradición cultural, etcétera,... Ningún modelo es mejor que otro siempre y cuando todos respeten la licencia de la red abierta, libre y neutral.

== Modelo comunitario horizontal ==
Un grupo de personas normalmente de una misma ubicación geográfica determinada se organizan para diseñar, construir y mantener una red. Se autocapacitan entre ellas para tener los conocimientos para hacerlo, toman decisiones de forma asamblearia y compran-construyen los materiales y mantienen los gastos periódicos (conexión con otras redes, gastos eléctricos, reposición de supernodos,...) entre todas, ya sea a través de cuotas de las que ellas mismas deciden el precio o a través de gastos puntuales según necesidades puntuales. Pueden constituir o no una organización legal o no para llevarlo a cabo.

=== Submodelo comunitario cooperativa de consumo de abajo a arriba ===
A veces el modelo comunitario horizontal ya sea en sus inicios o a partir de un momento dado que la red requiere mucho mantenimiento, puede decidir (o no) mutar su modelos a un modelo de cooperativa de consumo (similar al de las cooperativas o grupos de consumo de alimentos ecológicos locales) en el que esas personas ya sea por falta de tiempo o por cualquier otro motivo deciden mantener las decisiones asamblearias pero la gestión técnica en manos de una especialista técnico (o unas pocas especialistas técnicas) que actúa como un profesional liberado en beneficio de toda la red. En este caso las aportaciones siempre son periódicas en la que se suman los gastos periódicos, puntuales y el sueldo de la persona o personas técnicas destinadas y se divide entre todas las unidades familiares o comunidades de vecinos que participan de la red.

== Modelo instalador altruista voluntario ==
A veces hay personas que por pasión, amor al proyecto, por aprender y mejorar, por hacer currículum o cualquier otro motivo dedica su conocimiento y parte de su tiempo a montar, reparar y/o mantener nodos de red libre a otras personas u organizaciones. A veces lo hace a partir del material pagado por esas personas u organizaciones o a veces incluso lo pone de su propio bolsillo. Estas personas, por supuesto, en cualquier momento pueden dejar de hacerlo (de hecho, es común que en algún momento suceda) y que esos tramos de red pasen a otro modelo de gestión o, desgraciadamente, queden sin uso o apagados o incluso algún espabilado los privatice, se los reapropie y las usuarias pierdan las libertades.

== Modelo emprendedor de arriba a abajo ==
Una persona o un conjunto de personas con conocimientos técnicos para la construcción y mantenimiento de tramos de red libre se anuncian abiertamente para la construcción y mantenimiento con tarifas muchas veces puntuales (por ejemplo coste por hora por montar un nodo y realizar la primera conexión) y en ocasiones también periódicas (por proveer de servicios de internet, telefonía, web, servidores, etcétera,...) a personas u organizaciones que quieren formar parte de la red libre. Normalmente esta persona o personas trabaja/n bajo el nombre de una organización empresarial o como autónomos.

== Modelo de libre conexión individualista ==
Como la red abierta libre y neutral mantiene por licencia toda la documentación de cada nodo de la red incluida su ubicación e IPs cualquier persona individual puede, leyendo la documentación on-line general de WiFi y/o fibra óptica y específica de la ubicación determinada, conectarse a un nodo de la red abierta, libre y neutral siguiendo los pasos y respetando la licencia. Podrá hacerlo sin necesidad de contactar con la/s persona/s si es directamente a un nodo en modo AP altruista abierto a la interconexión o un nodo en modo ad-hoc o tendrá la necesidad de contactar y ampliar físicamente el nodo de la otra ubicación llevando un nuevo trasto que le permita ampliar la red en su dirección.

== Conclusiones ==
Estos no son los únicos modelos posibles. Son tan sólo unos ejemplos de implementaciones reales. Pueden crearse otros según necesidades específicas o también existen modelos que mixturan varios de estos modelos. Siéntete libre de utilizar cualquiera de ellos siempre y cuando respetes la licencia. La existencia de estos modelos de gestión en una red determinada no garantizan tampoco que esa red sea abierta, libre y neutral. Por ejemplo un tramo de red que tiene unos gestores que te obligan a seguir uno de estos modelos no es una red abierta, libre y neutral.

[[Categoría:social]]

LibreMesh

2015-08-05T18:59:05Z

Al:

'''Libre-mesh''' es una iniciativa llevada adelante por miembros de redes comunitarias de diferentes continentes que se organizan para unificar esfuerzos en el desarrollo de herramientas útiles para facilitar el despliegue de Redes Libres para cualquier comunidad del mundo.

La herramienta principal es el [https://dev.libre-mesh.org/projects/libre-mesh firmware Libre-mesh]: basado en [[OpenWrt]] estandariza la creación de comunidades WiFi y provee de [[roaming]] a las comunidades ya existentes.

Otras herramientas son:

*[https://dev.libre-mesh.org/projects/librenet6 Librenet6]: un mesh tunnel broker para proveer IPv6 globales a las redes libres
*[https://colectivo.altermundi.net/projects/chef Chef]: creador de firmwares a medida para comunidades
*[https://github.com/libremap Libremap] (en colaboración con Freifunk): representación de nodos según su ubicación geográfica con actualización de calidades de enlace a tiempo real.

Las herramientas se pueden utilizar por separado o todas juntas, actualmente estamos trabajando en la integración automatizada del uso de todas ellas.

Este proyecto nació como un esfuezo para fusionar algunos proyectos de firmware preexistentes:

* AlterMesh (de AlterMundi, Argentina)
* qMp (de guifi.net, Catalunya)
* eigenNet (de eigenLab, Ninux, Italia)

Y con el apoyo de algunas organizaciones existentes:

* the Free Network Foundation (de USA)
* the Guifi.net Foundation (de Catalunya)

Si quieres colaborar con el proyecto [https://lists.libre-mesh.org/mailman/listinfo/dev utiliza la lista de correo]

== Cómo escoger la versión de firmware a instalar ==
A partir del Chef puedes escoger una de estas versiones según tus necesidades:
{|
! Libre-mesh v.
! Descargable en:
! BATMAN-Adv
! BMX6
! Internet Detection
! Centralized DNS
! Distributed DNS
! Anygw
|-
| 36140
|
| y
| n
| y
| y
| n
| n
|-
| 15.04 (44952)
|
| y
| y
| n
| n
| n
| y
|-
| 15.07rc1
|
| y
| y
| n
| n
| y
| y
|-
| 15.07final
|
| y
| y
| y
| y
| y
| y
|}

El splash se puede instalar de la siguiente manera:

El reconocimiento de nombres dentro de batctl se habilita de la siguiente manera:

== Enlaces externos ==
* [https://libre-mesh.org Página oficial]

[[Categoría:MANET]]

Unsoloclic/RouterOS

2015-04-16T19:00:43Z

Al:

Explicación paso a paso de la configuración de unsoloclic para [http://test.guifi.net/es/guifi/device/43337/view/unsolclic RouterOSv3.x] ([http://test.guifi.net/es/node/41592 web del nodo])

__TOC__
== Fichero ==
Este es el archivo [[unsoloclic]] generado en febrero de 2013:

<pre>
# Generado por:
# RouterOSv3.x
:log info "Unsolclic for 43337-MLGforjaRd1 going to be executed."
#
# Configuration for RouterOSv3.x
# Dispositivo: 43337-MLGforjaRd1
#
# Métodos para subir/ejecutar este script:
# 1.-Como un script. Sube este texto como un script bien con:
# a.Winbox (con Linux es necesario wine)
# b.Terminal (telnet, ssh...)
# Entonces ejecuta el script con:
# > /system script run nombre_del_script
# 2.-Fichero importado:
# Guarda este texto en un fichero, luego súbelo al router
# utilizando ftp con un nombre como "script_name.rsc".
# (ten en cuenta que la extensión ".rsc" es necesaria)
# Ejecuta el fichero importado utilizando el comando:
# > /import nombre_del_script
# 3.-Telnet copiar&pegar:
# Abre una sesión de terminal, y copia y pega el texto
# directamente en la ventana de la terminal.
#
# Notas:
# -El paquete routing-test es necesario si utilizas RouterOSv2.9 , asegúrate de que lo tienes activado en system packages
# -las wlans deberían activarse de forma manual. Asegúrate de que están establecidas en la antena correcta (a/b)
# de acuerdo con cómo has conectado el cable a la miniPCI. Mantén la
# potencia al mínimo posible y comprueba el canal.
# -El script no reinicia el router. Quizá tengas que hacerlo de forma manual
# -Debes tener acceso de escritura al router
# -Se recomienda el método de acceso por MAC (winbox, telnet a la MAC...)
# (el script reconfigura algunas direcciones IP, así que se puede perder la comunicación)
# -No se realizan cambios en las contraseñas de usuario del dispositivo
# -Se creará una cuenta de invitado de Sólo Lectura para permitir el acceso de invitados
# al router sin riesgo de daño pero con capacidad para ver la configuración.
# -Asegúrate de que todos los paquetes están activados.
# -No ejecutes el script desde telnet si estás conectado mediante una conexión IP en
# la interfaz: Esta interfaz será desctruida durante la ejecución del script.
#
/ system identity set name=MLGforjaRd1
#
# DNS (client & server cache) zone: 53395
:delay 1
#
# NTP (client & server cache) zone: 53395
:delay 1
#
# Servidor de ancho de banda
/ tool bandwidth-server set enabled=yes authenticate=no allocate-udp-ports-from=2000
#
# SNMP
/snmp set contact="guifi@guifi.net" enabled=yes location="MLGForja"
#
# Guest user
/user
:foreach i in [find group=read] do={/user remove $i;}
add name="guest" group=read address=0.0.0.0/0 comment="" disabled=no
#
# Gráficas
/tool graphing interface add
# Eliminar el puente (bridge) actual wLan/Lan si existe
:foreach i in [/interface bridge find name=wLan/Lan] \
do={:foreach i in [/interface bridge port find bridge=wLan/Lan] \
do={/interface bridge port remove $i; \
:foreach i in [/ip address find interface=wLan/Lan] \
do={/ip address remove $i;};};
/interface bridge remove $i;}
# Crear puente (bridge) principal entre wlan1 y ether1
/ interface bridge
add name="wLan/Lan"
/ interface bridge port
add interface=ether1 bridge=wLan/Lan
add interface=wlan1 bridge=wLan/Lan
:delay 1
#
# Radio#: 0 MLGMLGfrjRd1AP0
/interface wireless set wlan1 name="wlan1" \
radio-name="MLGMLGfrjRd1AP0" mode=ap-bridge ssid="guifi.net-MLGMLGfrjRd1AP0" \
band="5ghz" \
frequency-mode=regulatory-domain country=spain antenna-gain=14 \
dfs-mode=radar-detect \
antenna-mode=ant-a wds-mode=static wds-default-bridge=none wds-default-cost=100 \
wds-cost-range=50-150 wds-ignore-ssid=yes hide-ssid=no
:delay 1
# Type: wLan/Lan
/ip address
:foreach i in [find address="10.64.2.161/29"] do={remove $i}
/ ip address add address=10.64.2.161/29 network=10.64.2.160 broadcast=10.64.2.167 interface=wLan/Lan disabled=no
/ routing bgp network
:foreach i in [/routing bgp network find network=10.64.2.160/29] do={/routing bgp network remove $i;}
add network=10.64.2.160/29 disabled=no
/ routing ospf interface
:foreach i in [/routing ospf interface find interface=wLan/Lan] do={/routing ospf interface remove $i;}
add interface=wLan/Lan
/ routing ospf network
:foreach i in [/routing ospf network find network=10.64.2.160/29] do={/routing ospf network remove $i;}
add network=10.64.2.160/29 area=backbone disabled=no
:delay 1
#
# DHCP
:foreach i in [/ip pool find name=dhcp-wLan/Lan] do={/ip pool remove $i;}
/ip pool add name=dhcp-wLan/Lan ranges=10.64.2.166-10.64.2.166
:foreach i in [/ip dhcp-server find name=dhcp-wLan/Lan] do={/ip dhcp-server remove $i;}
/ip dhcp-server add name=dhcp-wLan/Lan interface=wLan/Lan address-pool=dhcp-wLan/Lan disabled=yes
:foreach i in [/ip dhcp-server network find address="10.64.2.160/29"] do={/ip dhcp-server network remove $i;}
/ip dhcp-server network add address=10.64.2.160/29 gateway=10.64.2.161 domain=guifi.net comment=dhcp-wLan/Lan
/ip dhcp-server lease
:foreach i in [find comment=""] do={remove $i;}
:delay 1
add address=10.64.2.162 mac-address=99:99:99:99:99:9A client-id=ALHFuenteDelPerroRd1 server=dhcp-wLan/Lan
#
:delay 1
# Type: wLan
/ip address
:foreach i in [find address="10.64.2.193/27"] do={remove $i}
/ ip address add address=10.64.2.193/27 network=10.64.2.192 broadcast=10.64.2.223 interface=wlan1 disabled=no
/ routing bgp network
:foreach i in [/routing bgp network find network=10.64.2.192/27] do={/routing bgp network remove $i;}
add network=10.64.2.192/27 disabled=no
/ routing ospf interface
:foreach i in [/routing ospf interface find interface=wlan1] do={/routing ospf interface remove $i;}
add interface=wlan1
/ routing ospf network
:foreach i in [/routing ospf network find network=10.64.2.192/27] do={/routing ospf network remove $i;}
add network=10.64.2.192/27 area=backbone disabled=no
:delay 1
#
# DHCP
:foreach i in [/ip pool find name=dhcp-wlan1] do={/ip pool remove $i;}
/ip pool add name=dhcp-wlan1 ranges=10.64.2.199-10.64.2.222
:foreach i in [/ip dhcp-server find name=dhcp-wlan1] do={/ip dhcp-server remove $i;}
/ip dhcp-server add name=dhcp-wlan1 interface=wlan1 address-pool=dhcp-wlan1 disabled=no
:foreach i in [/ip dhcp-server network find address="10.64.2.192/27"] do={/ip dhcp-server network remove $i;}
/ip dhcp-server network add address=10.64.2.192/27 gateway=10.64.2.193 domain=guifi.net comment=dhcp-wlan1
/ip dhcp-server lease
:foreach i in [find comment=""] do={remove $i;}
:delay 1
#
:delay 1
# Type: wds/p2p
# Eliminar todas las interfaces wds existentes
:foreach i in [/interface wireless wds find master-interface=wlan1] \
do={:foreach n in [/interface wireless wds get $i name] \
do={:foreach inum in [/ip address find interface=$n] \
do={/ip address remove $inum;};}; \
/interface wireless wds remove $i;}
#
:delay 1
#
# Routed device
#
# Otra conexiones cableadas
#
# NAT de direcciones internas
:foreach i in [/ip firewall nat find src-address="172.16.0.0/12"] do={/ip firewall nat remove $i;}
:foreach i in [/ip firewall nat find src-address="192.168.0.0/16"] do={/ip firewall nat remove $i;}
/ip firewall nat
add chain=srcnat src-address="192.168.0.0/16" dst-address=!192.168.0.0/16 action=src-nat to-addresses=10.64.2.161 comment="" disabled=no
#
# Enrutamiento BMP
# Filtros BGP & OSPF
:foreach i in [/routing filter find chain=ospf-in] do={/routing filter remove $i;}
:foreach i in [/routing filter find chain=ospf-out] do={/routing filter remove $i;}
:foreach i in [/routing filter find chain=ebgp-in] do={/routing filter remove $i;}
:foreach i in [/routing filter find chain=ebgp-out] do={/routing filter remove $i;}
/ routing filter
add chain=ebgp-in comment="0. Set ebgp-in preferred source." set-pref-src="10.64.2.161" disabled=no
add action=discard chain=ebgp-in comment="1. Discard insert non 10.x routes from BGP peer" disabled=no invert-match=no prefix=!10.0.0.0/8 prefix-length=8-32
add action=discard chain=ebgp-out comment="2. Discard send non 10.x routes to BGP peer" disabled=no invert-match=no prefix=!10.0.0.0/8 prefix-length=8-32
add action=accept chain=ospf-in comment="3. Accept insert 10.x routes from OSPF neighbor" disabled=no invert-match=no prefix=10.0.0.0/8 prefix-length=8-32 set-pref-src="10.64.2.161"
add action=accept chain=ospf-in comment="4. Accept insert 172.x routes from OSPF neighbor" disabled=no invert-match=no prefix=172.16.0.0/12 prefix-length=8-32
add action=discard chain=ospf-in comment="5. Discard insert non 10.x and 172.x from OSPF neighbor" disabled=no invert-match=no
add action=accept chain=ospf-out comment="6. Allow send 10.x routes to OSPF neighbor" disabled=no invert-match=no prefix=10.0.0.0/8 prefix-length=8-32
add action=accept chain=ospf-out comment="7. Allow send 172.x routes to OSPF neighbor" disabled=no invert-match=no prefix=172.16.0.0/12 prefix-length=8-32
add action=discard chain=ospf-out comment="8. Discard send non 10.x and 172.x to OSPF neighbor" disabled=no invert-match=no
#
# instancia BGP
/ routing bgp instance
set default name="default" as=43337 router-id=10.64.2.161 \
redistribute-connected=yes redistribute-static=yes redistribute-rip=yes \
redistribute-ospf=yes redistribute-other-bgp=yes out-filter=ebgp-out \
client-to-client-reflection=yes comment="" disabled=no
#
# Enrutamiento OSPF
/routing ospf set router-id=10.64.2.161 distribute-default=never redistribute-connected=no \
redistribute-static=no redistribute-rip=no redistribute-bgp=as-type-1
#
:log info "Unsolclic for 43337-MLGforjaRd1 executed."
/
</pre>

== Explicación paso a paso ==
* Empieza con un comentario
* Guarda en el log que se empieza a ejecutar el script

<pre>
# Generado por:
# RouterOSv3.x
:log info "Unsolclic for 43337-MLGforjaRd1 going to be executed."
#
# Configuration for RouterOSv3.x
# Dispositivo: 43337-MLGforjaRd1
#
# Métodos para subir/ejecutar este script:
# 1.-Como un script. Sube este texto como un script bien con:
# a.Winbox (con Linux es necesario wine)
# b.Terminal (telnet, ssh...)
# Entonces ejecuta el script con:
# > /system script run nombre_del_script
# 2.-Fichero importado:
# Guarda este texto en un fichero, luego súbelo al router
# utilizando ftp con un nombre como "script_name.rsc".
# (ten en cuenta que la extensión ".rsc" es necesaria)
# Ejecuta el fichero importado utilizando el comando:
# > /import nombre_del_script
# 3.-Telnet copiar&pegar:
# Abre una sesión de terminal, y copia y pega el texto
# directamente en la ventana de la terminal.
#
# Notas:
# -El paquete routing-test es necesario si utilizas RouterOSv2.9 , asegúrate de que lo tienes activado en system packages
# -las wlans deberían activarse de forma manual. Asegúrate de que están establecidas en la antena correcta (a/b)
# de acuerdo con cómo has conectado el cable a la miniPCI. Mantén la
# potencia al mínimo posible y comprueba el canal.
# -El script no reinicia el router. Quizá tengas que hacerlo de forma manual
# -Debes tener acceso de escritura al router
# -Se recomienda el método de acceso por MAC (winbox, telnet a la MAC...)
# (el script reconfigura algunas direcciones IP, así que se puede perder la comunicación)
# -No se realizan cambios en las contraseñas de usuario del dispositivo
# -Se creará una cuenta de invitado de Sólo Lectura para permitir el acceso de invitados
# al router sin riesgo de daño pero con capacidad para ver la configuración.
# -Asegúrate de que todos los paquetes están activados.
# -No ejecutes el script desde telnet si estás conectado mediante una conexión IP en
# la interfaz: Esta interfaz será desctruida durante la ejecución del script.
#
</pre>

* Define el nombre del sistema (nombre del nodo)
* Configura DNS (opcional) y espera un segundo
* Configura NTP (opcional) y espera un segundo
<pre>
/ system identity set name=MLGforjaRd1
#
# DNS (client & server cache) zone: 53395
:delay 1
#
# NTP (client & server cache) zone: 53395
:delay 1
</pre>

* Activa el servidor para hacer pruebas de ancho de banda (puerto 2000 UDP y en adelante)
* Activar SNMP
<pre>
#
# Servidor de ancho de banda
/ tool bandwidth-server set enabled=yes authenticate=no allocate-udp-ports-from=2000
#
# SNMP
/snmp set contact="guifi@guifi.net" enabled=yes location="MLGForja"
</pre>

* Añade usuario invitado (guest), grupo lectura

<pre>
#
# Guest user
/user
:foreach i in [find group=read] do={/user remove $i;}
add name="guest" group=read address=0.0.0.0/0 comment="" disabled=no
</pre>

* Añade la herramienta de gráficas (accesible desde la interfaz web, p.ej.: http://192.168.88.1/graphs/)
* Quita bridge e ips a wLan/Lan (si hubiera)
<pre>
#
# Gráficas
/tool graphing interface add
# Eliminar el puente (bridge) actual wLan/Lan si existe
:foreach i in [/interface bridge find name=wLan/Lan] \
do={:foreach i in [/interface bridge port find bridge=wLan/Lan] \
do={/interface bridge port remove $i; \
:foreach i in [/ip address find interface=wLan/Lan] \
do={/ip address remove $i;};};
/interface bridge remove $i;}
</pre>

* Crea puente entre wlan1 y ether1 (con nombre: "wLan/Lan")
* Espera 1 segundo

<pre>
# Crear puente (bridge) principal entre wlan1 y ether1
/ interface bridge
add name="wLan/Lan"
/ interface bridge port
add interface=ether1 bridge=wLan/Lan
add interface=wlan1 bridge=wLan/Lan
:delay 1
</pre>

* Configura la radio:
** Nombre: MLGMLGfrjRd1AP0
** Modo: ap-bridge
** SSID: guifi.net-MLGMLGfrjRd1AP0
** Frecuencia: 5ghz
** Modo de frecuencia: regulatory-domain
** País: spain
** Ganancia antena: 14
** Modo DFS: radar-detect
** Modo antena: ant-a
** Modo WDS: static
** Sin bridge WDS
** Otros valores WDS
** Ocultar SSID: no
* Configura la IP
** Busca el rango (10.64.2.161/29) por si estuviera ya asignado y lo borra
** Configura la interfaz wLan/Lan creada anteriormente. IP: 10.64.2.161/29, Red: 10.64.2.160, Broadcast: 10.64.2.167
* Configura BGP
** Busca la configuración bgp para 10.64.2.160/29 por si estuviera ya en uso y la borra
** Añade la red 10.64.2.160/29
* Configura la interfaz OSPF
** Borra cualquier configuración de OSPF en la interfaz wLan/Lan
** Añade la interfaz wLan/Lan
* Configura la red OSPF
** Busca la configuración ospf para 10.64.2.160/29 por si estuviera ya en uso y la borra
** Añade la red 10.64.2.160/29 ('''area=backbone''')

<pre>
#
# Radio#: 0 MLGMLGfrjRd1AP0
/interface wireless set wlan1 name="wlan1" \
radio-name="MLGMLGfrjRd1AP0" mode=ap-bridge ssid="guifi.net-MLGMLGfrjRd1AP0" \
band="5ghz" \
frequency-mode=regulatory-domain country=spain antenna-gain=14 \
dfs-mode=radar-detect \
antenna-mode=ant-a wds-mode=static wds-default-bridge=none wds-default-cost=100 \
wds-cost-range=50-150 wds-ignore-ssid=yes hide-ssid=no
:delay 1
# Type: wLan/Lan
/ip address
:foreach i in [find address="10.64.2.161/29"] do={remove $i}
/ ip address add address=10.64.2.161/29 network=10.64.2.160 broadcast=10.64.2.167 interface=wLan/Lan disabled=no
/ routing bgp network
:foreach i in [/routing bgp network find network=10.64.2.160/29] do={/routing bgp network remove $i;}
add network=10.64.2.160/29 disabled=no
/ routing ospf interface
:foreach i in [/routing ospf interface find interface=wLan/Lan] do={/routing ospf interface remove $i;}
add interface=wLan/Lan
/ routing ospf network
:foreach i in [/routing ospf network find network=10.64.2.160/29] do={/routing ospf network remove $i;}
add network=10.64.2.160/29 area=backbone disabled=no
:delay 1
</pre>

* Configura DHCP en '''wLan/Lan'''
** Resetea el pool de ips de dhcp-wLan/Lan
** Añade al pool dhcp-wLan/Lan el rango 10.64.2.166-10.64.2.166
** Elimina los servidores dhcp de dhcp-wLan/Lan
** Añade el servidor dhcp "dhcp-wLan/Lan" a la interfaz wLan/Lan con el pool de ips "dhcp-wLan/Lan" (desactivado por defecto)
** Borra la ip 10.64.2.160/29 del servidor dhcp
** Añade el servidor dhcp la ip 10.64.2.160/29 con gateway 10.64.2.161 (dominio guifi.net)
** dhcp server lease
** '''Borra los comentarios'''
** Reserva una ip en el servidor dhcp "dhcp-wLan/Lan" para el nodo cliente del enlace (IP: 10.64.2.162, MAC: 99:99:99:99:99:9A, ID: ALHFuenteDelPerroRd1)

<pre>
#
# DHCP
:foreach i in [/ip pool find name=dhcp-wLan/Lan] do={/ip pool remove $i;}
/ip pool add name=dhcp-wLan/Lan ranges=10.64.2.166-10.64.2.166
:foreach i in [/ip dhcp-server find name=dhcp-wLan/Lan] do={/ip dhcp-server remove $i;}
/ip dhcp-server add name=dhcp-wLan/Lan interface=wLan/Lan address-pool=dhcp-wLan/Lan disabled=yes
:foreach i in [/ip dhcp-server network find address="10.64.2.160/29"] do={/ip dhcp-server network remove $i;}
/ip dhcp-server network add address=10.64.2.160/29 gateway=10.64.2.161 domain=guifi.net comment=dhcp-wLan/Lan
/ip dhcp-server lease
:foreach i in [find comment=""] do={remove $i;}
:delay 1
add address=10.64.2.162 mac-address=99:99:99:99:99:9A client-id=ALHFuenteDelPerroRd1 server=dhcp-wLan/Lan
#
:delay 1
</pre>

* Busca la 10.64.2.193/27 y la borra
* Configura la interfaz "wlan1" con ip 10.64.2.193/27, red 10.64.2.192 y broadcast 10.64.2.223
* Configura BGP
** Borra la ip 10.64.2.192/27
** Añade la red 10.64.2.192/27
* Configura la interfaz OSPF
** Borra OSPF de la interfaz wlan1
** Añade la interfaz wlan1
* Configura la red OSPF
** Borra la red 10.64.2.192/27 de OSPF
** Añade la red 10.64.2.192/27 ('''area=backbone''')

<pre>
# Type: wLan
/ip address
:foreach i in [find address="10.64.2.193/27"] do={remove $i}
/ ip address add address=10.64.2.193/27 network=10.64.2.192 broadcast=10.64.2.223 interface=wlan1 disabled=no
/ routing bgp network
:foreach i in [/routing bgp network find network=10.64.2.192/27] do={/routing bgp network remove $i;}
add network=10.64.2.192/27 disabled=no
/ routing ospf interface
:foreach i in [/routing ospf interface find interface=wlan1] do={/routing ospf interface remove $i;}
add interface=wlan1
/ routing ospf network
:foreach i in [/routing ospf network find network=10.64.2.192/27] do={/routing ospf network remove $i;}
add network=10.64.2.192/27 area=backbone disabled=no
:delay 1
</pre>

* Configura DHCP en '''wlan1'''
** Resetea el pool de ips de dhcp-wlan1
** Añade al pool dhcp-wlan1 el rango 10.64.2.199-10.64.2.222
** Elimina los servidores dhcp de dhcp-wlan1
** Añade el servidor dhcp "dhcp-wlan1" a la interfaz wlan1 con el pool de ips "dhcp-wlan1" ('''activado''' por defecto)
** Borra la ip 10.64.2.192/27 del servidor dhcp
** Añade el servidor dhcp la ip 10.64.2.192/27 con gateway 10.64.2.193 (dominio guifi.net)
** dhcp server lease
** '''Borra los comentarios'''

<pre>
#
# DHCP
:foreach i in [/ip pool find name=dhcp-wlan1] do={/ip pool remove $i;}
/ip pool add name=dhcp-wlan1 ranges=10.64.2.199-10.64.2.222
:foreach i in [/ip dhcp-server find name=dhcp-wlan1] do={/ip dhcp-server remove $i;}
/ip dhcp-server add name=dhcp-wlan1 interface=wlan1 address-pool=dhcp-wlan1 disabled=no
:foreach i in [/ip dhcp-server network find address="10.64.2.192/27"] do={/ip dhcp-server network remove $i;}
/ip dhcp-server network add address=10.64.2.192/27 gateway=10.64.2.193 domain=guifi.net comment=dhcp-wlan1
/ip dhcp-server lease
:foreach i in [find comment=""] do={remove $i;}
:delay 1
#
:delay 1
</pre>

* Eliminar todas las interfaces wds existentes ('''master-interface=wlan1''')

<pre>
# Type: wds/p2p
# Eliminar todas las interfaces wds existentes
:foreach i in [/interface wireless wds find master-interface=wlan1] \
do={:foreach n in [/interface wireless wds get $i name] \
do={:foreach inum in [/ip address find interface=$n] \
do={/ip address remove $inum;};}; \
/interface wireless wds remove $i;}
#
:delay 1
</pre>

* Configura NAT
** Busca y borra los rangos 172.16.0.0/12 y 192.168.0.0/16 del NAT
** Configura NAT (chain srcnat), dirección fuente: 192.168.0.0/16, dirección destino: !192.168.0.0/16, acción: src-nat, a la dirección: 10.64.2.161

<pre>
#
# Routed device
#
# Otra conexiones cableadas
#
# NAT de direcciones internas
:foreach i in [/ip firewall nat find src-address="172.16.0.0/12"] do={/ip firewall nat remove $i;}
:foreach i in [/ip firewall nat find src-address="192.168.0.0/16"] do={/ip firewall nat remove $i;}
/ip firewall nat
add chain=srcnat src-address="192.168.0.0/16" dst-address=!192.168.0.0/16 action=src-nat to-addresses=10.64.2.161 comment="" disabled=no
</pre>

* Borra todos los filtros en ospf-in, ospf-out
* Borra todos los filtros en ebgp-in, ebgp-out
* Configura ebgp
** Define ebgp-in como la fuente preferida
** Solo acepta rutas 10.x de peers BGP
** Solo envía rutas 10.x a peers BGP
* Configura ospf
** Solo acepta rutas 10.x y 172.x de vecinos OSPF
** Solo envía rutas 10.x y 172.x a vecinos OSPF

<pre>
#
# Enrutamiento BMP
# Filtros BGP & OSPF
:foreach i in [/routing filter find chain=ospf-in] do={/routing filter remove $i;}
:foreach i in [/routing filter find chain=ospf-out] do={/routing filter remove $i;}
:foreach i in [/routing filter find chain=ebgp-in] do={/routing filter remove $i;}
:foreach i in [/routing filter find chain=ebgp-out] do={/routing filter remove $i;}
/ routing filter
add chain=ebgp-in comment="0. Set ebgp-in preferred source." set-pref-src="10.64.2.161" disabled=no
add action=discard chain=ebgp-in comment="1. Discard insert non 10.x routes from BGP peer" disabled=no invert-match=no prefix=!10.0.0.0/8 prefix-length=8-32
add action=discard chain=ebgp-out comment="2. Discard send non 10.x routes to BGP peer" disabled=no invert-match=no prefix=!10.0.0.0/8 prefix-length=8-32
add action=accept chain=ospf-in comment="3. Accept insert 10.x routes from OSPF neighbor" disabled=no invert-match=no prefix=10.0.0.0/8 prefix-length=8-32 set-pref-src="10.64.2.161"
add action=accept chain=ospf-in comment="4. Accept insert 172.x routes from OSPF neighbor" disabled=no invert-match=no prefix=172.16.0.0/12 prefix-length=8-32
add action=discard chain=ospf-in comment="5. Discard insert non 10.x and 172.x from OSPF neighbor" disabled=no invert-match=no
add action=accept chain=ospf-out comment="6. Allow send 10.x routes to OSPF neighbor" disabled=no invert-match=no prefix=10.0.0.0/8 prefix-length=8-32
add action=accept chain=ospf-out comment="7. Allow send 172.x routes to OSPF neighbor" disabled=no invert-match=no prefix=172.16.0.0/12 prefix-length=8-32
add action=discard chain=ospf-out comment="8. Discard send non 10.x and 172.x to OSPF neighbor" disabled=no invert-match=no
</pre>

* Configura BGP
** Nombre por defecto: default
** AS: 43337
** Router ID: 10.64.2.161
** Le aplica los filtros ebgp-in y ebgp-out
** Otros detalles de BGP
* Configura OSPF
** Router ID: 10.64.2.161
** '''redistribute-bgp=as-type-1'''
* Guarda en el log que el script ha finalizado

<pre>
#
# instancia BGP
/ routing bgp instance
set default name="default" as=43337 router-id=10.64.2.161 \
redistribute-connected=yes redistribute-static=yes redistribute-rip=yes \
redistribute-ospf=yes redistribute-other-bgp=yes out-filter=ebgp-out \
client-to-client-reflection=yes comment="" disabled=no
#
# Enrutamiento OSPF
/routing ospf set router-id=10.64.2.161 distribute-default=never redistribute-connected=no \
redistribute-static=no redistribute-rip=no redistribute-bgp=as-type-1
#
:log info "Unsolclic for 43337-MLGforjaRd1 executed."
/
</pre>

[[Categoría:Unsoloclic|RouterOS]]

Fibra óptica

2015-02-04T01:48:33Z

Al: /* Cómo iniciar administrativamente un proyecto de fibra óptica de Guifi.net */

La '''fibra óptica''' es un [[medio de transmisión]] de datos digitales. Físicamente se trata de un hilo muy fino de material transparente y económico como vidrio o materiales plásticos por el que se envían pulsos de luz que representan los datos a transmitir. La fuente de luz puede ser [[láser]] o un [[LED]].

La [[velocidad de datos]] transmitidos por fibra se miden en [[Gigabit por segundo]], siendo actualmente el medio de transmisión de datos digitales más rápido. Son el medio de transmisión por excelencia al ser inmune a las interferencias electromagnéticas. Se utiliza en kilométricos cables submarinos que unen internet y también se utilizan para cortas redes locales.

En Guifi.net el despliegue de fibra óptica consta de dos retos, el tecnológico, fácilmente asumible con unas base de conocimientos técnicos, y, el mayor, el administrativo.

= Cómo iniciar administrativamente un proyecto de fibra óptica de Guifi.net =
Para iniciar un proyecto de fibra óptica de Guifi.net has de
# identificar el territorio por donde desplegarás la fibra
# reunirte con organizaciones y personas de la zona que fácilmente apoyarían el proyecto incluso económicamente (empresas locales, asociaciones de vecinos,...)
# tener en cuenta en qué ubicación o ubicaciones conectarías el territorio con el resto de internet (buscar mucho ancho de banda o, de ser posible, a un punto de fibra de Guifi.net)
# identificar, si es posible (por ejemplo, con acceso a los datos públicos de urbanismo del ayuntamiento, de tenerlos), las canalizaciones subterráneas o aéreas por dónde desplegarías la fibra
# con el conjunto de datos recabados anteriormente redactar un proyecto a presentar al ayuntamiento, por ejemplo al concejal de urbanismo. '''Importante: incorporar en el proyecto los tubos, arquetas, etcétera que la propiedad se la queda el instalador de Guifi.net sin cederlo a ningun operador'''<ref>http://guifi.net/ca/node/30425#comment-28625</ref>
# según la nueva ley estatal que regula el [http://www.lamoncloa.gob.es/ConsejodeMinistros/Referencias/_2013/refc20130913.htm#Telecomunicaciones despliegue de redes de telecomunicaciones], el proyecto será aprobado y podrás pasar al despliegue técnico
# Finalmente se firma el convenio con el ayuntamientos (o la institución pública pertinente) donde a '''cambio de que cedan gratuitamente los conductos nos comprometemos a que la red sea abierta y con ello beneficie a todos los vecinos''', que son los propietarios reales y quienes de verdad pagamos las obras públicas con nuestros impuestos, para que puedan conectarse sin discriminaciones.<ref>http://guifi.net/ca/node/30425#comment-28625</ref>

== Algunos ejemplos de proyectos enviados a ayuntamientos ==
''Los estamos buscando, si tienes un proyecto de éxito, por favor, ¡[[Especial:SubirArchivo|súbelo]]!''
* [http://guifi.net/es/node/23288 Descripción del primer tramo de fibra en Gurb (FFTF)]

== Algunos ejemplos de convenios firmados a ayuntamientos ==
''Los estamos buscando, si tienes un proyecto de éxito, por favor, ¡[[Especial:SubirArchivo|súbelo]]!''

== Estimaciones económicas ==
En zonas rurales pero dispersas con masias aisladas, estamos calculando que como mucho cuesta 3K€ por vivienda, lo que amortizado a 12 años y su mantenimiento son 24€/mes<ref>http://guifi.net/ca/node/30425#comment-28625</ref>.

=== Desglosado ===
* 4 km de cable multifibra a 2 €/m : 8.000 €
* 4 km de cable de dos fibras a 0,5 €/m : 2.000 €
* Rack, switches, conectores... : 10.000 €
* 20 sangrados a 250 € : 5.000 €<ref>http://guifi.net/ca/node/30425#comment-28662</ref>

= Conocimientos técnicos =

[[Archivo:6504773967_6733d231aa_b.jpg|thumb|right|200px|Tubo con 720 fibras]]

== Descripción ==
'''Tipos de empalmes en fibra óptica'''
* Soldadura de fusión
* Mecánicos con conectores ópticos de precisión

'''Parámetros de catalogación de fibra óptica'''
* Atenuación (dB/km)
* Dispersión

'''Tipos de fibra'''
* Monomodo
* Multimodo
** Grados de fibra multimodo: OM1, OM2 y OM3. Ver norma ISO/IEC11801<ref>[http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=36491 ISO/IEC 11801:2002] (PDF de pago)</ref>

'''Tipos de servicio'''
* Fibra iluminada. Servicio de transmisión de datos, de conectividad. El contratante no hace falta que tenga los equipos necesarios para la comunicación, ya que estos los gestiona el dueño de la fibra óptica<ref>[http://wikitel.info/wiki/Fibra_iluminada Fibra iluminada], Wikitel</ref>
* Fibra oscura. Servicio de alquiler de fibra óptica operada por un operador externo y permite interconectar equipos como si fuera un cable. El contratante debe tener los equipos necesarios para la comunicación, ya que el dueño de la fibra óptica solo la alquila<ref>[http://wikitel.info/wiki/Fibra_oscura Fibra oscura], Wikitel</ref>

'''Más conceptos'''
* [[PON]] (Redes Ópticas Pasivas, del inglés Passive Optical Network). Red punto-multipunto sin elementos activos entre servidor y cliente. Sustituyen tramos de cable coaxial por fibra óptica monomodo y divisores eléctricos (splitters) por divisores ópticos. De esta manera se reduce la inversión y los costes de mantenimiento<ref>[http://wikitel.info/wiki/PON PON], Wikitel</ref>
* [[GPON]] (Gigabit-capable PON), son un tipo de arquitectura de red óptica pasiva (PON) que alcanza velocidades de Gbps (ofrece tasas de transferencia de hasta 1,25 Gbps en caudales simétricos y hasta 2,5 Gbps en caudales asimétricos)<ref>[http://wikitel.info/wiki/GPON GPON], Wikitel</ref>
* [[WDM]] (Wavelength Division Multiplexing). Técnica para multiplexar y poder usar longitudes de onda diferentes sobre una misma fibra
* [[Módulo OLT]] (Unidad Óptica Terminal de Línea, del inglés Optical Line Terminal). Dispositivo que transforma señales eléctricas en señales ópticas, usado principalmente en los proveedores de servicios<ref>[http://en.wikipedia.org/wiki/Optical_line_termination OLT]</ref>
* [[Módulo ONU]] (Unidad Óptica de Usuario, del inglés Optical Network Unit). Dispositivo que transforma señales ópticas en señales eléctricas, usado principalmente en la casa de los usuarios finales
* [[Módulo ONT]] (Únidad Óptica de Red, del inglés Optical Network Terminal). Dispositivo ONU que concretamente sirve a un solo usuario final
* [[Divisor óptico o splitter]]. Multiplexan la fibra óptica y permite ramificar la red<ref>[http://wikitel.info/wiki/Divisor_%C3%B3ptico Divisor Óptico], Wikitel</ref>

=== Red PON ===
Una red PON precisa los siguientes componentes:
* Módulo OLT (uno, en el nodo central)
* Divisores ópticos (tantos como queramos para expandir la red)
* Módulos ONU (tantos como viviendas)

La transmisión se realiza entre OLT y ONU usando dos longitudes de onda diferentes y superpuestas (mediante técnicas WDM), una para cada canal (ascendiente (ONU->OLT) y descendiente (OLT->ONU), subida y bajada). Para luego separar ambas longitudes de ondas es necesario usar unos filtros ópticos específicos.

GPON es una recomendación definida en la familia G.984 aprobada por el ITU-T en 2004. La familia de recomendaciones G.984 comprende G.984.1, G.984.2, G.984.3 y G.984.4<ref>[http://en.wikipedia.org/wiki/G.984 G.984]</ref>.

== Fibra óptica de Guifi.net ==
A día de hoy Guifi.net ha desplegado dos tramos de fibra óptica. Ambos se encuentran en la provincia de Barcelona. uno en Gurb<ref>[http://guifi.net/node/23288 Guifi.net: Descripción del primer tramo de fibra en Gurb (FFTF)]</ref> y otro en Taradell<ref>[http://guifi.net/fibraopticataradell Guifi.net: Posant Fibra Òptica a Taradell 13/11/2010]</ref><ref>[http://guifi.net/ca/taradellfibraoptica Guifi.net: Il·luminada la Fibra Òptica de guifi.net a Taradell]</ref><ref>[http://guifi.net/image/tid/249 Galería de fotos: Fibra Òptica a Taradell]</ref>.

=== Gurb ===
Operativa desde 2009. Tiene una velocidad teórica de 1Gbps.

El tendido es principalmente aéreo, usando los palos de la línea de cobre de Telefónica ya existentes, algunas fachadas y algún tramo sepultado.

Proporciona conexión a varias masías de Gurb y está conectada con la fibra óptica de la Generalitat de Cataluña.

=== Taradell ===
Operativa desde el 15 de noviembre de 2010. Tiene una velocidad teórica de 100Mbps (velocidad real de 98Mbps).

Une punto a punto [[Gaufix.net]] con el Instituto de Educación Secundaria de Taradell.

En los extremos hay cajas de conexión para facilitar la expansión de la fibra óptica con enlaces a otros puntos

=== Sant Bartomeu del Grau ===
Operativa desde el 22 de febrero de 2012. Tiene una velocidad teórica de 1Gbps y une ''Telecentre'' con ''Torre''.<ref>https://twitter.com/#!/gaufix/status/172381871932579840</ref>

== Convenios de uso de fibra óptica ==
En agosto de [[2010]], Guifi.net firma un convenio con la Generalitat de Cataluña para llevar la fibra óptica a zonas rurales<ref>[http://blogs.guifi.net/rroca/2010/08/03/guifi-net-signa-un-conveni-amb-la-generalitat-per-estendre-fibra-optica-en-zones-rurals/ Guifi.net signa un conveni amb la Generalitat per estendre fibra òptica en zones rurals]</ref>. Este tramo va desde el punto neutro [[CATNIX]] en Girona hasta [[Gurb]].

= Preguntas frecuentes =
* ¿Qué hay que hacer para optar al [[Glosario#M|MARCo]] de Telefónica?<ref>[https://lists.guifi.net/pipermail/guifi-instal/2011-October/000791.html Preguntas Conductos de telefonica], guifi-instal</ref>
** Es necesario ser un operador de telecomunicaciones inscrito en el registro de operadores de la CMT (se recomienda hacerlo en nombre de la [[Fundación Guifi.net]] y bajos las condiciones de la XOLN). Es importante aclarar que el marco sólo se aplica cuando el conducto sea de Telefónica. Como operador público podemos pedir compartirlo (como privados no). Tener en cuenta también que la mayoría de los conductos no son de Telefónica sino de los Ayuntamientos.<ref>https://lists.guifi.net/pipermail/guifi-instal/2011-October/000792.html</ref><ref>https://lists.guifi.net/pipermail/guifi-instal/2011-October/000797.html]</ref>

= Referencias =
<references/>

= Véase también =
* Documento que recoge la propuesta de cesión del uso de la antigua fibra óptica de Caixa Laietana en [[Mataró]]: [[Archivo:Propuesta fibra Caixa Laietana Diciembre 2012.odt]]

= Enlaces externos =
* [[wikipedia:es:Fibra óptica|Fibra óptica]] en Wikipedia español
* [http://www.movistar.es/on/onTOFichaProducto?ficha=3&v_producto=64049&v_idioma=es&v_segmento=AOPN&v_pestania=3 Oferta de Acceso a Registros y Conductos (MARCo)], movistar.es
* [http://www.ftthcouncil.eu/ FTTH Council Europe]
* [http://en.wikipedia.org/wiki/Fiber_to_the_x FTTx]
* [http://wikitel.info/wiki/UA-Redes_PON_GPON_derivados UA-Redes PON GPON derivados], Wikitel
* [http://www.flickr.com/photos/11370436@N04/ Galería de Groupe Aménagement Numérique des Territoires], Flickr

; Empresas
* [http://www.optral.es/ Optral]
* [http://www.telnet-ri.es/ Telnet]
** [http://www.telnet-ri.es/fileadmin/user_upload/hojas_producto/CABLES_FO/06_PKCP.pdf Cable de Fibra Óptica anticazadores aéreo PKCP]

[[Categoría:Fibra óptica]]

[[ca:fibra òptica]]

Enrutamiento

2014-04-07T13:20:05Z

Al:

Hay que tener cuidado al crear un enlace entre supernodos si escogemos OSPF o BGP, pues pueden surgir problemas de rutas. Ver [http://ca.wiki.guifi.net/wiki/Discussi%C3%B3:Enrutament Discusión] de este hilo en catalán, la opinión de Joan Gaudes.

* [[BATMAN-adv]]
* [[BMX]]
* [[BGP]]
* [[OSPF]]

== Véase también ==
* [http://www.cepes.org.pe/apc-aa/archivos-aa/1e60354f4717edb9fb793dbc5219499d/Enrutamiento_IP_E5F6A.doc conceptos básicos de enrutamiento]
* [[Guaita.py]], script de localización de "Pollo de Rutas"

[[Categoría:Enrutamiento]]
[[Categoría:Red]]

[[ca:Enrutament]]

Criterios de asignación de direcciones IPv6

2014-03-17T02:57:05Z

Al:

Actualmente, la gran mayoría de nodos de la red Guifi.net sólo funcionan bajo [[IPv4]]. Una excepción son algunos de los nodos [[mesh]], que funcionan con el firmware [[Libre-mesh]], [[Altermesh]] y [[qMp]]<ref>[[qMp]] utiliza actualmente únicamente IPv6 [[ULA]], mientras que [[Altermesh]] utiliza IPv6 globales de [[Librenet6]]</ref> ya que éstos configuran el uso de IPv6 por defecto.

La migración se tendrá que hacer obligatoriamente en un futuro, es a la vez algo delicado que supone un reto y un deseo. Esta migración requiere un estudio de la topología de la red y una nueva política de asignación de rangos IPv6 para los nodos y las zonas. Una vez definida la política, habría que continuar con la adaptación de la utilidad [[unsoloclic]] para soportar la configuración automática de los nodos. Por último, hay que proporcionar un mecanismo sencillo para que los administradores de nodos puedan o bien mantener en convivencia IPv4 e IPv6 o actualizar a IPv6 sin perder conectividad.

La web de http://guifi.net en cambio, sí que es accesible a través de [[IPv6]].

== Propuestas y desarrollo actual ==
La propuesta pública inicial<ref>Proyecto propuesto en el [http://bcnproject.com/forums/topic/modificar-la-interfaz-web-de-guifi-net-para-que-otorgue-rangos-ipv6/ Catalunya Dades Weekend]</ref> es que estas IPs sean IPv6 globales basadas en las IPv4 actualmente distribuidas (por ejemplo utilizando los dígitos de IPv4 como los cuatro últimos grupos de cuatro dígitos hexadecimales de IPv6), así la migración no resulta traumática.

=== Propuesta inicial en proceso de aceptación ===
En la propuesta inicial el desarrollo utiliza un <code>/40</code> del rango IPv6 de guifi.net <code>2a00:1508:0a00::/40</code> (equivalente a 1/256 parte del rango total que dispone Guifi.net en IPv6, que es <code>2a00:1508::/32</code>).

La conversión de IPv4 de Guifi.net a IPv6 se hacía a partir de esta fórmula: https://gitorious.org/guifi/drupal-guifi/commit/17f15de8f105410e22cd7ec52e752207d103f16a

(Nótese que el último grupo <code>0a00</code> equivale en hexadecimal al <code>10.</code> por el que se inician todas las direcciones IPv4 de guifi.net).

El resultado en test de dicha fórmula es accesible en http://guifi.gfi (actualmente sólo desde dentro de la red de guifi IPv4, precisamente hasta que arreglemos este asunto).

=== Desarrollo alternativo desechado ===
En el desarrollo alternativo la propuesta pretenía utilizar tan sólo el que otorga [[Código Sur]] a [[Librenet6]]: <code>2a00:1508:1:f000::/52</code>. Entran 4096 x /64. Por lo tanto es insuficiente. Se desarrolla aquí como archivo histórico

Es decir los tres primeros grupos y el primer dígito del cuarto grupo sería fijo.

El resto de los dígitos hexadecimales de IPv6 irían rellenados con los siguientes datos:
==== Para nodos de Libre-mesh ====
Librenet6 IPv4adaptCIDR-16MAC
2a00:1508:1:ffff:ffff:xxxx:xxxx:xxxx/64

Se aprovechan todos los dígitos de la siguiente manera:
* <code>fff:fff</code> adaptación a hexadecimal de los tres últimos octetos (''bytes'') de la IPv4 de Guifi.net (el primer octeto es el 10 o el 172 y se puede eludir).
* <code>f</code> CIDR menos 16: adaptación a hexadecimal de la máscara, se le resta 16 para que quepa en un sólo digito hexadecimal (la máscara en guifi.net siempre es mayor de 16).
* <code>xxxx:xxxx:xxxx</code> dirección [[MAC]] de la interfaz de red. Al ponerla completa nos garantizamos que sea siempre un número único, que sepamos la MAC completa del router a partir de la su IP.
* <code>/64</code> la máscara siempre es un /64

Esta propuesta necesita unos cuantos ajustes para que realmente quepan todos los nodos.

==== Para clientes de esos nodos ====
Los clientes que cuelgan de esos nodos tendrán la siguiente representación, basada en la anterior:
Librenet6 IPv4adapt MAC
2a00:1508:1:ffff:xxxx:xxxx:xxxx:xxxx/64

== IPv6 en otras comunidades inalámbricas ==
La comunidad inalámbrica italiana [[Ninux.org]] publicó un documento con instrucciones para implantar y migrar sus nodos a IPv6.{{cita requerida}}

== Véase también ==
* [[Criterios de asignación de direcciones IPv4]]
* [[IPv6]]
* [[Unsoloclic]]

== Notas ==
Nota: Las zonas [[Libre-mesh]] que están funcionando en el ámbito territorial de guifi.net están utilizando IPv6 no ruteadas globalmente en período de prueba de implementación de esta forma de atribución de IPv6.

== Referencias ==
<references />

== Enlaces externos ==
* http://blog.ninux.org/2012/08/30/ipv6-in-free-networks/
* http://www.codigosur.org/article/ipv6-en-redes-libres-la-experiencia-de-ninux/

[[Categoría:IPv6]]

Abrir redes tipo mesh a través de Guifi.net

2014-03-10T00:35:09Z

Al: /* Agregar un dispositivo */

[[File:GSF-logo.png|right]]
[[File:Qmp_small.png|right|200px]]
Este manual explica cómo integrar con Guifi.net las redes mesh (también conocidas como [[MANET]] y entendidas como redes que funcionan con protocolos de enrutamiento dinámico cómo [[B.A.T.M.A.N.-adv]], [[BMX6]] u [[protocolos de enrutament dinámico|otros]]) de forma que se intercambian datos con el resto de la red libre a través de [[IPv4]].

El manual se basa en la manera de dar de alta los nodos mesh en la web de Guifi.net.

Originalmente, en [[Guifi.net]], para realizar este tipo de redes, se utilizaba un software/firmware desarrollado por la comunidad del barrio de Gràcia de Barcelona, [[GSF|Gràcia Sense Fils (GSF)]].

Actualmente, se utiliza habitualmente el software desarrollado en el proyecto [[Quick_Mesh_Project|Quick Mesh Project (qMp)]].

Desde junio de 2013 se han aplicado unos pequeños cambios para adaptar la web mejor a les redes Mesh, concretamente con [[Quick_Mesh_Project|qMp]].

Ahora, ya no hay tipos de zonas (ad-hoc, infraestructura) y lo que hay es un nuevo tipo de radio "Mesh".

Además, para poder realizar una mejor agregación IP en las zonas, se define un nuevo tipo de direcciones IP "Mesh", que es la que se asigna a los dispositivos con estas radios.

== Crear una nube Mesh ==

La finalidad de crear una nube Mesh es permitir agrupar los nodos que se conectarán a este tipo de redes, y reservar y asignar direcciones IP en la web sólo para estos nodos.

=== Crear una nueva zona ===

Se puede crear una nueva zona en la web siguiendo estos [[Zona|pasos para configurarla]], o bien utilizar una existente.

=== Agregar un rango IP ===

Lo más importante de todo, es agregar un nuevo direccionamiento IP de tipo Mesh en la zona, sea nueva o no, para que se puedan asignar IPs a los dispositivos que se conecten en Mesh.

[[File:MeshNetwork1.png|Afegir un rang nou]]

=== Limitaciones actuales ===

* La web '''no permite realizar búsquedas de rangos IPs de tipo Mesh'''.
** Se tiene que utilizar la herramienta de [http://guifi.net/es/guifi/menu/ip/ipsearch/10.1.%2525 búsqueda de direcciones IP] para ver los rangos disponibles.
** Se tiene que agregar manualmente la IP base de red y la máscara.
* La web '''no distingue si un rango IP está en uso''' si no se agrega exactamente la misma dirección y máscara.
:''P.ej. Si se agrega una red 10.1.4.0/24, lo permite, a pesar de que el rango 10.1.0.0/21 esté asignado previamente (sólo lo evitaría si intentamos agregar 10.1.0.0/21 de nuevo).''

== Conectarse a una red Mesh ==

Para conectarse a una de las redes Mesh con qMp existentes a Guifi.net, primero hay que seguir los [[Tres_pasos|"tres pasos para unirse a Guifi.net"]]; es decir:
# Registrarse en la web
# Crear un nodo
# Agregar un dispositivo

=== Agregar un dispositivo ===

* Primero es necesario seleccionar el modelo de dispositivo, concretamente uno de los [http://qmp.cat/projects/qmp/wiki/Devices soportados (en)] por qMp.
* A diferencia de otras redes de Guifi.net, para enlazar y conectar a una red Mesh, al crear un dispositivo nuevo tiene que agregarse '''una radio de tipo "Mesh"'''.

[[File:MeshRadio1.png|Añadir una radio para enlazar en Mesh]]

* Una vez agregada la radio se tienen que configurar los siguientes parámetros:
** '''MAC''': aquí hay que agregar el [http://es.wikipedia.org/wiki/BSSID BSSID] que se utilice en la zona Mesh donde se quiere conectar. Normalmente con qMp se utiliza <code>02:CA:FF:EE:BA:BE</code> y con [[Libre-mesh]] se utiliza <code>CA:FE:00:C0:FF:EE</code>
** '''SSID''': identificador Wifi de tu dispositivo. Se pide por favor <code>[nube]-[CIUDAD][calle][numero]-[ubicacion]</code> donde <code>[CIUDAD][calle][numero]</code> es exactamente igual al [[Convenciones de nombres#Nodos|nombre del nodo]] en la web de Guifi para ser reconocido fácilmente al hacer un scan.
***<div style="font-size:85%;">[[Convenciones de nombres|Más info sobre las convenciones de nombres]].</div>
***<div style="font-size:85%;">[[:ca:Annex:codis de núvols mesh|Listado de códigos de nubes mesh]].</div>
** '''Protocolo''': normalmente se utilizan enlaces a 5GHz, ya sean '''802.11a''' o '''más habitualmente 802.11n''' en dispositivos nuevos.
** '''Canal''': el número de canal Wifi con el que enlazan las antenas en una zona Mesh. ''Hay que colocarlo bien, ya que cada zona utiliza uno (o varios) diferentes''.
* Se asignará automáticamente un rango de direcciones IP /27 que serán las que el router/antena tendrá disponibles para comunicarse y para asignar a los dispositivos finales (ordenadores, móbiles, etc.).

[[File:MeshRadio2.png|Parámetros de la radio para enlazar en Mesh]]

* Finalmente, se tendrá que instalar el software qMp en el dispositivo con los parámetros que se han configurado en la web (BSSID, SSID, Canal, IP, etc.).
** Podéis seguir los pasos de http://es.wiki.guifi.net/wiki/QMP para instalar y configurar qMp.

=== Nodos frontera ===

Un nodo frontera es un nodo que interconecta una red Mesh con el resto de Guifi.net.

Como mínimo son necesarios dos dispositivos, o bien, uno con dos antenas/radios.

Hay dos maneras de montar un nodo frontera:

:1. Nodos frontera sólo con qMp.
: Utilizando el paquete de [[Quagga]] para [[OpenWRT]].

''[Completar]''

:2. Nodos frontera con diferentes dispositivos.
: Podéis ver un tipo de configuración "híbrida" con [[Node_frontera_amb_qMp|qMp y una RB Mikrotik]] con [[Router OS]].

''[Completar]''

=== Limitaciones actuales ===

Actualmente la web de Guifi.net presenta algunas limitaciones para crear y representar las redes Mesh.

* No se puede crear un dispositivo con una radio para Mesh y otra para infraestructura, y a la vez '''reservar un rango IP diferente (Mesh,public)''' para cada una, ya que la interfaz wlan/lan se crea asociada sólo a la primera radio añadida y, luego, sólo se pueden agregar nuevos rangos IP a ésta interfaz.
** Para permitir asignar una (o varias) IP a cada radio/cable se tendrían que hacer cambios más grandes en la web, así como adaptar la BBDD. Cómo no está previsto a corto plazo, de momento, es aconsejable en dispositivos mixtos crear primero la radio Mesh y luego la radio AP, para que la primera sea la asociada a la interfaz wlan/lan, y luego, si se precisa, agregar manualmente IP's del rango "público".

* Si hay '''algún nodo que tiene visión hacia dos redes Mesh''' (p.ej. GSF-Vallcarca, UPC-Sants), automáticamente no se podrá asignar una IP de cada rango, ya que el nodo tendría que estar a la vez en dos subzonas.
** Para solucionar esto, se podría hacer, o bien dejar el nodo en la zona superior (p.ej. Barcelona) y agregar las IP de las Mesh manualmente por un administrador en los diferentes dispositivos; ó bien dejarlo en una zona/nube que tenga rango IP Mesh, y agregar manualmente el rango de la otra Mesh a otro dispositivo.

* De momento, '''no se pueden representar/pintar en el mapa los enlaces Mesh''', ya que, al ser dinámicos, no está implementada la opción en la web.
** Para ver los nodos en un mapa, podéis mirar el que hay integrado en el software qMp dentro del dispositivo.
** O bien, en el mapa de Altermesh, seleccionando qMp.cat en el desplegable (combo box): http://map.qmp.cat/

== Recomendaciones ==
* En lo que respecta al direccionamiento IP, hay un rango reservado en la zona "World", y puede que sea recomendable (aunque sea por claridad) que las diferentes zonas Mesh tengan subrangos de éste.

* Reservar rangos IP de tipo Mesh para las zonas con máscara de al menos /21.

''REVISAR: http://ca.wiki.guifi.net/wiki/Criteris_d%27assignaci%C3%B3_d%27adreces_IPv4(cat)''

== Ver también ==

* [[Quick_Mesh_Project|Quick Mesh Project (qMp)]]
* [[Altermesh]]
* [[Instalación de qMp en RouterStation Pro]]
* [[MonsterBox]]
* [[MANET]]
* [[qMp al Jardí Botànic de Barcelona]]

== Enlaces externos ==

* [http://qmp.cat/ Web del projecte qMp]
* [http://graciasensefils.net/ Gracia Sense Fils]
* [http://guifisants.net/ Guifi Sants]
* [http://poblenousensefils.net/ Poble Nou Sense Fils]

; Listas de correo
* [https://mail.qmp.cat/cgi-bin/mailman/listinfo/qmp-users qmp-users ''(ENG)'']
* [https://mail.qmp.cat/cgi-bin/mailman/listinfo/qmp-dev qmp-dev ''(ENG)'']
* [https://llistes.guifi.net/sympa/info/guifi-mesh guifi-mesh]
* [https://llistes.graciasensefils.net/pipermail/graciasensefils/ gsf usuaris]
* [https://llistes.graciasensefils.net/pipermail/gsf-dev/ <strike>gsf-dev</strike> ''(cerrada)'']
* [https://mail.guifisants.net/cgi-bin/mailman/listinfo/llista guifi sants]

[[Categoría:MANET]]

[[ca:Obrir xarxes tipus mesh a través de Guifi.net]]

IPv6

2014-02-20T21:17:03Z

Al:

{{wikificar|t=20140217134726}}

'''El crecimiento exponencial de Internet, ha hecho que desde los años 80, el agotamiento de las direcciones IPv4 haya sido un tema de preocupación. El agotamiento ya ha llegado y nos encontramos en la era del IPv6.'''

El 31 de Enero del 2011, la IANA (Internet Assigned Numbers Authority), entidad que se encarga de distribuïr las IPs en Internet, asignó los dos últimos bloques /8 (16 millones de IPs) y el 3 de Febrero finalmente se asignaron los últimos 5 bloques de direcciones disponibles a los cinco registros de Internet (Regional Internet Registries o RIR), que tienen delegada la asignación en las cinco regiones administrativas en que se divide el mundo según Internet. Aquí podemos ver cuando los RIR van a agotar definitivamente las Ipv4 disponibles.

En 1999 se preveía que si la red seguía creciendo al ritmo que lo hacía, el numero de IPs se agotaría antes de encontrar una solución al problema, así que se diseñó NAT (Network Address Translation). El concepto de NAT consiste en utilizar una dirección IP enrutable (o un número limitado de direcciones IP) para conectar todas las máquinas a través de la traducción, en la pasarela de internet, entre la dirección interna (no enrutable) de la máquina que se desea conectar y la dirección IP de la pasarela.

Además, el proceso de traducción de direcciones permite a las compañías asegurar la red interna siempre y cuando oculte la asignación de direcciones internas. Para un observador que se ubica fuera de la red, todos los pedidos parecen provenir de la misma dirección IP.

NAT ha podido parecer un gran invento, también una forma de "tener los ordenadores a salvo del salvaje internet". NAT ha sido adoptado como firewall, pero en realidad no lo es ya que se permite que protocolos como UPNP o conexiones inversas puedan acceder a equipos de detrás del NAT.

Sin embargo, este sistema no está facilitando la tarea a todas aquellas aplicaciones tipo cliente-servidor (que ofrecen servicios dedicados a los usuarios), o permitiendo las cliente-cliente, tal como podría ser VoIP, Televisión Interactiva, juegos on-line, programas P2P, etc. Si somos usuarios de estos servicios seguramente alguna vez habremos tenido que acceder a nuestro router y configurar la redirección de puertos. Con IPv6 ¡esta farragosa tarea desaparece! cada ordenador dispone de una ip global y con este motivo, es posible rutearlo directamente a Internet, así que desde hace ya unos años, los sistemas operativos se toman mucho más en serio el tema de la seguridad y por un buen motivo, un sistema o aplicación que no esté preparado para las redes del futuro, ¡estará condenado a desaparecer!

Además de esto nos encontramos con la realidad del imparable crecimiento de internet, que en los últimos 10 años ha experimentado un crecimiento superior al 600%, día tras día se unen a esta gran red nuevos tipos de dispositivos.

== IPv6, el protocolo ==
Este protocolo empezó a ser diseñado en 1996 por la [http://www.ietf.org/ IETF (Internet Engineering Task Force)], organización que desarrolla y promueve estándares sobretodo sobre TCP/IP y protocolos de Internet. Desde entonces IPv6 ha ido evolucionando, pero a diferencia de otros protocolos se decidió no definir versiones, en motivo del farragoso proceso de estandarización de los RFC que hace que muchos estándares se apliquen en la red antes de ser estandarizados, como por ejemplo el polémico 802.11n.

Uno de los cambios que saltan mas a la vista es la notación de las direcciones, que trata de direcciones de 128bits de longitud escritos en 8 grupos de cuatro dígitos hexadecimales:

2001:0db8:85a3:08d3:1319:8a2e:0370:7334

Esto es una dirección IPv6 válida. Usamos el prefijo 2001:0db8: para documentación.
Si un grupo de cuatro dígitos es nulo (que tiene el valor 0000), puede ser comprimido, así que estas dos direcciones IPv6 serían en realidad la misma:

2001:0db8:85a3:0000:1319:8a2e:0370:7344
2001:0db8:85a3::1319:8a2e:0370:7344

Siguiendo esta regla, si más de dos grupos consecutivos son nulos pueden comprimirse como "::". Si la dirección tiene más de una serie de grupos nulos consecutivos, la compresión se puede aplicar en más de uno, así que:

2001:0DB8:0000:0000:0000:0000:1428:57ab
2001:0DB8:0000:0000:0000::1428:57ab
2001:0DB8:0:0:0:0:1428:57ab
2001:0DB8:0::0:1428:57ab
2001:0DB8::1428:57ab

Són todas válidas y representan lo mismo, pero

2001::25de::cade

No es válida porqué no queda claro cuantos grupos nulos hay en cada lado.

Los ceros iniciales en un grupo pueden ser omitidos. Así que:

2001:0DB8:02de::0e13

Es lo mismo que

2001:DB8:2de::e13

== Tipo de direcciones IPv6 ==
* '''Multicast (una a muchas):''' "ff00::/8"
* '''Anycast (una a la más cercana):''' para la réplica de DNS (por ejemplo para hacer peticiones al servidor DNS más cercano topológicamente hablando).
* '''Unicast:'''
** Globales : equivaldrían a lo que conocemos como IPs públicas en IPv4.
** Enlace local (link-local): "fe80::/10" Sólo son válidas a nivel 2, serían como las 169.254.0.0/16 en IPv4. No són enrutables en la red IPv6. Más info.
** Locales únicas (ULA): "fc00::/7" Estas tampoco son enrutables en la red IPv6 y su uso común es para redes privadas virtuales, un ejemplo podría ser el caso de un banco, que tiene sus ordenadores conectados a internet con su IP global, pero el programa de gestión del banco sólo sería accesible desde la ULA. Es habitual pues que un ordenador con IPv6 disponga de varias direcciones IPv6. Más info.
** IPv4 mapeadas: "::ffff:0:0/96" (en desuso)
** Compatible IPv4: (desaprobadas)
** Local de sitio (site-local): (desaprobadas) "fec0::/10" para definir una red interna en un edificio o planta.
** Loopback: "::1/128" el equivalente a la 127.0.0.1/8

== Los rangos de IP ==
IPv6 está diseñado para que cada máquina tenga asignado un rango en lugar de una única IP. Solo en casos muy concretos se aconseja que un dispositivo electrónico tenga una única IP.
El rango mínimo que se debería asignar a una interfaz de red es un /64 (2^64 Ips).
De esta forma puede usarse la MAC address del dispositivo físico para generar una IP válida en esos restantes 64 bits. De esta forma, entre otras cosas se gana privacidad, pues ya no será trivial descubrir la IP de una máquina y escanear el rango entero nos podría costar varios años.

Los RIRs recomiendan a las ISP que entreguen a sus clientes un /48, de esta forma el cliente puede asignar hasta 2^16 /64 a sus dispositivos domésticos (nevera, teléfono, tele, enchufe, persiana...)

Asignando un /48 a cada persona del planeta, suponiendo que estas /48 no se devolviesen, se podría asignar un /48 a cada persona del planeta durante 480 años.
¡Se espera que el protocolo quede obsoleto mucho antes!

== Broadcast y ARP ==
Otro cambio realmente significante es que IPv6 no implemente Broadcast, y por lo tanto no existe broadcast domain.
En su lugar se ha extendido y mejorado el funcionamiento de Multicast. Para comunicar los ordenadores directamente conectados (y sin conocer previamente sus Ips) se puede usar la dirección link-local multicast ff02::1.
En IPv6 ARP ha sido sustituido por un protocolo mucho más potente, NDP (Neighbor Discovery Protocol) que usa ICPMv6 para sus comunicaciones.

Una de las consecuencias de estos dos cambios es que, por ejemplo, se pueden comunicar dos maquinas conectadas sin necesidad de configurar ninguna IP. Las direcciones link-local (fe80::/10), que se configuran automáticamente en nuestro sistema, nos lo permiten.
ssh usuario@ipv6link-local%eth0

Como se puede apreciar la interfaz de red debe ser especificada, ya que si no el kernel no tiene forma de saber hacia donde enviar los paquetes. El ordenador destino verá que la dirección de destinación es su propia IP link-local y aceptará el paquete.

== ULA ==
También funcionaría por las ULA, pero no tiene sentido, ya que aunque no sean enrutables por internet si que pueden serlo dentro de la red local, y en este caso el gateway ya nos enrutaría a la ubicación correcta.

Para añadir una ULA:
ip -6 addr add ULA/64 dev INTERFACE

== El enrutamiento estático ==
El comportamiento de la red en esta versión cambia de forma significativa con la versión anterior, por ejemplo no es usual encontrar configuraciones como la siguiente:

eth0: 192.168.1.1/24
eth1: 192.168.1.10/16

En IPv6 lo habitual es que un mismo rango esté incluido en dos dispositivos de red (uno incluye el otro), el mas pequeño es siempre el que manda. Esta característica fue exportada a IPv4.

2001:0DB8:1006::/64 es mas pequeño que 2001:0DB8:1006:1100::/56

== SLACC (Stateless address autoconfiguration) ==
En IPv6 son los mismos hosts quienes se configuran automáticamente usando el protocolo "Neighbor Discovery Protocol" (NDP) mediante mensajes ICMPv6.
En el momento que estos se conectan a la red, envian al router una solicitud de link-local mediante una petición multicast (router solicitation) pidiendo los parámetros de configuración. Entonces los routers responderán con un paquete "router advertisment" que contiene los parámetros de configuración de la red.

== La cabecera de IPv6 ==
IPv6 incrementa la longitud de la cabecera IP de 20 a 40 bytes. La cabecera IPv6 contiene dos direcciones de 16 bytes (fuente y destino) precedidas de 8 bytes de control. La reducción de la información de control y la eliminación de opciones de la cabecera tienen como fin optimizar el procesamiento del paquete. Los campos de uso poco frecuente se han eliminado de la cabecera y se han pasado a extensiones de cabecera opcionales.

El campo "cabecera siguiente" o "next header", permite añadir nuevos campos en la cabecera sin tener que actualizar el software o el hardware de todos los dispositivos de la red. Y es que IPv6 se ha diseñado para poder implementar nuevos cambios de forma progresiva sin tener que apagar toda la red para aplicarlos.
Más información.

== La asignación de IPs ==
En IPv6 exististe DHCPv6, pero no es la opción recomendada. Para ello tenemos el nuevo protocolo SLAAC.
En el router cabecera activamos el RA y los equipos de la red al conectarse a ella ven el anuncio del router y son ellos mismos quienes se aplican la dirección IP a partir de, por ejemplo, su dirección MAC. En sistemas basados en GNU/Linux siempre se asigna dicha IP a partir de la MAC, pero en otros sistemas existen las llamadas direcciones de privacidad, donde se genera la IP de forma aleatoria.
Para activar IPv6 privacy en GNU/Linux deberemos activar las "IPv6 Privacy Extensions", como root editamos /etc/sysctl.conf y añadimos estas líneas:

net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2

Reiniciamos la red (o la maquina si se resiste al cambio) y entonces, si disponemos de un RA en nuestra red, veremos que nos asigna 2 direcciones IPv6, una basada en nuestra MAC y otra aleatoria. Un ejemplo:

wlan0 Link encap:Ethernet HWaddr 00:21:6a:a5:18:79
inet addr:192.168.1.6 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: 2001:db8:1006:0:221:6aff:fea5:1879/64 Scope:Global
inet6 addr: fe80::221:6aff:fea5:1879/64 Scope:Link
inet6 addr: 2001:db8:1006:0:2c04:41de:e3bc:ffe/64 Scope:Global

De esta forma, las peticiones en una página web aparecen como si se hicieran desde la ip privacy:

Nombre del Ordenador: 2001:db8:1006:0:2c04:41de:e3bc:ffe

Una dirección IP vendrá formada pues, en el caso que tengamos una ip /64, los 64 primeros bits vendrán dados por nuestro proveedor, los últimos 64, se generarán “aleatoriamente”.
Al igual que en IPv4 pues, podremos usar igualmente DHCP (aunque no sería recomendable) o bien definir una IPv6 de forma manual.
La recomendación con IPv6 (y esto es realmente muy importante), seria olvidarse de recordar un montón de direcciones IP y empezar a usar los DNS (Domain Name System), que para esto fueron creados! :)

En los DNS, para asignar una dirección IPv4 usamos el Address Record A, en IPv6 usaremos AAAA, así que al ejecutar una petición de resolución sobre un dominio nos va a devolver las direcciones IPv4 y IPv6 relacionadas. Si nuestra red tiene salida IPv6, la dirección IPv6 será la prioritaria:

$ host guifi.net
guifi.net has address 109.69.8.5
guifi.net has IPv6 address 2a00:1508::5

== El protocolo de movilidad ==
En IPv6 se ha desarrollado un conjunto de protocolos y herramientas de movilidad, que permiten "saltar" de red a red sin perder en ningún momento la conectividad. Por ejemplo, gracias a SLAAC los últimos 64 bits de nuestra IP son fijos (basados en la MAC). Así que si sabemos el prefijo (los primeros 64 bits) de la nueva red donde nos vamos a mover, podemos hacerlo sin perder nunca la conexión.

Por ejemplo, estamos en nuestra casa haciendo una llamada telefónica con nuestro móvil conectado a nuestra wifi y de repente salimos a la calle, fuera del alcance de nuestra wifi y pasamos a la red móvil de nuestro operador telefónico. Gracias a este protocolo podremos realizar dicha llamada telefónica sin ningún corte!

== Extensión IPSec ==
IPv4 se diseñó para ser funcional, no seguro; así que con IPv6 se ha dado un paso adelante en este aspecto. Es la razon por la que se ha implementado IPSec en este protocolo. El uso de IPSec no es obligatorio en IPv6, lo que si que es realmente obligatorio es que todos los dispositivos que soporten IPv6 (y esto sería extensivo para las conexiones end2end), también soporten IPSec, dejando a nuestro libre albedrío la decisión de proteger o no nuestras comunicaciones.
Más información

== Trabajando con IPv6 ==
La primera impresión que tenemos con IPv6 es pensar... ¡qué jaleo! ¡se han vuelto locos! ¡esto es el fin! Pero en realidad migrar una red de IPv4 a IPv6 no es una cosa tan crítica, además de que ambos protocolos pueden convivir perfectamente sin ningún tipo de conflicto! y es que TCP/IP aunque sea el protocolo más extendido no es el único. Posiblemente si analizamos nuestra red y se ha conectado nuestro vecino con su icacharro, podremos ver peticiones del protocolo manzanatalk. Vale que manzanatalk cada vez está más en desuso, pero es el primer protocolo distinto a tcp/ip que nos viene a la cabeza, están otros como netbios, ipx, etc.

Posiblemente nuestro operador de telecomunicaciones no está haciendo su trabajo y en tu casa aún no dispones de IPv6, ¡pero no desesperes! ¡hay opción!
Existen los llamados tunnel brokers, que te permiten realizar tuneles 6to4 (sit). Todos los que he probado requerían IPv4 estática, pero parece que existe ya alguno que también permiten IPv4 dinámica.
Así que vayamos a ver uno de los mas conocidos, el de hurricane electric, que además te ofrece los comandos para hacer un copy-paste en tu consola y disponer al acto de IPv6 :)
Hurricane Electric (tunnelbroker.net)
Esta página requiere registro y también IPv4 estática, pero una vez pasamos estos tramites podemos crear un tunel 6to4 realmente estable.
Una vez logueados vamos a "Create Regular Tunnel", especificamos nuestra dirección IP (si no la ha localizado), escojemos uno de los servidores y le damos a "Create Tunnel".
A continuación nos aparece una página con nuestra configuración IPv6 y en la pestaña example configurations escogemos nuestro sistema operativo (el caso más común Linux-net-tools):

ifconfig sit0 up
ifconfig sit0 inet6 tunnel ::216.66.84.46
ifconfig sit1 up
ifconfig sit1 inet6 add 2001:470:1f14:18b::2/64
route -A inet6 add ::/0 dev sit1

A partir de aquí ya dispondremos de un tunnel IPv6 en nuestra máquina y uno de los siguientes pasos es probar si estamos ya preparados para el mundo IPv6:
http://test-ipv6.com/

Una vez tengamos IPv6 podemos realizar algunas pruebas. Dichas pruebas están hechas desde un servidor de giss.tv (giss.delanit.net), así que a partir de aquí las direcciones IPv6 son reales:
$ host giss.delanit.net
giss.delanit.net is an alias for v-giss.delanit.net.
v-giss.delanit.net has address 109.69.9.56
v-giss.delanit.net has IPv6 address 2a00:1508:1000::6d45:938

=== Configuración IP ===
Éste servidor tiene en eth0 la IPv4 (pública) 108.69.9.56 y la IPv6 (global) 2a00:1508:1000::6d45:938. En eth1 la IPv4 interna de guifi.net. En la interfaz lo nos fijamos que está la ::1 que equivale a la 127.0.0.1.

# ifconfig
eth0 Link encap:Ethernet HWaddr 00:18:51:e6:d6:47
inet addr:109.69.9.56 Bcast:109.69.9.63 Mask:255.255.255.240
inet6 addr: 2a00:1508:1000::6d45:938/64 Scope:Global
inet6 addr: fe80::218:51ff:fee6:d647/64 Scope:Link

eth1 Link encap:Ethernet HWaddr 00:18:51:16:16:17
inet addr:10.138.15.131 Bcast:10.138.15.159 Mask:255.255.255.224
inet6 addr: fe80::218:51ff:fe16:1617/64 Scope:Link

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host

# route -6 -n
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
2a00:1508:1000::/64 :: U 256 0 1 eth0
fe80::/64 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 eth1
::/0 2a00:1508:1000::6d45:901 UG 1024 1 312 eth0
::/0 :: !n -1 1 830 lo
::1/128 :: Un 0 1 31179 lo
2a00:1508:1000::6d45:938/128 :: Un 0 1 21440 lo
fe80::218:51ff:fe16:1617/128 :: Un 0 1 0 lo
fe80::218:51ff:fee6:d647/128 :: Un 0 1 74 lo
ff00::/8 :: 256 0 0 eth0
ff00::/8 :: U 256 0 0 eth1
::/0 :: !n -1 1 830 lo

Al ser un servidor le hemos definido al igual que la IPv4, una IPv6 estática:

[/etc/network/interfaces]
auto lo eth0
iface lo inet loopback
iface eth0 inet static
address 109.69.9.56
netmask 255.255.255.240
gateway 109.69.9.49

iface eth0 inet6 static
address 2a00:1508:1000::6d45:938
netmask 64
up ip r add default via 2a00:1508:1000::6d45:901 dev eth0

Ping
$ ping6 guifi.net
PING guifi.net(2a00-1508--5.ip6.guifi.net) 56 data bytes
64 bytes from v6.guifi.net: icmp_seq=1 ttl=62 time=2.47 ms
64 bytes from 2a00-1508--5.ip6.guifi.net: icmp_seq=2 ttl=62 time=1.96 ms
64 bytes from v6.guifi.net: icmp_seq=3 ttl=62 time=2.08 ms

Traceroute
$ traceroute -6 guifi.net
traceroute to guifi.net (2a00:1508::5), 30 hops max, 80 byte packets
1 2a00:1508:1000::6d45:901 (2a00:1508:1000::6d45:901) 0.183 ms 0.166 ms 0.280 ms
2 2a00:1508:ffff:fffb::21 (2a00:1508:ffff:fffb::21) 2.032 ms 2.034 ms 2.029 ms
3 v6.guifi.net (2a00:1508::5) 2.438 ms 2.430 ms 2.423 ms

Si nos fijamos, estamos usando las típicas herramientas de red, pero le estamos añadiento la opción -6.

De momento, como no todo el mundo dispone de IPv6 en sus servidores, dependemos de IPv4 hasta que poco a poco toda la red vaya migrando a IPv6 (algunos proveedores estiman que el proceso no se completará hasta 2030). Muchos, antes de empezar a mirar Ipv6, nos imaginamos que este cambio puede ser una cosa tan crítica como el más que conocido efecto 2000, en la que nos pensábamos que todo dejaría de funcionar. Pero como todo, es bueno estar preparados antes de que nos pille el tren, y lo más importante es informarse de lo que realmente implica este cambio. En mi humilde opinión ¡a mejor! :)

== Presentes y futuros usos de un internet basado en IPv6 ==
Al igual que cuando se diseñó IPv4, nadie imaginaba que terminaríamos todos con pequeños dispositivos en nuestros bolsillos con una capacidad computacional de varios cientos de veces de la de aquellos antiguos ordenadores de los años 80.
Pero es que en la actualidad somos incapaces de imaginarnos cómo accederemos a internet en el futuro inmediato, con qué dispositivos, cuales serán sus usos... etc. Y es que esta realidad la podemos ver sin tener que ir muchos años atrás. ¿Quién hubiese imaginado hace tan sólo 5 años que lo común sería estar con nuestro teléfono móvil sacando fotos de una cosa que nos gusta en la calle y compartiéndola en tiempo real con cientos de amigos/contactos en la red? Las protestas organizadas simultáneamente a varios puntos del planeta han sido posibles gracias a la evolución de la tecnología.

Cuando tenemos a nuestro alcance la posibilidad de asignar una dirección IP a cualquier dispositivo nos pueden venir a la cabeza algunos de sus usos en modo de ciencia ficción.

Algunos de los usos mas novedosos que se le está dando a IPv6 en la actualidad es en el ámbito de la domótica, casas “inteligentes”, en las cuales podemos controlar con nuestro dispositivo móvil hasta la mas insignificante bombilla. La imaginación se desborda cuando tratamos temas como la seguridad o la reducción de costes energéticos a favor de nuestro bolsillo y del medioambiente.

Otro de los posibles usos que podría tener es por ejemplo para gestionar mucho mejor nuestra agenda. Cada componente electrónico de nuestro coche podría tener su única dirección IP, estar conectado con la base de datos del fabricante y en el momento de que este fallase, el propio coche contactaría con nuestro taller mecánico, pediría la pieza y el coche se coordinaría con nuestra agenda para que, por ejemplo, cuando tengamos que ir a hacer una visita a un cliente, en lugar de aparcar el coche en el párking dejarlo en el taller mecánico más cercano, dónde nos estaría esperando el nuevo recambio.

No tenemos que olvidarnos tampoco de las ventajas que puede aportar IPv6 en el campo de la medicina, para el seguimiento en tiempo real de enfermos los cuales es preciso tener un control exhaustivo de su tratamiento, así como monitorización remota de dispositivos de electromedicina, como los marcapasos, control de la diabétes, etc.

Coches, elementos electrónicos, dispositivos móviles, etc. permanentemente conectados a internet gracias a las nuevas tecnologías móviles como LTE y el diseño de IPv6 de estar permanentemente conectados a cualquier tipo de red sin ningún tipo de corte...
Y es que el futuro ya está aquí, es el presente.

== Véase también ==
* [[Criterios de asignación de direcciones IPv6]]
* [http://www.consulintel.es/Html/ForoIPv6/Documentos/Tutorial%20de%20IPv6.pdf: Tutorial IPv6]

== Enlaces externos ==
;Lecturas recomendadas
http://www.ipv6.es/es-ES/recursos/Paginas/Libros.aspx 
http://www.worldipv6launch.org/ 
http://es.wikipedia.org/wiki/IPv6 
http://www.ipv6.com/

[[Categoría:IPv6]]

[[ca:IPv6]]

IPv6

2014-02-20T21:16:05Z

Al: /* Véase también */

{{wikificar|t=20140217134726}}

'''El crecimiento exponencial de Internet, ha hecho que desde los años 80, el agotamiento de las direcciones IPv4 haya sido un tema de preocupación. El agotamiento ya ha llegado y nos encontramos en la era del IPv6.'''

El 31 de Enero del 2011, la IANA (Internet Assigned Numbers Authority), entidad que se encarga de distribuïr las IPs en Internet, asignó los dos últimos bloques /8 (16 millones de IPs) y el 3 de Febrero finalmente se asignaron los últimos 5 bloques de direcciones disponibles a los cinco registros de Internet (Regional Internet Registries o RIR), que tienen delegada la asignación en las cinco regiones administrativas en que se divide el mundo según Internet. Aquí podemos ver cuando los RIR van a agotar definitivamente las Ipv4 disponibles.

En 1999 se preveía que si la red seguía creciendo al ritmo que lo hacía, el numero de IPs se agotaría antes de encontrar una solución al problema, así que se diseñó NAT (Network Address Translation). El concepto de NAT consiste en utilizar una dirección IP enrutable (o un número limitado de direcciones IP) para conectar todas las máquinas a través de la traducción, en la pasarela de internet, entre la dirección interna (no enrutable) de la máquina que se desea conectar y la dirección IP de la pasarela.

Además, el proceso de traducción de direcciones permite a las compañías asegurar la red interna siempre y cuando oculte la asignación de direcciones internas. Para un observador que se ubica fuera de la red, todos los pedidos parecen provenir de la misma dirección IP.

NAT ha podido parecer un gran invento, también una forma de "tener los ordenadores a salvo del salvaje internet". NAT ha sido adoptado como firewall, pero en realidad no lo es ya que se permite que protocolos como UPNP o conexiones inversas puedan acceder a equipos de detrás del NAT.

Sin embargo, este sistema no está facilitando la tarea a todas aquellas aplicaciones tipo cliente-servidor (que ofrecen servicios dedicados a los usuarios), o permitiendo las cliente-cliente, tal como podría ser VoIP, Televisión Interactiva, juegos on-line, programas P2P, etc. Si somos usuarios de estos servicios seguramente alguna vez habremos tenido que acceder a nuestro router y configurar la redirección de puertos. Con IPv6 ¡esta farragosa tarea desaparece! cada ordenador dispone de una ip global y con este motivo, es posible rutearlo directamente a Internet, así que desde hace ya unos años, los sistemas operativos se toman mucho más en serio el tema de la seguridad y por un buen motivo, un sistema o aplicación que no esté preparado para las redes del futuro, ¡estará condenado a desaparecer!

Además de esto nos encontramos con la realidad del imparable crecimiento de internet, que en los últimos 10 años ha experimentado un crecimiento superior al 600%, día tras día se unen a esta gran red nuevos tipos de dispositivos.

== IPv6, el protocolo ==
Este protocolo empezó a ser diseñado en 1996 por la [http://www.ietf.org/ IETF (Internet Engineering Task Force)], organización que desarrolla y promueve estándares sobretodo sobre TCP/IP y protocolos de Internet. Desde entonces IPv6 ha ido evolucionando, pero a diferencia de otros protocolos se decidió no definir versiones, en motivo del farragoso proceso de estandarización de los RFC que hace que muchos estándares se apliquen en la red antes de ser estandarizados, como por ejemplo el polémico 802.11n.

Uno de los cambios que saltan mas a la vista es la notación de las direcciones, que trata de direcciones de 128bits de longitud escritos en 8 grupos de cuatro dígitos hexadecimales:

2001:0db8:85a3:08d3:1319:8a2e:0370:7334

Esto es una dirección IPv6 válida. Usamos el prefijo 2001:0db8: para documentación.
Si un grupo de cuatro dígitos es nulo (que tiene el valor 0000), puede ser comprimido, así que estas dos direcciones IPv6 serían en realidad la misma:

2001:0db8:85a3:0000:1319:8a2e:0370:7344
2001:0db8:85a3::1319:8a2e:0370:7344

Siguiendo esta regla, si más de dos grupos consecutivos son nulos pueden comprimirse como "::". Si la dirección tiene más de una serie de grupos nulos consecutivos, la compresión se puede aplicar en más de uno, así que:

2001:0DB8:0000:0000:0000:0000:1428:57ab
2001:0DB8:0000:0000:0000::1428:57ab
2001:0DB8:0:0:0:0:1428:57ab
2001:0DB8:0::0:1428:57ab
2001:0DB8::1428:57ab

Són todas válidas y representan lo mismo, pero

2001::25de::cade

No es válida porqué no queda claro cuantos grupos nulos hay en cada lado.

Los ceros iniciales en un grupo pueden ser omitidos. Así que:

2001:0DB8:02de::0e13

Es lo mismo que

2001:DB8:2de::e13

== Tipo de direcciones IPv6 ==
* '''Multicast (una a muchas):''' "ff00::/8"
* '''Anycast (una a la más cercana):''' para la réplica de DNS (por ejemplo para hacer peticiones al servidor DNS más cercano topológicamente hablando).
* '''Unicast:'''
** Globales : equivaldrían a lo que conocemos como IPs públicas en IPv4.
** Enlace local (link-local): "fe80::/10" Sólo son válidas a nivel 2, serían como las 169.254.0.0/16 en IPv4. No són enrutables en la red IPv6. Más info.
** Locales únicas (ULA): "fc00::/7" Estas tampoco son enrutables en la red IPv6 y su uso común es para redes privadas virtuales, un ejemplo podría ser el caso de un banco, que tiene sus ordenadores conectados a internet con su IP global, pero el programa de gestión del banco sólo sería accesible desde la ULA. Es habitual pues que un ordenador con IPv6 disponga de varias direcciones IPv6. Más info.
** IPv4 mapeadas: "::ffff:0:0/96" (en desuso)
** Compatible IPv4: (desaprobadas)
** Local de sitio (site-local): (desaprobadas) "fec0::/10" para definir una red interna en un edificio o planta.
** Loopback: "::1/128" el equivalente a la 127.0.0.1/8

== Los rangos de IP ==
IPv6 está diseñado para que cada máquina tenga asignado un rango en lugar de una única IP. Solo en casos muy concretos se aconseja que un dispositivo electrónico tenga una única IP.
El rango mínimo que se debería asignar a una interfaz de red es un /64 (2^64 Ips).
De esta forma puede usarse la MAC address del dispositivo físico para generar una IP válida en esos restantes 64 bits. De esta forma, entre otras cosas se gana privacidad, pues ya no será trivial descubrir la IP de una máquina y escanear el rango entero nos podría costar varios años.

Los RIRs recomiendan a las ISP que entreguen a sus clientes un /48, de esta forma el cliente puede asignar hasta 2^16 /64 a sus dispositivos domésticos (nevera, teléfono, tele, enchufe, persiana...)

Asignando un /48 a cada persona del planeta, suponiendo que estas /48 no se devolviesen, se podría asignar un /48 a cada persona del planeta durante 480 años.
¡Se espera que el protocolo quede obsoleto mucho antes!

== Broadcast y ARP ==
Otro cambio realmente significante es que IPv6 no implemente Broadcast, y por lo tanto no existe broadcast domain.
En su lugar se ha extendido y mejorado el funcionamiento de Multicast. Para comunicar los ordenadores directamente conectados (y sin conocer previamente sus Ips) se puede usar la dirección link-local multicast ff02::1.
En IPv6 ARP ha sido sustituido por un protocolo mucho más potente, NDP (Neighbor Discovery Protocol) que usa ICPMv6 para sus comunicaciones.

Una de las consecuencias de estos dos cambios es que, por ejemplo, se pueden comunicar dos maquinas conectadas sin necesidad de configurar ninguna IP. Las direcciones link-local (fe80::/10), que se configuran automáticamente en nuestro sistema, nos lo permiten.
ssh usuario@ipv6link-local%eth0

Como se puede apreciar la interfaz de red debe ser especificada, ya que si no el kernel no tiene forma de saber hacia donde enviar los paquetes. El ordenador destino verá que la dirección de destinación es su propia IP link-local y aceptará el paquete.

== ULA ==
También funcionaría por las ULA, pero no tiene sentido, ya que aunque no sean enrutables por internet si que pueden serlo dentro de la red local, y en este caso el gateway ya nos enrutaría a la ubicación correcta.

Para añadir una ULA:
ip -6 addr add ULA/64 dev INTERFACE

== El enrutamiento estático ==
El comportamiento de la red en esta versión cambia de forma significativa con la versión anterior, por ejemplo no es usual encontrar configuraciones como la siguiente:

eth0: 192.168.1.1/24
eth1: 192.168.1.10/16

En IPv6 lo habitual es que un mismo rango esté incluido en dos dispositivos de red (uno incluye el otro), el mas pequeño es siempre el que manda. Esta característica fue exportada a IPv4.

2001:0DB8:1006::/64 es mas pequeño que 2001:0DB8:1006:1100::/56

== SLACC (Stateless address autoconfiguration) ==
En IPv6 son los mismos hosts quienes se configuran automáticamente usando el protocolo "Neighbor Discovery Protocol" (NDP) mediante mensajes ICMPv6.
En el momento que estos se conectan a la red, envian al router una solicitud de link-local mediante una petición multicast (router solicitation) pidiendo los parámetros de configuración. Entonces los routers responderán con un paquete "router advertisment" que contiene los parámetros de configuración de la red.

== La cabecera de IPv6 ==
IPv6 incrementa la longitud de la cabecera IP de 20 a 40 bytes. La cabecera IPv6 contiene dos direcciones de 16 bytes (fuente y destino) precedidas de 8 bytes de control. La reducción de la información de control y la eliminación de opciones de la cabecera tienen como fin optimizar el procesamiento del paquete. Los campos de uso poco frecuente se han eliminado de la cabecera y se han pasado a extensiones de cabecera opcionales.

El campo "cabecera siguiente" o "next header", permite añadir nuevos campos en la cabecera sin tener que actualizar el software o el hardware de todos los dispositivos de la red. Y es que IPv6 se ha diseñado para poder implementar nuevos cambios de forma progresiva sin tener que apagar toda la red para aplicarlos.
Más información.

== La asignación de IPs ==
En IPv6 exististe DHCPv6, pero no es la opción recomendada. Para ello tenemos el nuevo protocolo SLAAC.
En el router cabecera activamos el RA y los equipos de la red al conectarse a ella ven el anuncio del router y son ellos mismos quienes se aplican la dirección IP a partir de, por ejemplo, su dirección MAC. En sistemas basados en GNU/Linux siempre se asigna dicha IP a partir de la MAC, pero en otros sistemas existen las llamadas direcciones de privacidad, donde se genera la IP de forma aleatoria.
Para activar IPv6 privacy en GNU/Linux deberemos activar las "IPv6 Privacy Extensions", como root editamos /etc/sysctl.conf y añadimos estas líneas:

net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2

Reiniciamos la red (o la maquina si se resiste al cambio) y entonces, si disponemos de un RA en nuestra red, veremos que nos asigna 2 direcciones IPv6, una basada en nuestra MAC y otra aleatoria. Un ejemplo:

wlan0 Link encap:Ethernet HWaddr 00:21:6a:a5:18:79
inet addr:192.168.1.6 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: 2001:db8:1006:0:221:6aff:fea5:1879/64 Scope:Global
inet6 addr: fe80::221:6aff:fea5:1879/64 Scope:Link
inet6 addr: 2001:db8:1006:0:2c04:41de:e3bc:ffe/64 Scope:Global

De esta forma, las peticiones en una página web aparecen como si se hicieran desde la ip privacy:

Nombre del Ordenador: 2001:db8:1006:0:2c04:41de:e3bc:ffe

Una dirección IP vendrá formada pues, en el caso que tengamos una ip /64, los 64 primeros bits vendrán dados por nuestro proveedor, los últimos 64, se generarán “aleatoriamente”.
Al igual que en IPv4 pues, podremos usar igualmente DHCP (aunque no sería recomendable) o bien definir una IPv6 de forma manual.
La recomendación con IPv6 (y esto es realmente muy importante), seria olvidarse de recordar un montón de direcciones IP y empezar a usar los DNS (Domain Name System), que para esto fueron creados! :)

En los DNS, para asignar una dirección IPv4 usamos el Address Record A, en IPv6 usaremos AAAA, así que al ejecutar una petición de resolución sobre un dominio nos va a devolver las direcciones IPv4 y IPv6 relacionadas. Si nuestra red tiene salida IPv6, la dirección IPv6 será la prioritaria:

$ host guifi.net
guifi.net has address 109.69.8.5
guifi.net has IPv6 address 2a00:1508::5

== El protocolo de movilidad ==
En IPv6 se ha desarrollado un conjunto de protocolos y herramientas de movilidad, que permiten "saltar" de red a red sin perder en ningún momento la conectividad. Por ejemplo, gracias a SLAAC los últimos 64 bits de nuestra IP son fijos (basados en la MAC). Así que si sabemos el prefijo (los primeros 64 bits) de la nueva red donde nos vamos a mover, podemos hacerlo sin perder nunca la conexión.

Por ejemplo, estamos en nuestra casa haciendo una llamada telefónica con nuestro móvil conectado a nuestra wifi y de repente salimos a la calle, fuera del alcance de nuestra wifi y pasamos a la red móvil de nuestro operador telefónico. Gracias a este protocolo podremos realizar dicha llamada telefónica sin ningún corte!

== Extensión IPSec ==
IPv4 se diseñó para ser funcional, no seguro; así que con IPv6 se ha dado un paso adelante en este aspecto. Es la razon por la que se ha implementado IPSec en este protocolo. El uso de IPSec no es obligatorio en IPv6, lo que si que es realmente obligatorio es que todos los dispositivos que soporten IPv6 (y esto sería extensivo para las conexiones end2end), también soporten IPSec, dejando a nuestro libre albedrío la decisión de proteger o no nuestras comunicaciones.
Más información

== Trabajando con IPv6 ==
La primera impresión que tenemos con IPv6 es pensar... ¡qué jaleo! ¡se han vuelto locos! ¡esto es el fin! Pero en realidad migrar una red de IPv4 a IPv6 no es una cosa tan crítica, además de que ambos protocolos pueden convivir perfectamente sin ningún tipo de conflicto! y es que TCP/IP aunque sea el protocolo más extendido no es el único. Posiblemente si analizamos nuestra red y se ha conectado nuestro vecino con su icacharro, podremos ver peticiones del protocolo manzanatalk. Vale que manzanatalk cada vez está más en desuso, pero es el primer protocolo distinto a tcp/ip que nos viene a la cabeza, están otros como netbios, ipx, etc.

Posiblemente nuestro operador de telecomunicaciones no está haciendo su trabajo y en tu casa aún no dispones de IPv6, ¡pero no desesperes! ¡hay opción!
Existen los llamados tunnel brokers, que te permiten realizar tuneles 6to4 (sit). Todos los que he probado requerían IPv4 estática, pero parece que existe ya alguno que también permiten IPv4 dinámica.
Así que vayamos a ver uno de los mas conocidos, el de hurricane electric, que además te ofrece los comandos para hacer un copy-paste en tu consola y disponer al acto de IPv6 :)
Hurricane Electric (tunnelbroker.net)
Esta página requiere registro y también IPv4 estática, pero una vez pasamos estos tramites podemos crear un tunel 6to4 realmente estable.
Una vez logueados vamos a "Create Regular Tunnel", especificamos nuestra dirección IP (si no la ha localizado), escojemos uno de los servidores y le damos a "Create Tunnel".
A continuación nos aparece una página con nuestra configuración IPv6 y en la pestaña example configurations escogemos nuestro sistema operativo (el caso más común Linux-net-tools):

ifconfig sit0 up
ifconfig sit0 inet6 tunnel ::216.66.84.46
ifconfig sit1 up
ifconfig sit1 inet6 add 2001:470:1f14:18b::2/64
route -A inet6 add ::/0 dev sit1

A partir de aquí ya dispondremos de un tunnel IPv6 en nuestra máquina y uno de los siguientes pasos es probar si estamos ya preparados para el mundo IPv6:
http://test-ipv6.com/

Una vez tengamos IPv6 podemos realizar algunas pruebas. Dichas pruebas están hechas desde un servidor de giss.tv (giss.delanit.net), así que a partir de aquí las direcciones IPv6 son reales:
$ host giss.delanit.net
giss.delanit.net is an alias for v-giss.delanit.net.
v-giss.delanit.net has address 109.69.9.56
v-giss.delanit.net has IPv6 address 2a00:1508:1000::6d45:938

=== Configuración IP ===
Éste servidor tiene en eth0 la IPv4 (pública) 108.69.9.56 y la IPv6 (global) 2a00:1508:1000::6d45:938. En eth1 la IPv4 interna de guifi.net. En la interfaz lo nos fijamos que está la ::1 que equivale a la 127.0.0.1.

# ifconfig
eth0 Link encap:Ethernet HWaddr 00:18:51:e6:d6:47
inet addr:109.69.9.56 Bcast:109.69.9.63 Mask:255.255.255.240
inet6 addr: 2a00:1508:1000::6d45:938/64 Scope:Global
inet6 addr: fe80::218:51ff:fee6:d647/64 Scope:Link

eth1 Link encap:Ethernet HWaddr 00:18:51:16:16:17
inet addr:10.138.15.131 Bcast:10.138.15.159 Mask:255.255.255.224
inet6 addr: fe80::218:51ff:fe16:1617/64 Scope:Link

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host

# route -6 -n
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
2a00:1508:1000::/64 :: U 256 0 1 eth0
fe80::/64 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 eth1
::/0 2a00:1508:1000::6d45:901 UG 1024 1 312 eth0
::/0 :: !n -1 1 830 lo
::1/128 :: Un 0 1 31179 lo
2a00:1508:1000::6d45:938/128 :: Un 0 1 21440 lo
fe80::218:51ff:fe16:1617/128 :: Un 0 1 0 lo
fe80::218:51ff:fee6:d647/128 :: Un 0 1 74 lo
ff00::/8 :: 256 0 0 eth0
ff00::/8 :: U 256 0 0 eth1
::/0 :: !n -1 1 830 lo

Al ser un servidor le hemos definido al igual que la IPv4, una IPv6 estática:

[/etc/network/interfaces]
auto lo eth0
iface lo inet loopback
iface eth0 inet static
address 109.69.9.56
netmask 255.255.255.240
gateway 109.69.9.49

iface eth0 inet6 static
address 2a00:1508:1000::6d45:938
netmask 64
up ip r add default via 2a00:1508:1000::6d45:901 dev eth0

Ping
$ ping6 guifi.net
PING guifi.net(2a00-1508--5.ip6.guifi.net) 56 data bytes
64 bytes from v6.guifi.net: icmp_seq=1 ttl=62 time=2.47 ms
64 bytes from 2a00-1508--5.ip6.guifi.net: icmp_seq=2 ttl=62 time=1.96 ms
64 bytes from v6.guifi.net: icmp_seq=3 ttl=62 time=2.08 ms

Traceroute
$ traceroute -6 guifi.net
traceroute to guifi.net (2a00:1508::5), 30 hops max, 80 byte packets
1 2a00:1508:1000::6d45:901 (2a00:1508:1000::6d45:901) 0.183 ms 0.166 ms 0.280 ms
2 2a00:1508:ffff:fffb::21 (2a00:1508:ffff:fffb::21) 2.032 ms 2.034 ms 2.029 ms
3 v6.guifi.net (2a00:1508::5) 2.438 ms 2.430 ms 2.423 ms

Si nos fijamos, estamos usando las típicas herramientas de red, pero le estamos añadiento la opción -6.

De momento, como no todo el mundo dispone de IPv6 en sus servidores, dependemos de IPv4 hasta que poco a poco toda la red vaya migrando a IPv6 (algunos proveedores estiman que el proceso no se completará hasta 2030). Muchos, antes de empezar a mirar Ipv6, nos imaginamos que este cambio puede ser una cosa tan crítica como el más que conocido efecto 2000, en la que nos pensábamos que todo dejaría de funcionar. Pero como todo, es bueno estar preparados antes de que nos pille el tren, y lo más importante es informarse de lo que realmente implica este cambio. En mi humilde opinión ¡a mejor! :)

== Presentes y futuros usos de un internet basado en IPv6 ==
Al igual que cuando se diseñó IPv4, nadie imaginaba que terminaríamos todos con pequeños dispositivos en nuestros bolsillos con una capacidad computacional de varios cientos de veces de la de aquellos antiguos ordenadores de los años 80.
Pero es que en la actualidad somos incapaces de imaginarnos cómo accederemos a internet en el futuro inmediato, con qué dispositivos, cuales serán sus usos... etc. Y es que esta realidad la podemos ver sin tener que ir muchos años atrás. ¿Quién hubiese imaginado hace tan sólo 5 años que lo común sería estar con nuestro teléfono móvil sacando fotos de una cosa que nos gusta en la calle y compartiéndola en tiempo real con cientos de amigos/contactos en la red? Las protestas organizadas simultáneamente a varios puntos del planeta han sido posibles gracias a la evolución de la tecnología.

Cuando tenemos a nuestro alcance la posibilidad de asignar una dirección IP a cualquier dispositivo nos pueden venir a la cabeza algunos de sus usos en modo de ciencia ficción.

Algunos de los usos mas novedosos que se le está dando a IPv6 en la actualidad es en el ámbito de la domótica, casas “inteligentes”, en las cuales podemos controlar con nuestro dispositivo móvil hasta la mas insignificante bombilla. La imaginación se desborda cuando tratamos temas como la seguridad o la reducción de costes energéticos a favor de nuestro bolsillo y del medioambiente.

Otro de los posibles usos que podría tener es por ejemplo para gestionar mucho mejor nuestra agenda. Cada componente electrónico de nuestro coche podría tener su única dirección IP, estar conectado con la base de datos del fabricante y en el momento de que este fallase, el propio coche contactaría con nuestro taller mecánico, pediría la pieza y el coche se coordinaría con nuestra agenda para que, por ejemplo, cuando tengamos que ir a hacer una visita a un cliente, en lugar de aparcar el coche en el párking dejarlo en el taller mecánico más cercano, dónde nos estaría esperando el nuevo recambio.

No tenemos que olvidarnos tampoco de las ventajas que puede aportar IPv6 en el campo de la medicina, para el seguimiento en tiempo real de enfermos los cuales es preciso tener un control exhaustivo de su tratamiento, así como monitorización remota de dispositivos de electromedicina, como los marcapasos, control de la diabétes, etc.

Coches, elementos electrónicos, dispositivos móviles, etc. permanentemente conectados a internet gracias a las nuevas tecnologías móviles como LTE y el diseño de IPv6 de estar permanentemente conectados a cualquier tipo de red sin ningún tipo de corte...
Y es que el futuro ya está aquí, es el presente.

== Véase también ==
* [[Criterios de asignación de IPv6]]
* [http://www.consulintel.es/Html/ForoIPv6/Documentos/Tutorial%20de%20IPv6.pdf: Tutorial IPv6]

== Enlaces externos ==
;Lecturas recomendadas
http://www.ipv6.es/es-ES/recursos/Paginas/Libros.aspx 
http://www.worldipv6launch.org/ 
http://es.wikipedia.org/wiki/IPv6 
http://www.ipv6.com/

[[Categoría:IPv6]]

[[ca:IPv6]]

Categoría:IPv4

2014-02-20T21:13:22Z

Al:

El artículo principal de esta categoría es [[IPv4]].

[[Categoría:IP]]

[[ca:categoria:IPv4]]

Criterios de asignación de direcciones IPv4

2014-02-20T21:11:36Z

Al:

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

<h3>En primer lugar, los criterios de asignación en función de los usos:</h3>
<ul>
<li>'''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'''.</li>
</ul>

<ul>
<li>'''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'''.</li>
</ul>

<ul>
<li>'''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'''.</li>
</ul>

<h3>Formas de asignación:</h3>
<ul>
<li>'''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.</li>

<ul>
<li>Asignación automática de rangos de direcciones '''a las zonas'''.</li>
</ul>

<ul>
<li>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.</li>
</ul>

<ul>
<li>Asignación automática de direcciones públicas '''a las aplicaciones, nodo o servidores''' dentro de las zonas.</li>

<ul>
<li>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.</li>
</ul>

<ul>
<li>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.</li>
</ul>
</ul>

<ul>
<li>'''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.</li>
</ul>

<ul>
<li>'''Las direcciones privadas no se gestionan ni se reservan en ninguna herramienta de gestión''' sino que es responsabilidad del usuario gestionarlas.</li>
</ul>
</ul>

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.

=== Véase también ===
* [[Criterios de asignación de direcciones IPv6]]

[[ca:Criteris_d'assignació_d'adreces_IPv4]]

[[categoría:IPv4]]

Criterios de asignación de direcciones IPv6

2014-02-20T21:10:40Z

Al: /* Véase también */

Actualmente, la gran mayoría de nodos de la red Guifi.net solo funcionan bajo IPv4. Una excepción son algunas de las [[mesh]], que funcionan con el firmware [[Libre-mesh]], [[Altermesh]] y [[qMp]]<ref>[[qMp]] utiliza actualmente únicamente IPv6 [[LUA]], mientras que [[Altermesh]] utiliza IPv6 globales de [[Librenet6]]</ref> ya que éstos configuran el uso de IPv6 por defecto.

La migración se tendrá que hacer obligatoriamente en un futuro, es a la vez es algo delicado que supone un reto y un deseo. Esta migración requiere un estudio de la topología de la red y una nueva política de asignación de rangos IPv6 para los nodos y las zonas. Una vez definida la política, habría que continuar con la adaptación de la utilidad [[unsoloclic]] para soportar la configuración automática de los nodos. Por último, hay que proporcionar un mecanismo sencillo para que los administradores de nodos puedan o bien mantener en convivencia IPv4 e IPv6 o actualizar a IPv6 sin perder conectividad.

La web de http://guifi.net en cambio, sí que es accesible a través de [[IPv6]].

== Propuestas y desarrollo actual ==
La propuesta pública inicial<ref>Proyecto propuesto en el [http://bcnproject.com/forums/topic/modificar-la-interfaz-web-de-guifi-net-para-que-otorgue-rangos-ipv6/ Catalunya Dades Weekend]</ref> es que estas IPs sean IPv6 globales basadas en las IPv4 actualmente distribuidas (por ejemplo utilizando los dígitos de IPv4 como los cuatro últimos grupos de cuatro dígitos hexadecimales de IPv6), así la migración no resulta traumática.

=== Propuesta inicial en proceso de aceptación ===
En la propuesta inicial el desarrollo utiliza un <code>/40</code> del rango IPv6 de guifi.net <code>2a00:1508:0a00::/40</code> (equivalente a 1/256 parte del rango total de Guifi.net, que es <code>2a00:1508::/32</code>).

La conversión de IPv4 de Guifi.net a IPv6 se hacía a partir de esta fórmula: https://gitorious.org/guifi/drupal-guifi/commit/17f15de8f105410e22cd7ec52e752207d103f16a

Y el resultado en test es accesible en http://guifi.gfi (actualmente sólo desde dentro de la red de guifi IPv4, precisamente hasta que arreglemos este asunto).

=== Desarrollo alternativo depurándose ===
En el desarrollo alternativo la propuesta utiliza tan sólo el que otorga [[Código Sur]] a [[Librenet6]]: <code>2a00:1508:1:f000::/52</code>. Entran 4096 x /64.

Es decir los tres primeros grupos y el primer dígito del cuarto grupo es fijo.

El resto de los dígitos hexadecimales de IPv6 van rellenados con los siguientes datos:
==== Para nodos de Libre-mesh ====
Librenet6 IPv4adaptCIDR-16MAC
2a00:1508:1:ffff:ffff:xxxx:xxxx:xxxx/64

Se aprovechan todos los dígitos de la siguiente manera:
* <code>fff:fff</code> adaptación a hexadecimal de los tres últimos octetos (''bytes'') de la IPv4 de Guifi.net (el primer octeto es el 10 o el 172 y se puede eludir).
* <code>f</code> CIDR menos 16: adaptación a hexadecimal de la máscara, se le resta 16 para que quepa en un sólo digito hexadecimal (la máscara en guifi.net siempre es mayor de 16).
* <code>xxxx:xxxx:xxxx</code> dirección [[MAC]] de la interfaz de red. Al ponerla completa nos garantizamos que sea siempre un número único, que sepamos la MAC completa del router a partir de la su IP.
* <code>/64</code> la máscara siempre es un /64

Esta propuesta necesita unos cuantos ajustes para que realmente quepan todos los nodos.

==== Para clientes de esos nodos ====
Los clientes que cuelgan de esos nodos tendrán la siguiente representación, basada en la anterior:
Librenet6 IPv4adapt MAC
2a00:1508:1:ffff:xxxx:xxxx:xxxx:xxxx/64

Se aprovechan todos los dígitos de la siguiente manera:
''en desarrollo''

==== Ejemplos ====
''en desarrollo''

''Nota: Las zonas [[Libre-mesh]] que están funcionando en el ámbito territorial de guifi.net están en período de prueba de implementación de esta forma de atribución de IPv6.''

== IPv6 en otras comunidades inalámbricas ==
La comunidad inalámbrica italiana [[Ninux.org]] publicó un documento con instrucciones para implantar y migrar sus nodos a IPv6.

== Véase también ==
* [[Criterios de asignación de direcciones IPv4]]
* [[IPv6]]
* [[Unsoloclic]]

== Referencias ==
<references />

== Enlaces externos ==
* http://blog.ninux.org/2012/08/30/ipv6-in-free-networks/
* http://www.codigosur.org/article/ipv6-en-redes-libres-la-experiencia-de-ninux/

[[Categoría:IPv6]]

Categoría:IPv6

2014-02-20T21:08:11Z

Al:

El artículo principal de esta categoría es [[IPv6]].

[[Categoría:IP]]

[[ca:categoria:IPv6]]

Categoría:IPv6

2014-02-20T21:07:54Z

Al:

El artículo principal de esta categoría es [[IPv6]].

[[Categoría:IP]]

[[ca:categoria:IP]]

Criterios de asignación de direcciones IPv6

2014-02-20T21:07:19Z

Al: Al movió la página IPv6 en Guifi.net a Criterios de asignación de direcciones IPv6

Actualmente, la gran mayoría de nodos de la red Guifi.net solo funcionan bajo IPv4. Una excepción son algunas de las [[mesh]], que funcionan con el firmware [[Libre-mesh]], [[Altermesh]] y [[qMp]]<ref>[[qMp]] utiliza actualmente únicamente IPv6 [[LUA]], mientras que [[Altermesh]] utiliza IPv6 globales de [[Librenet6]]</ref> ya que éstos configuran el uso de IPv6 por defecto.

La migración se tendrá que hacer obligatoriamente en un futuro, es a la vez es algo delicado que supone un reto y un deseo. Esta migración requiere un estudio de la topología de la red y una nueva política de asignación de rangos IPv6 para los nodos y las zonas. Una vez definida la política, habría que continuar con la adaptación de la utilidad [[unsoloclic]] para soportar la configuración automática de los nodos. Por último, hay que proporcionar un mecanismo sencillo para que los administradores de nodos puedan o bien mantener en convivencia IPv4 e IPv6 o actualizar a IPv6 sin perder conectividad.

La web de http://guifi.net en cambio, sí que es accesible a través de [[IPv6]].

== Propuestas y desarrollo actual ==
La propuesta pública inicial<ref>Proyecto propuesto en el [http://bcnproject.com/forums/topic/modificar-la-interfaz-web-de-guifi-net-para-que-otorgue-rangos-ipv6/ Catalunya Dades Weekend]</ref> es que estas IPs sean IPv6 globales basadas en las IPv4 actualmente distribuidas (por ejemplo utilizando los dígitos de IPv4 como los cuatro últimos grupos de cuatro dígitos hexadecimales de IPv6), así la migración no resulta traumática.

=== Propuesta inicial en proceso de aceptación ===
En la propuesta inicial el desarrollo utiliza un <code>/40</code> del rango IPv6 de guifi.net <code>2a00:1508:0a00::/40</code> (equivalente a 1/256 parte del rango total de Guifi.net, que es <code>2a00:1508::/32</code>).

La conversión de IPv4 de Guifi.net a IPv6 se hacía a partir de esta fórmula: https://gitorious.org/guifi/drupal-guifi/commit/17f15de8f105410e22cd7ec52e752207d103f16a

Y el resultado en test es accesible en http://guifi.gfi (actualmente sólo desde dentro de la red de guifi IPv4, precisamente hasta que arreglemos este asunto).

=== Desarrollo alternativo depurándose ===
En el desarrollo alternativo la propuesta utiliza tan sólo el que otorga [[Código Sur]] a [[Librenet6]]: <code>2a00:1508:1:f000::/52</code>. Entran 4096 x /64.

Es decir los tres primeros grupos y el primer dígito del cuarto grupo es fijo.

El resto de los dígitos hexadecimales de IPv6 van rellenados con los siguientes datos:
==== Para nodos de Libre-mesh ====
Librenet6 IPv4adaptCIDR-16MAC
2a00:1508:1:ffff:ffff:xxxx:xxxx:xxxx/64

Se aprovechan todos los dígitos de la siguiente manera:
* <code>fff:fff</code> adaptación a hexadecimal de los tres últimos octetos (''bytes'') de la IPv4 de Guifi.net (el primer octeto es el 10 o el 172 y se puede eludir).
* <code>f</code> CIDR menos 16: adaptación a hexadecimal de la máscara, se le resta 16 para que quepa en un sólo digito hexadecimal (la máscara en guifi.net siempre es mayor de 16).
* <code>xxxx:xxxx:xxxx</code> dirección [[MAC]] de la interfaz de red. Al ponerla completa nos garantizamos que sea siempre un número único, que sepamos la MAC completa del router a partir de la su IP.
* <code>/64</code> la máscara siempre es un /64

Esta propuesta necesita unos cuantos ajustes para que realmente quepan todos los nodos.

==== Para clientes de esos nodos ====
Los clientes que cuelgan de esos nodos tendrán la siguiente representación, basada en la anterior:
Librenet6 IPv4adapt MAC
2a00:1508:1:ffff:xxxx:xxxx:xxxx:xxxx/64

Se aprovechan todos los dígitos de la siguiente manera:
''en desarrollo''

==== Ejemplos ====
''en desarrollo''

''Nota: Las zonas [[Libre-mesh]] que están funcionando en el ámbito territorial de guifi.net están en período de prueba de implementación de esta forma de atribución de IPv6.''

== IPv6 en otras comunidades inalámbricas ==
La comunidad inalámbrica italiana [[Ninux.org]] publicó un documento con instrucciones para implantar y migrar sus nodos a IPv6.

== Véase también ==
* [[IPv6]]
* [[Unsoloclic]]

== Referencias ==
<references />

== Enlaces externos ==
* http://blog.ninux.org/2012/08/30/ipv6-in-free-networks/
* http://www.codigosur.org/article/ipv6-en-redes-libres-la-experiencia-de-ninux/

[[Categoría:IPv6]]

IPv6 en Guifi.net

2014-02-20T21:07:19Z

Al: Al movió la página IPv6 en Guifi.net a Criterios de asignación de direcciones IPv6

#REDIRECCIÓN [[Criterios de asignación de direcciones IPv6]]

Categoría:IP

2014-02-20T21:04:07Z

Al:

El artículo principal de esta categoría es [[IP]].

[[ca:Categoria:IP]]

Categoría:IPv4

2014-02-20T21:03:33Z

Al: Página creada con «El artículo principal de esta categoría es IPv4. Categoría:IP»

El artículo principal de esta categoría es [[IPv4]].

[[Categoría:IP]]

Criterios de asignación de direcciones IPv4

2014-02-20T21:02:44Z

Al:

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

<h3>En primer lugar, los criterios de asignación en función de los usos:</h3>
<ul>
<li>'''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'''.</li>
</ul>

<ul>
<li>'''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'''.</li>
</ul>

<ul>
<li>'''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'''.</li>
</ul>

<h3>Formas de asignación:</h3>
<ul>
<li>'''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.</li>

<ul>
<li>Asignación automática de rangos de direcciones '''a las zonas'''.</li>
</ul>

<ul>
<li>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.</li>
</ul>

<ul>
<li>Asignación automática de direcciones públicas '''a las aplicaciones, nodo o servidores''' dentro de las zonas.</li>

<ul>
<li>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.</li>
</ul>

<ul>
<li>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.</li>
</ul>
</ul>

<ul>
<li>'''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.</li>
</ul>

<ul>
<li>'''Las direcciones privadas no se gestionan ni se reservan en ninguna herramienta de gestión''' sino que es responsabilidad del usuario gestionarlas.</li>
</ul>
</ul>

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.

[[ca:Criteris_d'assignació_d'adreces_IPv4]]

[[categoría:IPv4]]

Categoría:IPv6

2014-02-20T21:01:47Z

Al:

El artículo principal de esta categoría es [[IPv6]].

[[Categoría:IP]]

Categoría:IP

2014-02-20T21:01:13Z

Al: Página creada con «El artículo principal de esta categoría es IP.»

El artículo principal de esta categoría es [[IP]].

Categoría:IPv6

2014-02-20T21:00:40Z

Al: Página creada con «El artículo principal de esta categoría es IPv6.»

El artículo principal de esta categoría es [[IPv6]].

IPv6

2014-02-20T20:56:39Z

Al:

{{wikificar|t=20140217134726}}

'''El crecimiento exponencial de Internet, ha hecho que desde los años 80, el agotamiento de las direcciones IPv4 haya sido un tema de preocupación. El agotamiento ya ha llegado y nos encontramos en la era del IPv6.'''

El 31 de Enero del 2011, la IANA (Internet Assigned Numbers Authority), entidad que se encarga de distribuïr las IPs en Internet, asignó los dos últimos bloques /8 (16 millones de IPs) y el 3 de Febrero finalmente se asignaron los últimos 5 bloques de direcciones disponibles a los cinco registros de Internet (Regional Internet Registries o RIR), que tienen delegada la asignación en las cinco regiones administrativas en que se divide el mundo según Internet. Aquí podemos ver cuando los RIR van a agotar definitivamente las Ipv4 disponibles.

En 1999 se preveía que si la red seguía creciendo al ritmo que lo hacía, el numero de IPs se agotaría antes de encontrar una solución al problema, así que se diseñó NAT (Network Address Translation). El concepto de NAT consiste en utilizar una dirección IP enrutable (o un número limitado de direcciones IP) para conectar todas las máquinas a través de la traducción, en la pasarela de internet, entre la dirección interna (no enrutable) de la máquina que se desea conectar y la dirección IP de la pasarela.

Además, el proceso de traducción de direcciones permite a las compañías asegurar la red interna siempre y cuando oculte la asignación de direcciones internas. Para un observador que se ubica fuera de la red, todos los pedidos parecen provenir de la misma dirección IP.

NAT ha podido parecer un gran invento, también una forma de "tener los ordenadores a salvo del salvaje internet". NAT ha sido adoptado como firewall, pero en realidad no lo es ya que se permite que protocolos como UPNP o conexiones inversas puedan acceder a equipos de detrás del NAT.

Sin embargo, este sistema no está facilitando la tarea a todas aquellas aplicaciones tipo cliente-servidor (que ofrecen servicios dedicados a los usuarios), o permitiendo las cliente-cliente, tal como podría ser VoIP, Televisión Interactiva, juegos on-line, programas P2P, etc. Si somos usuarios de estos servicios seguramente alguna vez habremos tenido que acceder a nuestro router y configurar la redirección de puertos. Con IPv6 ¡esta farragosa tarea desaparece! cada ordenador dispone de una ip global y con este motivo, es posible rutearlo directamente a Internet, así que desde hace ya unos años, los sistemas operativos se toman mucho más en serio el tema de la seguridad y por un buen motivo, un sistema o aplicación que no esté preparado para las redes del futuro, ¡estará condenado a desaparecer!

Además de esto nos encontramos con la realidad del imparable crecimiento de internet, que en los últimos 10 años ha experimentado un crecimiento superior al 600%, día tras día se unen a esta gran red nuevos tipos de dispositivos.

== IPv6, el protocolo ==
Este protocolo empezó a ser diseñado en 1996 por la [http://www.ietf.org/ IETF (Internet Engineering Task Force)], organización que desarrolla y promueve estándares sobretodo sobre TCP/IP y protocolos de Internet. Desde entonces IPv6 ha ido evolucionando, pero a diferencia de otros protocolos se decidió no definir versiones, en motivo del farragoso proceso de estandarización de los RFC que hace que muchos estándares se apliquen en la red antes de ser estandarizados, como por ejemplo el polémico 802.11n.

Uno de los cambios que saltan mas a la vista es la notación de las direcciones, que trata de direcciones de 128bits de longitud escritos en 8 grupos de cuatro dígitos hexadecimales:

2001:0db8:85a3:08d3:1319:8a2e:0370:7334

Esto es una dirección IPv6 válida. Usamos el prefijo 2001:0db8: para documentación.
Si un grupo de cuatro dígitos es nulo (que tiene el valor 0000), puede ser comprimido, así que estas dos direcciones IPv6 serían en realidad la misma:

2001:0db8:85a3:0000:1319:8a2e:0370:7344
2001:0db8:85a3::1319:8a2e:0370:7344

Siguiendo esta regla, si más de dos grupos consecutivos son nulos pueden comprimirse como "::". Si la dirección tiene más de una serie de grupos nulos consecutivos, la compresión se puede aplicar en más de uno, así que:

2001:0DB8:0000:0000:0000:0000:1428:57ab
2001:0DB8:0000:0000:0000::1428:57ab
2001:0DB8:0:0:0:0:1428:57ab
2001:0DB8:0::0:1428:57ab
2001:0DB8::1428:57ab

Són todas válidas y representan lo mismo, pero

2001::25de::cade

No es válida porqué no queda claro cuantos grupos nulos hay en cada lado.

Los ceros iniciales en un grupo pueden ser omitidos. Así que:

2001:0DB8:02de::0e13

Es lo mismo que

2001:DB8:2de::e13

== Tipo de direcciones IPv6 ==
* '''Multicast (una a muchas):''' "ff00::/8"
* '''Anycast (una a la más cercana):''' para la réplica de DNS (por ejemplo para hacer peticiones al servidor DNS más cercano topológicamente hablando).
* '''Unicast:'''
** Globales : equivaldrían a lo que conocemos como IPs públicas en IPv4.
** Enlace local (link-local): "fe80::/10" Sólo son válidas a nivel 2, serían como las 169.254.0.0/16 en IPv4. No són enrutables en la red IPv6. Más info.
** Locales únicas (ULA): "fc00::/7" Estas tampoco son enrutables en la red IPv6 y su uso común es para redes privadas virtuales, un ejemplo podría ser el caso de un banco, que tiene sus ordenadores conectados a internet con su IP global, pero el programa de gestión del banco sólo sería accesible desde la ULA. Es habitual pues que un ordenador con IPv6 disponga de varias direcciones IPv6. Más info.
** IPv4 mapeadas: "::ffff:0:0/96" (en desuso)
** Compatible IPv4: (desaprobadas)
** Local de sitio (site-local): (desaprobadas) "fec0::/10" para definir una red interna en un edificio o planta.
** Loopback: "::1/128" el equivalente a la 127.0.0.1/8

== Los rangos de IP ==
IPv6 está diseñado para que cada máquina tenga asignado un rango en lugar de una única IP. Solo en casos muy concretos se aconseja que un dispositivo electrónico tenga una única IP.
El rango mínimo que se debería asignar a una interfaz de red es un /64 (2^64 Ips).
De esta forma puede usarse la MAC address del dispositivo físico para generar una IP válida en esos restantes 64 bits. De esta forma, entre otras cosas se gana privacidad, pues ya no será trivial descubrir la IP de una máquina y escanear el rango entero nos podría costar varios años.

Los RIRs recomiendan a las ISP que entreguen a sus clientes un /48, de esta forma el cliente puede asignar hasta 2^16 /64 a sus dispositivos domésticos (nevera, teléfono, tele, enchufe, persiana...)

Asignando un /48 a cada persona del planeta, suponiendo que estas /48 no se devolviesen, se podría asignar un /48 a cada persona del planeta durante 480 años.
¡Se espera que el protocolo quede obsoleto mucho antes!

== Broadcast y ARP ==
Otro cambio realmente significante es que IPv6 no implemente Broadcast, y por lo tanto no existe broadcast domain.
En su lugar se ha extendido y mejorado el funcionamiento de Multicast. Para comunicar los ordenadores directamente conectados (y sin conocer previamente sus Ips) se puede usar la dirección link-local multicast ff02::1.
En IPv6 ARP ha sido sustituido por un protocolo mucho más potente, NDP (Neighbor Discovery Protocol) que usa ICPMv6 para sus comunicaciones.

Una de las consecuencias de estos dos cambios es que, por ejemplo, se pueden comunicar dos maquinas conectadas sin necesidad de configurar ninguna IP. Las direcciones link-local (fe80::/10), que se configuran automáticamente en nuestro sistema, nos lo permiten.
ssh usuario@ipv6link-local%eth0

Como se puede apreciar la interfaz de red debe ser especificada, ya que si no el kernel no tiene forma de saber hacia donde enviar los paquetes. El ordenador destino verá que la dirección de destinación es su propia IP link-local y aceptará el paquete.

== ULA ==
También funcionaría por las ULA, pero no tiene sentido, ya que aunque no sean enrutables por internet si que pueden serlo dentro de la red local, y en este caso el gateway ya nos enrutaría a la ubicación correcta.

Para añadir una ULA:
ip -6 addr add ULA/64 dev INTERFACE

== El enrutamiento estático ==
El comportamiento de la red en esta versión cambia de forma significativa con la versión anterior, por ejemplo no es usual encontrar configuraciones como la siguiente:

eth0: 192.168.1.1/24
eth1: 192.168.1.10/16

En IPv6 lo habitual es que un mismo rango esté incluido en dos dispositivos de red (uno incluye el otro), el mas pequeño es siempre el que manda. Esta característica fue exportada a IPv4.

2001:0DB8:1006::/64 es mas pequeño que 2001:0DB8:1006:1100::/56

== SLACC (Stateless address autoconfiguration) ==
En IPv6 son los mismos hosts quienes se configuran automáticamente usando el protocolo "Neighbor Discovery Protocol" (NDP) mediante mensajes ICMPv6.
En el momento que estos se conectan a la red, envian al router una solicitud de link-local mediante una petición multicast (router solicitation) pidiendo los parámetros de configuración. Entonces los routers responderán con un paquete "router advertisment" que contiene los parámetros de configuración de la red.

== La cabecera de IPv6 ==
IPv6 incrementa la longitud de la cabecera IP de 20 a 40 bytes. La cabecera IPv6 contiene dos direcciones de 16 bytes (fuente y destino) precedidas de 8 bytes de control. La reducción de la información de control y la eliminación de opciones de la cabecera tienen como fin optimizar el procesamiento del paquete. Los campos de uso poco frecuente se han eliminado de la cabecera y se han pasado a extensiones de cabecera opcionales.

El campo "cabecera siguiente" o "next header", permite añadir nuevos campos en la cabecera sin tener que actualizar el software o el hardware de todos los dispositivos de la red. Y es que IPv6 se ha diseñado para poder implementar nuevos cambios de forma progresiva sin tener que apagar toda la red para aplicarlos.
Más información.

== La asignación de IPs ==
En IPv6 exististe DHCPv6, pero no es la opción recomendada. Para ello tenemos el nuevo protocolo SLAAC.
En el router cabecera activamos el RA y los equipos de la red al conectarse a ella ven el anuncio del router y son ellos mismos quienes se aplican la dirección IP a partir de, por ejemplo, su dirección MAC. En sistemas basados en GNU/Linux siempre se asigna dicha IP a partir de la MAC, pero en otros sistemas existen las llamadas direcciones de privacidad, donde se genera la IP de forma aleatoria.
Para activar IPv6 privacy en GNU/Linux deberemos activar las "IPv6 Privacy Extensions", como root editamos /etc/sysctl.conf y añadimos estas líneas:

net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2

Reiniciamos la red (o la maquina si se resiste al cambio) y entonces, si disponemos de un RA en nuestra red, veremos que nos asigna 2 direcciones IPv6, una basada en nuestra MAC y otra aleatoria. Un ejemplo:

wlan0 Link encap:Ethernet HWaddr 00:21:6a:a5:18:79
inet addr:192.168.1.6 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: 2001:db8:1006:0:221:6aff:fea5:1879/64 Scope:Global
inet6 addr: fe80::221:6aff:fea5:1879/64 Scope:Link
inet6 addr: 2001:db8:1006:0:2c04:41de:e3bc:ffe/64 Scope:Global

De esta forma, las peticiones en una página web aparecen como si se hicieran desde la ip privacy:

Nombre del Ordenador: 2001:db8:1006:0:2c04:41de:e3bc:ffe

Una dirección IP vendrá formada pues, en el caso que tengamos una ip /64, los 64 primeros bits vendrán dados por nuestro proveedor, los últimos 64, se generarán “aleatoriamente”.
Al igual que en IPv4 pues, podremos usar igualmente DHCP (aunque no sería recomendable) o bien definir una IPv6 de forma manual.
La recomendación con IPv6 (y esto es realmente muy importante), seria olvidarse de recordar un montón de direcciones IP y empezar a usar los DNS (Domain Name System), que para esto fueron creados! :)

En los DNS, para asignar una dirección IPv4 usamos el Address Record A, en IPv6 usaremos AAAA, así que al ejecutar una petición de resolución sobre un dominio nos va a devolver las direcciones IPv4 y IPv6 relacionadas. Si nuestra red tiene salida IPv6, la dirección IPv6 será la prioritaria:

$ host guifi.net
guifi.net has address 109.69.8.5
guifi.net has IPv6 address 2a00:1508::5

== El protocolo de movilidad ==
En IPv6 se ha desarrollado un conjunto de protocolos y herramientas de movilidad, que permiten "saltar" de red a red sin perder en ningún momento la conectividad. Por ejemplo, gracias a SLAAC los últimos 64 bits de nuestra IP son fijos (basados en la MAC). Así que si sabemos el prefijo (los primeros 64 bits) de la nueva red donde nos vamos a mover, podemos hacerlo sin perder nunca la conexión.

Por ejemplo, estamos en nuestra casa haciendo una llamada telefónica con nuestro móvil conectado a nuestra wifi y de repente salimos a la calle, fuera del alcance de nuestra wifi y pasamos a la red móvil de nuestro operador telefónico. Gracias a este protocolo podremos realizar dicha llamada telefónica sin ningún corte!

== Extensión IPSec ==
IPv4 se diseñó para ser funcional, no seguro; así que con IPv6 se ha dado un paso adelante en este aspecto. Es la razon por la que se ha implementado IPSec en este protocolo. El uso de IPSec no es obligatorio en IPv6, lo que si que es realmente obligatorio es que todos los dispositivos que soporten IPv6 (y esto sería extensivo para las conexiones end2end), también soporten IPSec, dejando a nuestro libre albedrío la decisión de proteger o no nuestras comunicaciones.
Más información

== Trabajando con IPv6 ==
La primera impresión que tenemos con IPv6 es pensar... ¡qué jaleo! ¡se han vuelto locos! ¡esto es el fin! Pero en realidad migrar una red de IPv4 a IPv6 no es una cosa tan crítica, además de que ambos protocolos pueden convivir perfectamente sin ningún tipo de conflicto! y es que TCP/IP aunque sea el protocolo más extendido no es el único. Posiblemente si analizamos nuestra red y se ha conectado nuestro vecino con su icacharro, podremos ver peticiones del protocolo manzanatalk. Vale que manzanatalk cada vez está más en desuso, pero es el primer protocolo distinto a tcp/ip que nos viene a la cabeza, están otros como netbios, ipx, etc.

Posiblemente nuestro operador de telecomunicaciones no está haciendo su trabajo y en tu casa aún no dispones de IPv6, ¡pero no desesperes! ¡hay opción!
Existen los llamados tunnel brokers, que te permiten realizar tuneles 6to4 (sit). Todos los que he probado requerían IPv4 estática, pero parece que existe ya alguno que también permiten IPv4 dinámica.
Así que vayamos a ver uno de los mas conocidos, el de hurricane electric, que además te ofrece los comandos para hacer un copy-paste en tu consola y disponer al acto de IPv6 :)
Hurricane Electric (tunnelbroker.net)
Esta página requiere registro y también IPv4 estática, pero una vez pasamos estos tramites podemos crear un tunel 6to4 realmente estable.
Una vez logueados vamos a "Create Regular Tunnel", especificamos nuestra dirección IP (si no la ha localizado), escojemos uno de los servidores y le damos a "Create Tunnel".
A continuación nos aparece una página con nuestra configuración IPv6 y en la pestaña example configurations escogemos nuestro sistema operativo (el caso más común Linux-net-tools):

ifconfig sit0 up
ifconfig sit0 inet6 tunnel ::216.66.84.46
ifconfig sit1 up
ifconfig sit1 inet6 add 2001:470:1f14:18b::2/64
route -A inet6 add ::/0 dev sit1

A partir de aquí ya dispondremos de un tunnel IPv6 en nuestra máquina y uno de los siguientes pasos es probar si estamos ya preparados para el mundo IPv6:
http://test-ipv6.com/

Una vez tengamos IPv6 podemos realizar algunas pruebas. Dichas pruebas están hechas desde un servidor de giss.tv (giss.delanit.net), así que a partir de aquí las direcciones IPv6 son reales:
$ host giss.delanit.net
giss.delanit.net is an alias for v-giss.delanit.net.
v-giss.delanit.net has address 109.69.9.56
v-giss.delanit.net has IPv6 address 2a00:1508:1000::6d45:938

=== Configuración IP ===
Éste servidor tiene en eth0 la IPv4 (pública) 108.69.9.56 y la IPv6 (global) 2a00:1508:1000::6d45:938. En eth1 la IPv4 interna de guifi.net. En la interfaz lo nos fijamos que está la ::1 que equivale a la 127.0.0.1.

# ifconfig
eth0 Link encap:Ethernet HWaddr 00:18:51:e6:d6:47
inet addr:109.69.9.56 Bcast:109.69.9.63 Mask:255.255.255.240
inet6 addr: 2a00:1508:1000::6d45:938/64 Scope:Global
inet6 addr: fe80::218:51ff:fee6:d647/64 Scope:Link

eth1 Link encap:Ethernet HWaddr 00:18:51:16:16:17
inet addr:10.138.15.131 Bcast:10.138.15.159 Mask:255.255.255.224
inet6 addr: fe80::218:51ff:fe16:1617/64 Scope:Link

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host

# route -6 -n
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
2a00:1508:1000::/64 :: U 256 0 1 eth0
fe80::/64 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 eth1
::/0 2a00:1508:1000::6d45:901 UG 1024 1 312 eth0
::/0 :: !n -1 1 830 lo
::1/128 :: Un 0 1 31179 lo
2a00:1508:1000::6d45:938/128 :: Un 0 1 21440 lo
fe80::218:51ff:fe16:1617/128 :: Un 0 1 0 lo
fe80::218:51ff:fee6:d647/128 :: Un 0 1 74 lo
ff00::/8 :: 256 0 0 eth0
ff00::/8 :: U 256 0 0 eth1
::/0 :: !n -1 1 830 lo

Al ser un servidor le hemos definido al igual que la IPv4, una IPv6 estática:

[/etc/network/interfaces]
auto lo eth0
iface lo inet loopback
iface eth0 inet static
address 109.69.9.56
netmask 255.255.255.240
gateway 109.69.9.49

iface eth0 inet6 static
address 2a00:1508:1000::6d45:938
netmask 64
up ip r add default via 2a00:1508:1000::6d45:901 dev eth0

Ping
$ ping6 guifi.net
PING guifi.net(2a00-1508--5.ip6.guifi.net) 56 data bytes
64 bytes from v6.guifi.net: icmp_seq=1 ttl=62 time=2.47 ms
64 bytes from 2a00-1508--5.ip6.guifi.net: icmp_seq=2 ttl=62 time=1.96 ms
64 bytes from v6.guifi.net: icmp_seq=3 ttl=62 time=2.08 ms

Traceroute
$ traceroute -6 guifi.net
traceroute to guifi.net (2a00:1508::5), 30 hops max, 80 byte packets
1 2a00:1508:1000::6d45:901 (2a00:1508:1000::6d45:901) 0.183 ms 0.166 ms 0.280 ms
2 2a00:1508:ffff:fffb::21 (2a00:1508:ffff:fffb::21) 2.032 ms 2.034 ms 2.029 ms
3 v6.guifi.net (2a00:1508::5) 2.438 ms 2.430 ms 2.423 ms

Si nos fijamos, estamos usando las típicas herramientas de red, pero le estamos añadiento la opción -6.

De momento, como no todo el mundo dispone de IPv6 en sus servidores, dependemos de IPv4 hasta que poco a poco toda la red vaya migrando a IPv6 (algunos proveedores estiman que el proceso no se completará hasta 2030). Muchos, antes de empezar a mirar Ipv6, nos imaginamos que este cambio puede ser una cosa tan crítica como el más que conocido efecto 2000, en la que nos pensábamos que todo dejaría de funcionar. Pero como todo, es bueno estar preparados antes de que nos pille el tren, y lo más importante es informarse de lo que realmente implica este cambio. En mi humilde opinión ¡a mejor! :)

== Presentes y futuros usos de un internet basado en IPv6 ==
Al igual que cuando se diseñó IPv4, nadie imaginaba que terminaríamos todos con pequeños dispositivos en nuestros bolsillos con una capacidad computacional de varios cientos de veces de la de aquellos antiguos ordenadores de los años 80.
Pero es que en la actualidad somos incapaces de imaginarnos cómo accederemos a internet en el futuro inmediato, con qué dispositivos, cuales serán sus usos... etc. Y es que esta realidad la podemos ver sin tener que ir muchos años atrás. ¿Quién hubiese imaginado hace tan sólo 5 años que lo común sería estar con nuestro teléfono móvil sacando fotos de una cosa que nos gusta en la calle y compartiéndola en tiempo real con cientos de amigos/contactos en la red? Las protestas organizadas simultáneamente a varios puntos del planeta han sido posibles gracias a la evolución de la tecnología.

Cuando tenemos a nuestro alcance la posibilidad de asignar una dirección IP a cualquier dispositivo nos pueden venir a la cabeza algunos de sus usos en modo de ciencia ficción.

Algunos de los usos mas novedosos que se le está dando a IPv6 en la actualidad es en el ámbito de la domótica, casas “inteligentes”, en las cuales podemos controlar con nuestro dispositivo móvil hasta la mas insignificante bombilla. La imaginación se desborda cuando tratamos temas como la seguridad o la reducción de costes energéticos a favor de nuestro bolsillo y del medioambiente.

Otro de los posibles usos que podría tener es por ejemplo para gestionar mucho mejor nuestra agenda. Cada componente electrónico de nuestro coche podría tener su única dirección IP, estar conectado con la base de datos del fabricante y en el momento de que este fallase, el propio coche contactaría con nuestro taller mecánico, pediría la pieza y el coche se coordinaría con nuestra agenda para que, por ejemplo, cuando tengamos que ir a hacer una visita a un cliente, en lugar de aparcar el coche en el párking dejarlo en el taller mecánico más cercano, dónde nos estaría esperando el nuevo recambio.

No tenemos que olvidarnos tampoco de las ventajas que puede aportar IPv6 en el campo de la medicina, para el seguimiento en tiempo real de enfermos los cuales es preciso tener un control exhaustivo de su tratamiento, así como monitorización remota de dispositivos de electromedicina, como los marcapasos, control de la diabétes, etc.

Coches, elementos electrónicos, dispositivos móviles, etc. permanentemente conectados a internet gracias a las nuevas tecnologías móviles como LTE y el diseño de IPv6 de estar permanentemente conectados a cualquier tipo de red sin ningún tipo de corte...
Y es que el futuro ya está aquí, es el presente.

== Véase también ==
* [[IPv6 en Guifi.net]]
* [http://www.consulintel.es/Html/ForoIPv6/Documentos/Tutorial%20de%20IPv6.pdf: Tutorial IPv6]

== Enlaces externos ==
;Lecturas recomendadas
http://www.ipv6.es/es-ES/recursos/Paginas/Libros.aspx 
http://www.worldipv6launch.org/ 
http://es.wikipedia.org/wiki/IPv6 
http://www.ipv6.com/

[[Categoría:IPv6]]

[[ca:IPv6]]

Criterios de asignación de direcciones IPv6

2014-02-20T20:55:00Z

Al:

Actualmente, la gran mayoría de nodos de la red Guifi.net solo funcionan bajo IPv4. Una excepción son algunas de las [[mesh]], que funcionan con el firmware [[Libre-mesh]], [[Altermesh]] y [[qMp]]<ref>[[qMp]] utiliza actualmente únicamente IPv6 [[LUA]], mientras que [[Altermesh]] utiliza IPv6 globales de [[Librenet6]]</ref> ya que éstos configuran el uso de IPv6 por defecto.

La migración se tendrá que hacer obligatoriamente en un futuro, es a la vez es algo delicado que supone un reto y un deseo. Esta migración requiere un estudio de la topología de la red y una nueva política de asignación de rangos IPv6 para los nodos y las zonas. Una vez definida la política, habría que continuar con la adaptación de la utilidad [[unsoloclic]] para soportar la configuración automática de los nodos. Por último, hay que proporcionar un mecanismo sencillo para que los administradores de nodos puedan o bien mantener en convivencia IPv4 e IPv6 o actualizar a IPv6 sin perder conectividad.

La web de http://guifi.net en cambio, sí que es accesible a través de [[IPv6]].

== Propuestas y desarrollo actual ==
La propuesta pública inicial<ref>Proyecto propuesto en el [http://bcnproject.com/forums/topic/modificar-la-interfaz-web-de-guifi-net-para-que-otorgue-rangos-ipv6/ Catalunya Dades Weekend]</ref> es que estas IPs sean IPv6 globales basadas en las IPv4 actualmente distribuidas (por ejemplo utilizando los dígitos de IPv4 como los cuatro últimos grupos de cuatro dígitos hexadecimales de IPv6), así la migración no resulta traumática.

=== Propuesta inicial en proceso de aceptación ===
En la propuesta inicial el desarrollo utiliza un <code>/40</code> del rango IPv6 de guifi.net <code>2a00:1508:0a00::/40</code> (equivalente a 1/256 parte del rango total de Guifi.net, que es <code>2a00:1508::/32</code>).

La conversión de IPv4 de Guifi.net a IPv6 se hacía a partir de esta fórmula: https://gitorious.org/guifi/drupal-guifi/commit/17f15de8f105410e22cd7ec52e752207d103f16a

Y el resultado en test es accesible en http://guifi.gfi (actualmente sólo desde dentro de la red de guifi IPv4, precisamente hasta que arreglemos este asunto).

=== Desarrollo alternativo depurándose ===
En el desarrollo alternativo la propuesta utiliza tan sólo el que otorga [[Código Sur]] a [[Librenet6]]: <code>2a00:1508:1:f000::/52</code>. Entran 4096 x /64.

Es decir los tres primeros grupos y el primer dígito del cuarto grupo es fijo.

El resto de los dígitos hexadecimales de IPv6 van rellenados con los siguientes datos:
==== Para nodos de Libre-mesh ====
Librenet6 IPv4adaptCIDR-16MAC
2a00:1508:1:ffff:ffff:xxxx:xxxx:xxxx/64

Se aprovechan todos los dígitos de la siguiente manera:
* <code>fff:fff</code> adaptación a hexadecimal de los tres últimos octetos (''bytes'') de la IPv4 de Guifi.net (el primer octeto es el 10 o el 172 y se puede eludir).
* <code>f</code> CIDR menos 16: adaptación a hexadecimal de la máscara, se le resta 16 para que quepa en un sólo digito hexadecimal (la máscara en guifi.net siempre es mayor de 16).
* <code>xxxx:xxxx:xxxx</code> dirección [[MAC]] de la interfaz de red. Al ponerla completa nos garantizamos que sea siempre un número único, que sepamos la MAC completa del router a partir de la su IP.
* <code>/64</code> la máscara siempre es un /64

Esta propuesta necesita unos cuantos ajustes para que realmente quepan todos los nodos.

==== Para clientes de esos nodos ====
Los clientes que cuelgan de esos nodos tendrán la siguiente representación, basada en la anterior:
Librenet6 IPv4adapt MAC
2a00:1508:1:ffff:xxxx:xxxx:xxxx:xxxx/64

Se aprovechan todos los dígitos de la siguiente manera:
''en desarrollo''

==== Ejemplos ====
''en desarrollo''

''Nota: Las zonas [[Libre-mesh]] que están funcionando en el ámbito territorial de guifi.net están en período de prueba de implementación de esta forma de atribución de IPv6.''

== IPv6 en otras comunidades inalámbricas ==
La comunidad inalámbrica italiana [[Ninux.org]] publicó un documento con instrucciones para implantar y migrar sus nodos a IPv6.

== Véase también ==
* [[IPv6]]
* [[Unsoloclic]]

== Referencias ==
<references />

== Enlaces externos ==
* http://blog.ninux.org/2012/08/30/ipv6-in-free-networks/
* http://www.codigosur.org/article/ipv6-en-redes-libres-la-experiencia-de-ninux/

[[Categoría:IPv6]]

Criterios de asignación de direcciones IPv6

2014-02-19T20:49:43Z

Al: /* Desarrollo alternativo depurándose */

Actualmente, la gran mayoría de nodos de la red Guifi.net solo funcionan bajo IPv4. Una excepción son algunas de las zonas [[mesh]], especialmente las que funcionan con el firmware [[qMp]] y [[Altermesh]], ya que éstos configuran el uso de IPv6 por defecto.

La migración se tendrá que hacer obligatoriamente en un futuro, es a la vez es algo delicado que supone un reto y un deseo. Esta migración requiere un estudio de la topología de la red y una nueva política de asignación de rangos IPv6 para los nodos y las zonas. Una vez definida la política, habría que continuar con la adaptación de la utilidad [[unsoloclic]] para soportar la configuración automática de los nodos. Por último, hay que proporcionar un mecanismo sencillo para que los administradores de nodos puedan migrar a IPv6 sin perder conectividad.

La web de http://guifi.net en cambio, sí que es accesible a través de [[IPv6]].

== Propuestas y desarrollo actual ==
La propuesta pública inicial<ref>Proyecto propuesto en el [http://bcnproject.com/forums/topic/modificar-la-interfaz-web-de-guifi-net-para-que-otorgue-rangos-ipv6/ Catalunya Dades Weekend]</ref> es que estas IPs sean IPv6 globales basadas en las IPv4 actualmente distribuidas (por ejemplo utilizando los dígitos de IPv4 como los cuatro últimos grupos de cuatro dígitos hexadecimales de IPv6), así la migración no resulta traumática.

=== Propuesta inicial en proceso de aceptación ===
En la propuesta inicial el desarrollo utiliza un <code>/40</code> del rango IPv6 de guifi.net <code>2a00:1508:0a00::/40</code> (equivalente a 1/256 parte del rango total de Guifi.net, que es <code>2a00:1508::/32</code>).

La conversión de IPv4 de Guifi.net a IPv6 se hacía a partir de esta fórmula: https://gitorious.org/guifi/drupal-guifi/commit/17f15de8f105410e22cd7ec52e752207d103f16a

Y el resultado en test es accesible en http://guifi.gfi (actualmente sólo desde dentro de la red de guifi IPv4, precisamente hasta que arreglemos este asunto).

=== Desarrollo alternativo depurándose ===
En el desarrollo alternativo la propuesta utiliza tan sólo el que otorga [[Código Sur]] a [[Librenet6]]: <code>2a00:1508:1:f000::/52</code>. Entran 4096 x /64.

Es decir los tres primeros grupos y el primer dígito del cuarto grupo es fijo.

El resto de los dígitos hexadecimales de IPv6 van rellenados con los siguientes datos:
==== Para nodos de Libre-mesh ====
Librenet6 IPv4adaptCIDR-16MAC
2a00:1508:1:ffff:ffff:xxxx:xxxx:xxxx/64

Se aprovechan todos los dígitos de la siguiente manera:
* <code>fff:fff</code> adaptación a hexadecimal de los tres últimos octetos (''bytes'') de la IPv4 de Guifi.net (el primer octeto es el 10 o el 172 y se puede eludir).
* <code>f</code> CIDR menos 16: adaptación a hexadecimal de la máscara, se le resta 16 para que quepa en un sólo digito hexadecimal (la máscara en guifi.net siempre es mayor de 16).
* <code>xxxx:xxxx:xxxx</code> dirección [[MAC]] de la interfaz de red. Al ponerla completa nos garantizamos que sea siempre un número único, que sepamos la MAC completa del router a partir de la su IP.
* <code>/64</code> la máscara siempre es un /64

Esta propuesta necesita unos cuantos ajustes para que realmente quepan todos los nodos.

==== Para clientes de esos nodos ====
Los clientes que cuelgan de esos nodos tendrán la siguiente representación, basada en la anterior:
Librenet6 IPv4adapt MAC
2a00:1508:1:ffff:xxxx:xxxx:xxxx:xxxx/64

Se aprovechan todos los dígitos de la siguiente manera:
''en desarrollo''

==== Ejemplos ====
''en desarrollo''

''Nota: Las zonas [[Libre-mesh]] que están funcionando en el ámbito territorial de guifi.net están en período de prueba de implementación de esta forma de atribución de IPv6.''

== IPv6 en otras comunidades inalámbricas ==
La comunidad inalámbrica italiana [[Ninux.org]] publicó un documento con instrucciones para implantar y migrar sus nodos a IPv6.

== Véase también ==
* [[IPv6]]
* [[Unsoloclic]]

== Referencias ==
<references />

== Enlaces externos ==
* http://blog.ninux.org/2012/08/30/ipv6-in-free-networks/
* http://www.codigosur.org/article/ipv6-en-redes-libres-la-experiencia-de-ninux/

[[Categoría:IPv6]]

Criterios de asignación de direcciones IPv6

2014-02-19T20:47:07Z

Al: /* Propuestas y desarrollo actual */

Actualmente, la gran mayoría de nodos de la red Guifi.net solo funcionan bajo IPv4. Una excepción son algunas de las zonas [[mesh]], especialmente las que funcionan con el firmware [[qMp]] y [[Altermesh]], ya que éstos configuran el uso de IPv6 por defecto.

La migración se tendrá que hacer obligatoriamente en un futuro, es a la vez es algo delicado que supone un reto y un deseo. Esta migración requiere un estudio de la topología de la red y una nueva política de asignación de rangos IPv6 para los nodos y las zonas. Una vez definida la política, habría que continuar con la adaptación de la utilidad [[unsoloclic]] para soportar la configuración automática de los nodos. Por último, hay que proporcionar un mecanismo sencillo para que los administradores de nodos puedan migrar a IPv6 sin perder conectividad.

La web de http://guifi.net en cambio, sí que es accesible a través de [[IPv6]].

== Propuestas y desarrollo actual ==
La propuesta pública inicial<ref>Proyecto propuesto en el [http://bcnproject.com/forums/topic/modificar-la-interfaz-web-de-guifi-net-para-que-otorgue-rangos-ipv6/ Catalunya Dades Weekend]</ref> es que estas IPs sean IPv6 globales basadas en las IPv4 actualmente distribuidas (por ejemplo utilizando los dígitos de IPv4 como los cuatro últimos grupos de cuatro dígitos hexadecimales de IPv6), así la migración no resulta traumática.

=== Propuesta inicial en proceso de aceptación ===
En la propuesta inicial el desarrollo utiliza un <code>/40</code> del rango IPv6 de guifi.net <code>2a00:1508:0a00::/40</code> (equivalente a 1/256 parte del rango total de Guifi.net, que es <code>2a00:1508::/32</code>).

La conversión de IPv4 de Guifi.net a IPv6 se hacía a partir de esta fórmula: https://gitorious.org/guifi/drupal-guifi/commit/17f15de8f105410e22cd7ec52e752207d103f16a

Y el resultado en test es accesible en http://guifi.gfi (actualmente sólo desde dentro de la red de guifi IPv4, precisamente hasta que arreglemos este asunto).

=== Desarrollo alternativo depurándose ===
En el desarrollo alternativo la propuesta utiliza tan sólo el rango otorgado a Código Sur: <code>2a00:1508:1:f000::/52</code>. Entran 4096 x /64.

Es decir los tres primeros grupos y el primer dígito del cuarto grupo es fijo.

El resto de los dígitos hexadecimales de IPv6 van rellenados con los siguientes datos:
==== Para nodos de Libre-mesh ====
Librenet6 IPv4adaptCIDR-16MAC
2a00:1508:1:ffff:ffff:xxxx:xxxx:xxxx/64

Se aprovechan todos los dígitos de la siguiente manera:
* <code>fff:fff</code> adaptación a hexadecimal de los tres últimos octetos (''bytes'') de la IPv4 de Guifi.net (el primer octeto es el 10 o el 172 y se puede eludir).
* <code>f</code> CIDR menos 16: adaptación a hexadecimal de la máscara, se le resta 16 para que quepa en un sólo digito hexadecimal (la máscara en guifi.net siempre es mayor de 16).
* <code>xxxx:xxxx:xxxx</code> dirección [[MAC]] de la interfaz de red. Al ponerla completa nos garantizamos que sea siempre un número único, que sepamos la MAC completa del router a partir de la su IP.
* <code>/64</code> la máscara siempre es un /64

Esta propuesta necesita unos cuantos ajustes para que realmente quepan todos los nodos.

==== Para clientes de esos nodos ====
Los clientes que cuelgan de esos nodos tendrán la siguiente representación, basada en la anterior:
Librenet6 IPv4adapt MAC
2a00:1508:1:ffff:xxxx:xxxx:xxxx:xxxx/64

Se aprovechan todos los dígitos de la siguiente manera:
''en desarrollo''

==== Ejemplos ====
''en desarrollo''

''Nota: Las zonas [[Libre-mesh]] que están funcionando en el ámbito territorial de guifi.net están en período de prueba de implementación de esta forma de atribución de IPv6.''

== IPv6 en otras comunidades inalámbricas ==
La comunidad inalámbrica italiana [[Ninux.org]] publicó un documento con instrucciones para implantar y migrar sus nodos a IPv6.

== Véase también ==
* [[IPv6]]
* [[Unsoloclic]]

== Referencias ==
<references />

== Enlaces externos ==
* http://blog.ninux.org/2012/08/30/ipv6-in-free-networks/
* http://www.codigosur.org/article/ipv6-en-redes-libres-la-experiencia-de-ninux/

[[Categoría:IPv6]]

Criterios de asignación de direcciones IPv6

2014-02-19T02:28:06Z

Al: /* Clientes */

Actualmente, la gran mayoría de nodos de la red Guifi.net solo funcionan bajo IPv4. Una excepción son algunas de las zonas [[mesh]], especialmente las que funcionan con el firmware [[qMp]] y [[Altermesh]], ya que éstos configuran el uso de IPv6 por defecto.

La migración se tendrá que hacer obligatoriamente en un futuro, es a la vez es algo delicado que supone un reto y un deseo. Esta migración requiere un estudio de la topología de la red y una nueva política de asignación de rangos IPv6 para los nodos y las zonas. Una vez definida la política, habría que continuar con la adaptación de la utilidad [[unsoloclic]] para soportar la configuración automática de los nodos. Por último, hay que proporcionar un mecanismo sencillo para que los administradores de nodos puedan migrar a IPv6 sin perder conectividad.

La web de http://guifi.net en cambio, sí que es accesible a través de [[IPv6]].

== Propuestas y desarrollo actual ==
La propuesta pública inicial<ref>Proyecto propuesto en el [http://bcnproject.com/forums/topic/modificar-la-interfaz-web-de-guifi-net-para-que-otorgue-rangos-ipv6/ Catalunya Dades Weekend]</ref> es que estas IPs sean IPv6 globales basadas en las IPv4 actualmente distribuidas (por ejemplo utilizando los dígitos de IPv4 como los cuatro últimos grupos de cuatro dígitos hexadecimales de IPv6), así la migración no resulta traumática.

=== Propuesta inicial no aceptada ===
En la propuesta inicial que no fue aceptada el desarrollo utilizaba todo el rango IPv6 de guifi.net, es decir, <code>2a00:1508::/32</code>

La conversión de IPv4 de Guifi.net a IPv6 se hacía a partir de esta fórmula: https://gitorious.org/guifi/drupal-guifi/commit/17f15de8f105410e22cd7ec52e752207d103f16a

=== Desarrollo alternativo ===
En el desarrollo alternativo la propuesta utiliza tan sólo el rango otorgado a Código Sur: <code>2a00:1508:1:f000::/52</code>. Entran 4096 x /64.

Es decir los tres primeros grupos y el primer dígito del cuarto grupo es fijo.

El resto de los dígitos hexadecimales de IPv6 van rellenados con los siguientes datos:
==== Para nodos de Libre-mesh ====
Librenet6 IPv4adaptCIDR-16MAC
2a00:1508:1:ffff:ffff:xxxx:xxxx:xxxx/64

Se aprovechan todos los dígitos de la siguiente manera:
* <code>fff:fff</code> adaptación a hexadecimal de los tres últimos octetos (''bytes'') de la IPv4 de Guifi.net (el primer octeto es el 10 o el 172 y se puede eludir).
* <code>f</code> CIDR menos 16: adaptación a hexadecimal de la máscara, se le resta 16 para que quepa en un sólo digito hexadecimal (la máscara en guifi.net siempre es mayor de 16).
* <code>xxxx:xxxx:xxxx</code> dirección [[MAC]] de la interfaz de red. Al ponerla completa nos garantizamos que sea siempre un número único, que sepamos la MAC completa del router a partir de la su IP.
* <code>/64</code> la máscara siempre es un /64

==== Para clientes de esos nodos ====
Los clientes que cuelgan de esos nodos tendrán la siguiente representación, basada en la anterior:
Librenet6 IPv4adapt MAC
2a00:1508:1:ffff:xxxx:xxxx:xxxx:xxxx/64

Se aprovechan todos los dígitos de la siguiente manera:
''en desarrollo''

==== Ejemplos ====
''en desarrollo''

''Nota: Las zonas [[Libre-mesh]] que están funcionando en el ámbito territorial de guifi.net están en período de prueba de implementación de esta forma de atribución de IPv6.''

== IPv6 en otras comunidades inalámbricas ==
La comunidad inalámbrica italiana [[Ninux.org]] publicó un documento con instrucciones para implantar y migrar sus nodos a IPv6.

== Véase también ==
* [[IPv6]]
* [[Unsoloclic]]

== Referencias ==
<references />

== Enlaces externos ==
* http://blog.ninux.org/2012/08/30/ipv6-in-free-networks/
* http://www.codigosur.org/article/ipv6-en-redes-libres-la-experiencia-de-ninux/

[[Categoría:IPv6]]