Anforderungen: Unterschied zwischen den Versionen

Aus Freifunk Köln, Bonn und Umgebung
Zur Navigation springen Zur Suche springen
KKeine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 1: Zeile 1:
Hier soll eine Sammlung der Anforderungen, die wir unterstützen wollen entstehen:
Hier soll eine Sammlung der Anforderungen, die wir unterstützen wollen entstehen:


* Aus dem Netz soll das Internet erreichbar sein. Das Netz soll mindestens einen leistungsfähigen Exit-Node in das Internet besitzen.
== Funktionale Anforderungen  ==
* Alle Nodes des Netzes sollen direkt oder indirekt (indirekt bedeutet: "per uplink getunnelt über andere Netze") miteinander verbunden sein.
 
* Das Netz soll in der Lage sein mehrere hundert Nodes und mehrere Regionen zu beinhalten.
=== Nutzer-/Klientensicht ===
* Das Netz soll so gestaltet werden, dass ein nahtloser Ausbau von wenigen Nodes auf viele Nodes möglich ist.
''Aus der Sicht eines Endnutzers...''
* Die Clients sollen sich per IP4 DHCP verbinden können, um ältere Hardware zu unterstützen.
 
* Die Nodes sollen sich per IP6 verbinden.
# Das Netz verbindet Wireless-Lan-Hardware (nach IEEE 802.11 b/g) seiner Teilnehmer
* Das Netz soll so gestaltet sein, dass die Verantwortung für Handlungen beim Client-Anwender verbleiben, und der Nodebetreiber lediglich Infrastrukturbetreiber ist.
# Die Teilnahme am Netz ist ohne Installation zusätzlicher Software auf jedem Endgeräten möglich.
* automatische updates des Nodes?
# Das Netz bindet alle Teilnehmer an das Internet und das World Wide Web an.
* was soll noch funktionieren, wenn das routing des exit-node ausfällt?
# Das Netz ermöglicht einen zum Internet analogen Datenaustausch zwischen allen Teilnehmern
# Das Netz informiert die Teilnehmer über sich und stellt seine Dokumentation offen zur Verfügung
Ggf ''(Diskussion)''
# Das Netz bietet Roaming zwischen sich überlappenden Zellen
# Das Netz schützt den Internetverkehr seiner Teilnehmer vor Sniffing im Netz (würde dann VPN zum Endpunkt bedeuten)
# Mehrere hundert Endnutzer können am Netz teilnehmen.
 
=== Betreibersicht ===
''Aus Sicht derer, die Accesspoints haben...''
# Der Betrieb erfolgt sicher und getrennt von (ggf. vorhandenen) eigenen Netzen. Keine privaten Daten sind aus dem Netz abrufbar.
# Der Abuse wird nicht über den Betreiber abgewickelt. Er erscheint im Internet nicht als Absender der Datenpakete, die er abwickelt. Ansprechpartner für Abmahnungen / Polizeit, etc. ist der CCC.
# Der Betrieb des Accesspoints beeinträchtigt die eigene Internet-Verbindung nicht wesentlich. Falls gewünscht kann der Betreiber einstellen, welche Bandbreite er dem Freifunk-Netz zu Verfügung stellt.
# Der Betreiber muss den Node nicht konfigurieren.
# Der Betreiber hat die Möglichkeit, alle Einstellungen seines APs vollständig anzupassen, verliert damit aber u.U. die Kompatibilität zum Netz.
 
== Nicht-funktionale Anforderungen ==
# Das Netz wird über eine zentrale Gateway-Struktur mit dem Internet verbunden
# Die Anbindung ist redundant ausgelegt.
# Eine direkte Ende-zu-Ende Kommunikation mit IPv4 und IPv6 ist zwischen allen Teilnehmern mögglich.
# Das Netz skaliert
# Die Konfiguration der Endgeräte erfolgt via DHCP und IPv6 auto konfiguration. (Dual-Stack)
# Auch ohne Dual-Stack (also ausschl. IPv4 oder IPv6) ist das Netz ohne Einschränkung nutzbar
# Node-Konfigurationen (Firmware-Images & Pakete) werden zentral zur Verfügung gestellt.
 
Ggf.
# Konfigurations-Management für die Nodes: Die Konfiguration aller Nodes liegt zentral in einem Repository und wird bei Bedarf (Änderungen) automatisch an alle Nodes deployed. Dabei ist sicher gestellt, dass im Fehlerfall jeder Node auf die letzte, funktionierende Konfiguration zurückfällt.

Version vom 23. März 2011, 18:11 Uhr

Hier soll eine Sammlung der Anforderungen, die wir unterstützen wollen entstehen:

Funktionale Anforderungen

Nutzer-/Klientensicht

Aus der Sicht eines Endnutzers...

  1. Das Netz verbindet Wireless-Lan-Hardware (nach IEEE 802.11 b/g) seiner Teilnehmer
  2. Die Teilnahme am Netz ist ohne Installation zusätzlicher Software auf jedem Endgeräten möglich.
  3. Das Netz bindet alle Teilnehmer an das Internet und das World Wide Web an.
  4. Das Netz ermöglicht einen zum Internet analogen Datenaustausch zwischen allen Teilnehmern
  5. Das Netz informiert die Teilnehmer über sich und stellt seine Dokumentation offen zur Verfügung

Ggf (Diskussion)

  1. Das Netz bietet Roaming zwischen sich überlappenden Zellen
  2. Das Netz schützt den Internetverkehr seiner Teilnehmer vor Sniffing im Netz (würde dann VPN zum Endpunkt bedeuten)
  3. Mehrere hundert Endnutzer können am Netz teilnehmen.

Betreibersicht

Aus Sicht derer, die Accesspoints haben...

  1. Der Betrieb erfolgt sicher und getrennt von (ggf. vorhandenen) eigenen Netzen. Keine privaten Daten sind aus dem Netz abrufbar.
  2. Der Abuse wird nicht über den Betreiber abgewickelt. Er erscheint im Internet nicht als Absender der Datenpakete, die er abwickelt. Ansprechpartner für Abmahnungen / Polizeit, etc. ist der CCC.
  3. Der Betrieb des Accesspoints beeinträchtigt die eigene Internet-Verbindung nicht wesentlich. Falls gewünscht kann der Betreiber einstellen, welche Bandbreite er dem Freifunk-Netz zu Verfügung stellt.
  4. Der Betreiber muss den Node nicht konfigurieren.
  5. Der Betreiber hat die Möglichkeit, alle Einstellungen seines APs vollständig anzupassen, verliert damit aber u.U. die Kompatibilität zum Netz.

Nicht-funktionale Anforderungen

  1. Das Netz wird über eine zentrale Gateway-Struktur mit dem Internet verbunden
  2. Die Anbindung ist redundant ausgelegt.
  3. Eine direkte Ende-zu-Ende Kommunikation mit IPv4 und IPv6 ist zwischen allen Teilnehmern mögglich.
  4. Das Netz skaliert
  5. Die Konfiguration der Endgeräte erfolgt via DHCP und IPv6 auto konfiguration. (Dual-Stack)
  6. Auch ohne Dual-Stack (also ausschl. IPv4 oder IPv6) ist das Netz ohne Einschränkung nutzbar
  7. Node-Konfigurationen (Firmware-Images & Pakete) werden zentral zur Verfügung gestellt.

Ggf.

  1. Konfigurations-Management für die Nodes: Die Konfiguration aller Nodes liegt zentral in einem Repository und wird bei Bedarf (Änderungen) automatisch an alle Nodes deployed. Dabei ist sicher gestellt, dass im Fehlerfall jeder Node auf die letzte, funktionierende Konfiguration zurückfällt.