Benutzer:Lars/Blog:2015 November 01 23:08:53 CET - Versionsgeschichte

Lars: Formatierung

2015-11-01T22:11:06Z

Formatierung

← Nächstältere Version		Version vom 1. November 2015, 22:11 Uhr
Zeile 7:		Zeile 7:
	** fluktuierendes IP-Präfix füe jeden Nutzer-AP (reduziert personifizierbare Datenspuren im Internet bei ausgehendem Verkehr)		** fluktuierendes IP-Präfix füe jeden Nutzer-AP (reduziert personifizierbare Datenspuren im Internet bei ausgehendem Verkehr)
	** (optional) dauerhaft unveränderliches Präfix für jeden Router aus dem ULA-Bereich		** (optional) dauerhaft unveränderliches Präfix für jeden Router aus dem ULA-Bereich
	*** siehe auch [http://tools.ietf.org/html/rfc6879#page-7\|RFC6879]: Verwendung von ULA-Adressen für interne Dienste, um Präfix-Änderungen (z.B. durch den/die ISPs) auszuweichen		*** siehe auch [http://tools.ietf.org/html/rfc6879#page-7 RFC6879]: Verwendung von ULA-Adressen für interne Dienste, um Präfix-Änderungen (z.B. durch den/die ISPs) auszuweichen
	* zur Umsetzung sollten möglichst viele standardkonforme Mittel genutzt werden.		* zur Umsetzung sollten möglichst viele standardkonforme Mittel genutzt werden.

Lars: Formatierung

2015-11-01T22:10:34Z

Formatierung

← Nächstältere Version		Version vom 1. November 2015, 22:10 Uhr
Zeile 4:		Zeile 4:
	=== Anforderungen ===		=== Anforderungen ===
	* bisher diskustieren wir über zwei bzw. drei Bereiche:		* bisher diskustieren wir über zwei bzw. drei Bereiche:
	## permanentes IP-Präfix für jeden Nutzer-AP (kann aus dem Internet heraus angesprochen werden)		** permanentes IP-Präfix für jeden Nutzer-AP (kann aus dem Internet heraus angesprochen werden)
	## fluktuierendes IP-Präfix füe jeden Nutzer-AP (reduziert personifizierbare Datenspuren im Internet bei ausgehendem Verkehr)		** fluktuierendes IP-Präfix füe jeden Nutzer-AP (reduziert personifizierbare Datenspuren im Internet bei ausgehendem Verkehr)
	## (optional) dauerhaft unveränderliches Präfix für jeden Router aus dem ULA-Bereich		** (optional) dauerhaft unveränderliches Präfix für jeden Router aus dem ULA-Bereich
	*** siehe auch [http://tools.ietf.org/html/rfc6879#page-7\|RFC6879]: Verwendung von ULA-Adressen für interne Dienste, um Präfix-Änderungen (z.B. durch den/die ISPs) auszuweichen		*** siehe auch [http://tools.ietf.org/html/rfc6879#page-7\|RFC6879]: Verwendung von ULA-Adressen für interne Dienste, um Präfix-Änderungen (z.B. durch den/die ISPs) auszuweichen
	* zur Umsetzung sollten möglichst viele standardkonforme Mittel genutzt werden.		* zur Umsetzung sollten möglichst viele standardkonforme Mittel genutzt werden.

Lars: init

2015-11-01T22:09:48Z

init

Neue Seite

=== IPv6-Treffen (01.11.2015) ===
Heute trafen wir uns zu unserem vierten IPv6-Treffen in diesem Jahr.

=== Anforderungen ===
* bisher diskustieren wir über zwei bzw. drei Bereiche:
## permanentes IP-Präfix für jeden Nutzer-AP (kann aus dem Internet heraus angesprochen werden)
## fluktuierendes IP-Präfix füe jeden Nutzer-AP (reduziert personifizierbare Datenspuren im Internet bei ausgehendem Verkehr)
## (optional) dauerhaft unveränderliches Präfix für jeden Router aus dem ULA-Bereich
*** siehe auch [http://tools.ietf.org/html/rfc6879#page-7|RFC6879]: Verwendung von ULA-Adressen für interne Dienste, um Präfix-Änderungen (z.B. durch den/die ISPs) auszuweichen
* zur Umsetzung sollten möglichst viele standardkonforme Mittel genutzt werden.

=== Wege der standkonformen Umsetzung===
==== Homenet ====
* es gibt IETF-Gruppe namens Homenet
* Ziel: selbständig vermaschendes Heimnetzwerk mit mehreren Netzanbindungen
* technischer Überblick: http://www.ipv6conference.ch/wp-content/uploads/Slide/Technical%20Track/T04%20-%20D%C3%B6ring-14_council_homenet_en-final.pdf
* openwrt: http://wiki.openwrt.org/doc/howto/hncp
** hnetd - https://github.com/sbyx/hnetd/
** shncpd - https://github.com/jech/shncpd
** comparance - https://www.ietf.org/proceedings/93/slides/slides-93-homenet-2.pdf
* Zusammenfassung im Opennet-Kontext:
** Löst theoretisch viele unserer Probleme (automatische Adressvergabe, Uplink Detection, Verteilung von Routen und Namen, ...)
** Ist jedoch für Heimnetze ausgelegt und es ist uns gerade nicht ganz klar wie viele zusätzliche Nachrichten durch die Nutzung von HNCP generiert und versendet werden, wenn sehr viele Router vorhanden sind.
*** der Nachrichten-Broadcast-Algorithmus scheint Informationen an alle zu verteilen - dies wurde wahrscheinlich nicht in Richtung > 100 Knoten entwickelt
** für die Konfiguration der Heimnetze (hinter dem Opennet-AP beim Nutzer) ist es wahrscheinlich gut geeignet
** Bausteine von Homenet (siehe https://github.com/sbyx/hnetd/) sind eventuell für uns nutzbar
** unklar, wie ein Routing-Protokoll (mit Link-Bewertung) integrierbar ist:

=== IP-Vergabe ===
==== AP in der Wolke ====
* grober Gedanke: lokale IP mit unserem Präfix (/64) kombiniert mit MAC und 16-Bit-Zufallszahl auswürfeln
** es ist nur eine einzige IP - also kein Präfix
** OLSRDv2 würde diese eine IP dann für all seine Interfaces selbst konfigurieren
* Kommunikation nach außen (z.B. Paket-Downloads) sind mit dieser IP natürlich nicht möglich

==== AP mit Uplink-Bedürfnis ====
* DHCP-Anfragen an Uplink-Server scheinen der richtige Weg zu sein
** statische Leases (idealerweise konfigurierbar und nicht skriptbar) durch den DHCP-Server vergeben
** dynamische Leases (privatsphärenfreundlich) idealerweise ebenfalls konfigurierbar und nicht skriptbar durch den DHCP-Server vergeben lassen
** Unicast-Anfragen (und Antworten) sind noch zu klären/prüfen
* hierbei würden wir nicht IPs, sondern Präfix erfragen (/64)

=== Zu recherchieren / ausprobieren ===
* dynamische "Präfix-Delegation" scheint mit ISC DHCP (nicht WIDE) zu gehen: http://unix.stackexchange.com/a/168337 (Suche nach "relatively")
** dies praktisch mal testen
* DHCPv6 Unicast Anfragen
** Kann en client per Unicast DHCPv6 Anfragen an einen DHCPv6 Server stellen? (und die Antworten per Unicast erhalten)
* Lars konfiguriert drei Test-Hosts auf ryoko (ein Debian-Server für WIDE/ISC DHCP, zwei Chaos-Calmer-Hosts)
* Kann man OpenVPN durch IPSec ersetzen?