Ninux.org Wireless Community

Dopo molti anni di duro lavoro, il 15 Novembre 2013 Ninux-roma si è collegata al NaMeX per avviare una sperimentazione che sta cominciando ad entrare a pieno regime proprio in questi giorni.

Questo è un evento molto importante per Ninux perchè sancisce il parziale raggiungimento del traguardo di uno tra i più importanti obiettivi dichiarati nel nostro manifesto, ovvero “costruire un’infrastruttura di rete che punti a divenire una parte integrante di Internet”.

Cos’è il NaMeX?

Il NaMeX è un Internet Exchange Point, anche conosciuto come Neutral Access Point.

Ma cos’è un Internet Exchange Point o NAP?

Non c’è un organismo che controlli Internet nella sua interezza. Una rete può essere costruita collegando tra loro dei computer da chiunque abbia le competenze per farlo. Internet quindi è l’interconnessione a livello globale tra moltissime reti, grandi e piccole. Per favorire queste interconnessioni esistono dei luoghi in cui le reti si possono collegare fisicamente con molte altre reti in un colpo solo: gli Internet Exchange Point.

Il NaMeX è un Internet Exchange Point senza fini di lucro situato a Roma, al quale sono collegati più di 50 reti . Tra queste, da qualche settimana, c’è anche Ninux! Siamo stati accettati come membri in via sperimentale, grazie ad alcuni fattori.

Quali fattori ci hanno permesso di collegarci?

Innanzitutto, la crescita esponenziale del fenomeno delle community network in tutto il mondo ed in particolare in Europa le sta facendo riconoscere come il quinto tipo di rete: dopo quelle (in ordine cronologico) militari, accademiche, commerciali e municipali stanno emergendo le reti costruite e gestite dal basso (o Bottom Up Broadband – BuB).

Progetti di ricerca europei incentrati sulle community network, quali CONFINE e CLOMMUNITY, e conferenze di livello internazionale come Community Network Broadband 2013, International Summit for Community Wireless Networks e Battlemesh legittimano ed incentivano questo tipo di iniziative.

Ninux.org già da moltissimi anni collabora ed interagisce con le community network europee: molti eventi di carattere tecnico sono stati co-partecipati e co-organizzati nella scorsa decade, creando di fatto un movimento a livello continentale, unito dai prinicipi del Wireless Common Manifesto e caratterizzato da pratiche riprese dal mondo del software libero ed open source (FOSS), con intensi scambi di idee, riportate nel mondo del networking IP, tra l’altro già orientato ad un’estrema apertura fin dalla nascita. In questo contesto, alcuni dispositivi utilizzati per il progetto di ricerca CONFINE sono già ospitati all’interno della rete Ninux.

Un esperimento collettivo

La rete Ninux è stata oggetto di studi accademici in quanto la topologia e statistiche di traffico sono resi pubblici a chiunque voglia studiare, analizzare e sperimentare su una rete mesh reale.

In più Ninux Roma ha buoni rapporti con i suoi vicini. Alcuni provider supportano il nostro progetto in vari modi. Siamo interconnessi (in ordine cronologico) ad Ydea, Unidata ed Airmax Italia.

Grazie ad Unidata le nostre case sono tra le poche in Italia a potersi vantare di avere connettività IPv6 nativa. Le motivazioni che spingono questi operatori ad aiutarci sono legate alla nostra apertura alla sperimentazione di nuove tecnologie e alla loro lungimiranza, in modo simile a quanto avviene già nell’interazione tra la comunità del free software e varie aziende.

Don’t connect to the Internet, become the Internet!

Ninux

After publishing the document on the ninux Roma architecture prepared for the World IPv6 Launch we were asked by the Codigosur folks to write an article about our experience with IPv6. Originally written in English, has been translated to Spanish and published on the online magazine pillku:

http://codigosur.org/article/ipv6-en-redes-libres-la-experiencia-de-ninux/

English version follows:

Ninux.org is a community network movement started around the year 2001 in Rome and now spreading all over Italy. The main idea is to create computer networks built by the users, with no central ownership or management, as opposed to traditional Internet service providers (ISPs), in which a single entity owns and manages the network.

Providing connections to the Internet is not a primary objective in community networks, as the main goal is the direct interconnection between the community members that can share, phone, chat, play among them without mediators. This type of networks are common all over the World: from guifi.net in Catalunya to SeattleWireless in the U.S.A. or Air Stream Wireless in Australia. The technology that prevails is Wi-Fi, because wireless routers are easy to deploy on the roofs to connect with neighboring buildings, and also because it is cheap, allowing for the inclusion of a large number of people.

While building our network in Rome we came across some friendly ISPs that liked the ninux.org project and wanted to collaborate. We got to know Ydea in the early days, and this wireless ISP has grown with us, recognizing that ninux.org’s aims are not in conflict with theirs, exchanging continuously ideas and know-how, and donating hardware to the community.

Another friendly ISP that we met along the way is Unidata. When we talked to them they were enthusiastic about our project and willing to help us, but we didn’t find any practical way to collaborate, until we got involved in the Battlemesh. This is an event in which community network members, developers and networking enthusiasts from all over the World meet for a few days, build a temporary wireless network and find which is the best routing protocol, i.e. the best software that runs on wireless routers and that is able to reconfigure automatically a network in case of faults. We wanted to organize the Italian edition of this event in a camping on the shore of the Bracciano lake, near Rome, but the problem was that there was no Internet connection, and we surely could not host such a nerdy event without a reliable and fast connection to the Internet. Thankfully Unidata offered to sponsor the event by providing us a free and fast connection for the duration of the Battlemesh (that, by the way, was a great success). This strengthened our ties and led to an important collaboration between them and ninux.org, that is IPv6 experimentation.

All the devices (PCs, phones, tablets) that access the Internet need to have what is called an IP address in order to communicate with other devices (e.g. servers), and each device should have a World-unique IP address. You can think of it as a telephone number, but with a fixed number of digits. In the days when the Internet was a small interconnection of the universities’ networks, the IP (more specifically IPv4, where “v4” stands for “version 4”) addresses seemed to be more than enough, but then something unexpected happened: more and more organizations joined the Internet, making it bigger and bigger, using it for business and commerce and involving increasingly more users and thus consuming more and more IP addresses. So it became evident that something had to be done to cope with the IPv4 address exhaustion or “IPcalypse” problem. The most notable proposals in this direction are NAT and IPv6.

NAT stands for Network Address Translation and allows the use of a single IP address for thousands of devices. Its main drawback is that it creates a hierarchy between computers that can both access and provide what are called “services” (i.e. Web pages, e-mail accounts, etc) and computers that can only access these services as clients. This transforms the Internet from a “peer to peer” network, in which all devices can provide and access services, to something that resembles traditional broadcast media (e.g. TV), in which there is a distinction between producers and consumers. This does not mean that NAT users are not able to post on Web pages such as blogs or social networks or send e-mails, but it means that they cannot usually host these services directly on their computers.

NAT also breaks the end-to-end principle, which states that in order for a network such as the Internet to work well, all the “intelligence” should be on the end devices while the network should be “dumb” and neutral, i.e. it should not discriminate between types of traffic.

The main idea behind IPv6 (IP version 6) is instead to replace the old IP (v4) addresses with larger addresses, allowing for billions of billions of billions of billions of them, and thus no need for NAT, preserving the horizontality of the Internet. The major drawback is that is that IPv6 addresses are not directly compatible with IPv4 addresses and so the whole World should switch to IPv6. This is not an easy task, as there is no organization owning or managing the whole Internet, but, as the name “Inter-net” suggests, it is an interconnection of autonomous networks, each network belonging to a different entity (universities, companies, non-profit organizations, governments, etc). Another thing that slows down IPv6 adoption is that there is not much know-how out there about how to run IPv6 networks in a reliable and safe way.

But time is running out: no more IPv4 addresses are available in Asia since April 2011, and the rest of the World will follow before the end of 2014. For this many organizations, including big players such as Google, Facebook and Yahoo!, are pushing for IPv6 adoption by adhering to events such as the World IPv6 Launch.

So, going back to the collaboration with Unidata, the idea was that they would provide our community free access to the IPv6 Internet if we were willing to play and experiment with it and spread the acquired knowledge on the Web. As experimentation has always been one of our drivers, we accepted enthusiastically and began by installing a wireless router on top of the building that hosts the Unidata servers. Then we needed what is called an “IPv6 address block”, that is a set of IPv6 addresses assigned to an organization. For this task we asked for help to our friends at Ydea, which were successful (also thanks to Fusolab, the association of which ninux.org is an active part) after going through the labyrinths of bureaucracy. So we upgraded our network to support IPv6 along with IPv4 and started choosing our own IPv6 addresses out of our block. While IPv4 addresses are represented using quite boring numbers separated by dots (e.g. 78.47.245.242), IPv6 addresses are represented using also letters from a to f (e.g. 2a03:2880:2110:3f03:face:b00c:: – guess who is the owner). This allowed for some nerd fun by putting words such as ‘cafe’, ‘beef’, ‘b055’ (not to report the bad words) inside our addresses.

Along with the IPv6 address block we obtained also what is called an Autonomous System Number (ASN). This is used by an autonomous network that is part of the Internet to link to other peer networks. So we can say that we are not connected to the Internet but that we are the Internet.

This experimentation has been very successful and we are among the firsts in Italy to have IPv6 at our homes. This is a double success if we think that we are using our own network, built by us, and that we are providing the IPv6 addresses ourselves.

Meddle TV ha pubblicato il video girato al Fusolab 2.0 in occasione dell’IPv6 world launch. Gabriella Paolini di GARR è venuta a trovare i ragazzi di Ninux per raccontare il suo punto di vista e la sua esperienza con il protocollo IPv6. Una serata piacevole dove alla fine dell’intervento di Gabriella i ragazzi di Ninux hanno lanciato in cielo delle mongolfiere, come un simbolico lancio dell’IPv6 in tutto il mondo.

buona visione

Saverio

Download this press release in pdf from here

Download here the Ninux Roma Routing Architecture -Version 0

Introduction

A few months ago we published a graph on our homepage that shows in real time the last 24 hours of the bandwidth usage of our main IPv6 peering link.

We started our IPv6 deployment in March 2011. Unidata, an ISP operating in the area of Rome (Italy), offered us the chance to make an IPv6 BGP peering providing to us free transit to the public Internet (IPv6 only).

We accepted immediately this chance to experiment with IPv6, as since the beginning of our community network, making experiments with new technology has been a leading factor.

We already had a private peering with Ydea.com, to route a few IPv4 addresses we used for mail servers and other lightweight services. To set up the second peering we started to think of the new network architecture and we faced how to pay the necessary resources.

In the early days of Ninux we started “playing” with wireless equipment together with Iacopo Iacarelli, the owner of Ydea.com. Our stories are different, because Ydea.com is a wireless ISP and we are a community network, but our relationship grew bigger and bigger over time, so he was very happy to help us out by giving us some useful tips to deal with the LIR, a required step to obtain the necessary resources.

We first upgraded our private peering with Ydea.com to a public peering, once our public AS number was registered at RIPE.

The 8th of April 2011 we installed our antenna on the roof of the Unidata PoP located in the eastern suburbs of Rome. We installed our second BGP router, a Linux Server running Quagga (the hardware was kindly offered by Unidata).

The 24th of May 2011 we had our IPv6 address block 2001:4c00:893b::/48 ready to use.

To make sure it all worked well we moved by little steps. At Ninux we don’t have a vendor that provides hardware and software upgrades, like it happens with large scale ISPs. We have a software team that builds firmware on top of devices. Firmware are open source like in Pisa (OpenWRT firmware) or based on some vendor product that has an available SDK, as in Rome where we use AirOS by Ubiquiti.

Because we were not sure that the new firmware was stable enough, at first we upgraded just a few nodes to connect the Ninux Farm to the BGP router at the edge of the network. The upgrade of this 4 nodes was not critical for the whole network, and it was a perfect test playground to generate enough traffic.

You can see the nodes involved in the first experiment on our mapserver at these links:

http://map.ninux.org/select/ninuxfarm/

http://map.ninux.org/select/tecnopolo/

http://map.ninux.org/select/fishsupernode/

Problems

We started working to provide native IPv6 access to the servers in the Ninux Server Farm, and we faced the first problems.

The hardest problem we faced was to have IPv6 support on our backbone devices. The Ninux.org backbone runs mostly on Ubiquiti devices of the M-Series. Running OpenWRT on these devices would give total IPv6 support, however the open source drivers coming with OpenWRT are not as stable as the proprietary ones embedded in the AirOS firmware, leading to poor performances when using OpenWRT.

Using the AirOS SDK we developed ourselves our own IPv6 solution, but we couldn’t get something really stable until  the end of september.

We had to face some problems, because Ubiquiti is very fast in releasing new firmware versions when there is a bug, but the SDK release is somehow delayed. So to speed up testing and development, in August we had to reverse engineer their latest firmware.

After a lot of work we have now a stable firmware 🙂

We published here the patches to apply on top of the Ubiquiti SDK to have a IPv6 OLSR router:

https://github.com/ninuxorg/UbntM5AirOsOLSR/tree/master/patches/AirOS5.3.3

Stateless addresses

When starting with IPv6 you have to give IPv6 addresses to the devices of your network. We had a /48 to be partitioned.

IPv6 gives enough room for messy address management without easily run into a collision of addresses. At first we used a wiki page, and everybody was taking note of the /64 used for his home.

The easier way to deliver an IP address to the end users was using radvd directly on the OLSR routers. However we had a lot of flaps because the routers were changing IP addresses. Soon we realized that we had to disable routing advertisements on routers that had already a manually configured IPv6 address.

echo 0 > /proc/sys/net/ipv6/conf/all/accept_ra

BGP and IGP

The Ninux network in Rome had just IPv4 private addresses. The routing protocol used is OLSR. Connecting to the big Internet we started to identify OLSR as our IGP protocol. We upgraded the network to run in dual stack IPv4 and IPv6, so running two instances of the OLSR protocol. After configuring some stuff without a real plan, we started to write a real routing architecture, that you can find now on our web site.

When you have only one peering point with a single upstream provider, it is enough to redistribute via BGP to your upstream a static route that matches all your address space. But if you have different peering points in your network, then you need to redistribute IGP routers to BGP to understand what is really reachable and should be announced.

This was not trivial, because we use OLSR as IGP routing protocol, and the integration with Quagga is still experimental. We are still testing Quagga version 0.99.21 with this patch https://dev.openwrt.org/browser/packages/net/quagga/patches/120-quagga_manet.patch

Public Services

We are very happy to run a network that is ready for IPv6. Our users are using IPv6 services since several months, and we expect this traffic to increase the 6th of June 2012.

In addition to normal IPv6 Internet access we also set up some IPv6 services for our community members and for the all Internet:

• Jabber XMPP server: A Jabber server running ejabberd is available with both public ipv6 and ipv4 address at jabber.ninux.org. The server is federated with the rest of the XMPP network and has proven a useful service for our community.
  More information (in Italian) can be found here: http://wiki.ninux.org/Jabber.
• Openarena: Openarena is a first person shooting game based on the open sourced quake3 engine. An Openarena server is available at cleopatra.ninux.org:27960.
  More information (in Italian) can be found here: http://wiki.ninux.org/openarena_it.
• Mumble server: Mumble is an open source low latency voice chat software that is really useful for quick conferences.
  The server has public IPv6 2001:4c00:893b:f2::2 and is reachable at port 64738.
  More information (in Italian) can be found here: http://wiki.ninux.org/Mumble.
• Owncloud: Owncloud is an open source web application built in php that offers dropbox-like functionalities, we use it successfully to store documentation of our activities, like photos taken while building nodes or videos recorded at our events. We don’t use it only internally, infact we also allow other people who are not yet connected to our network to send us data: we often ask newcomers to send us photos of their roof in order to understand if we can connect them to any of our nodes and we give them access to our owncloud server to upload the photos easily. It has proved to be an useful and reliable service for our community.The server is reachable at https://obelix.ninux.org/owncloud/ with public ipv6 2001:4c00:893b:fa:230:48ff:fe73:53d.

Conclusion

The Ninux network is now ready for IPv6. Once we fixed the problems described in this document we updated all the nodes of the network. We have now 139 prefixes of size /64 active in our network. To the best of our knowledge we are one of the first Italian networks to deliver native IPv6 access to the home of Internet users.

After 1 year of testing and developing we feel ready for the world IPv6 day, and we are very proud of our experimentation done in a completely no profit way in the spirit of free and open source software.

We hope to see our IPv6 traffic increase on June the 6th !

We want to thank our upstream providers, Unidata, Ydea and E4A. We are very happy to cooperate with experienced companies that have worked for many years in the field of networking, it is a fantastic example of how the open source community can create chances for cooperation and innovation.

Hello world !

grazie a Maurizio adesso abbiamo un server DNS per la zona ipv6.ninux.org. L’IP del server è 2001:4c00:893b:43::250 e funziona popolando la zona DNS in base alle informazioni che i ragazzi della rete Ninux mettono sul database del map server comunitario.

Finalmente non dobbiamo scrivere più lunghissimi indirizzi IPv6 a mano, ed inoltre visto che funziona anche il reverse lookup, possiamo fare dei traceroute dove i nomi dei nodi hanno un significato !

L’ottimo lavoro di Maurizio non è solo tecnico, ma anche di documentazione. Di seguito un video da non perdere. Vi consiglio di aprirlo su youtube in HD.