Projekt IPv6 - Versionsgeschichte

Leo: /* Textuell */ Situation von dhcpy6d hat sich geändert. Dies dokumentieren.

2021-01-29T12:36:17Z

Textuell: Situation von dhcpy6d hat sich geändert. Dies dokumentieren.

← Nächstältere Version		Version vom 29. Januar 2021, 12:36 Uhr
Zeile 143:		Zeile 143:
	## isc-dhcp-server: es gibt bspw. "on commit" Trigger, wenn ein neues Prefix vergeben wird. In dieser Funktion gibt der Dienst leider nicht die IP Adresse des anfragenden Nodes mit. ( https://jpmens.net/2011/07/06/execute-a-script-when-isc-dhcp-hands-out-a-new-lease/ ) Lediglich im Syslog ist die IP zu sehen.		## isc-dhcp-server: es gibt bspw. "on commit" Trigger, wenn ein neues Prefix vergeben wird. In dieser Funktion gibt der Dienst leider nicht die IP Adresse des anfragenden Nodes mit. ( https://jpmens.net/2011/07/06/execute-a-script-when-isc-dhcp-hands-out-a-new-lease/ ) Lediglich im Syslog ist die IP zu sehen.
	## kea: hier kann man auch per Hooks auf Events reagieren, aber leider scheint auch hier nicht die IP des Nodes verfügbar zu sein.		## kea: hier kann man auch per Hooks auf Events reagieren, aber leider scheint auch hier nicht die IP des Nodes verfügbar zu sein.
	## dhcpy6d: Hier gibt es explizit eine Option, um die link-local Adresse des Nodes zu ermitteln (siehe "route_link_local" unter https://dhcpy6d.ifw-dresden.de/documentation/config/prefixes/ ). Leider lief der dhcp6yd nicht in meiner Debian10 Installation, weil es ~~Python~~ ~~Abhängigkeitsprobleme~~ gab. Es gibt ~~auch~~ ~~kein~~ ~~original~~ Debian ~~Paket~~. ~~Dieses muss per~~ ~~Hand~~ ~~gebaut~~ ~~werden~~.		## dhcpy6d: Hier gibt es explizit eine Option, um die link-local Adresse des Nodes zu ermitteln (siehe "route_link_local" unter https://dhcpy6d.ifw-dresden.de/documentation/config/prefixes/ ). Leider lief der dhcp6yd nicht in meiner Debian10 Installation damals nicht, weil es kein originales Debian10 Paket gab und bei der manuellen Installation Abhängigkeitsprobleme mit Python vorkamen. Mittlerweile (Jan 2021) gibt es wieder funktionierende Debian Pakete. Müsste man nochmals testen.
	# statische Route auf dem Server setzen '''für den ganze IP Bereich der PD Netze'''.		# statische Route auf dem Server setzen '''für den ganze IP Bereich der PD Netze'''.
	## hierfür wird ein NDP Proxy benötigt.		## hierfür wird ein NDP Proxy benötigt.

Leo: /* Graphische Darstellung */

2020-04-11T21:10:49Z

Graphische Darstellung

← Nächstältere Version		Version vom 11. April 2020, 21:10 Uhr
Zeile 154:		Zeile 154:

	=====Graphische Darstellung=====		=====Graphische Darstellung=====
	1. statische Routen auf dem Server '''für jedes neu vergebene Netz''' setzen.		1. '''statische Routen''' auf dem Server '''für jedes neu vergebene Netz''' setzen.

	+--------------------------------------------------------------------+		+--------------------------------------------------------------------+
Zeile 185:		Zeile 185:
	+-----+		+-----+

	2. statische Route auf dem Server setzen '''für den ganze IP Bereich der PD Netze'''.		2. '''statische Route''' auf dem Server setzen '''für den ganze IP Bereich der PD Netze'''.

	+--------------------------------------------------------------------+		+--------------------------------------------------------------------+
Zeile 217:		Zeile 217:


	3. dynamisches Routing. Der Node könnte sein erhaltenes Netz auch per dynamischem Routingprotokoll dem Server mitteilen. Damit entstehen automatisch die richtigen Routingeinträge auf dem Server.		3. '''dynamisches Routing'''. Der Node könnte sein erhaltenes Netz auch per dynamischem Routingprotokoll dem Server mitteilen. Damit entstehen automatisch die richtigen Routingeinträge auf dem Server.

	+--------------------------------------------------------------------+		+--------------------------------------------------------------------+

Leo: /* Möglich Lösungen */

2020-04-11T20:59:51Z

Möglich Lösungen

← Nächstältere Version		Version vom 11. April 2020, 20:59 Uhr
Zeile 139:		Zeile 139:

	====Möglich Lösungen====		====Möglich Lösungen====
			=====Textuell=====
	* statische Routen auf dem Server setzen. Auf dem DHCPv6 Server muss es einen Mechanismus geben, welcher bei der Vergabe eines Prefixes gleichzeitig einen neuen Routingeintrag erstellt. Bei unterschiedlichen DHCPv6 Server gibt es unterschiedliche Möglichkeiten Skripte/Trigger zu aktivieren. Damit ein Routingeintrag erstellt werden kann benötigen wir zwei Informationen, a) das vergebene Subnetz unb b) die IP des Nodes, an dem das Subnetz vergeben wird.
			# statische Routen auf dem Server '''für jedes neu vergebene Netz''' setzen. Auf dem DHCPv6 Server muss es einen Mechanismus geben, welcher bei der Vergabe eines Prefixes gleichzeitig einen neuen Routingeintrag erstellt. Bei unterschiedlichen DHCPv6 Server gibt es unterschiedliche Möglichkeiten Skripte/Trigger zu aktivieren. Damit ein Routingeintrag erstellt werden kann benötigen wir zwei Informationen, a) das vergebene Subnetz unb b) die IP des Nodes, an dem das Subnetz vergeben wird. Es folgt ein beispielhafter Aufbau:
	** isc-dhcp-server: es gibt bspw. "on commit" Trigger, wenn ein neues Prefix vergeben wird. In dieser Funktion gibt der Dienst leider nicht die IP Adresse des anfragenden Nodes mit. ( https://jpmens.net/2011/07/06/execute-a-script-when-isc-dhcp-hands-out-a-new-lease/ ) Lediglich im Syslog ist die IP zu sehen.
			## isc-dhcp-server: es gibt bspw. "on commit" Trigger, wenn ein neues Prefix vergeben wird. In dieser Funktion gibt der Dienst leider nicht die IP Adresse des anfragenden Nodes mit. ( https://jpmens.net/2011/07/06/execute-a-script-when-isc-dhcp-hands-out-a-new-lease/ ) Lediglich im Syslog ist die IP zu sehen.
	** kea: hier kann man auch per Hooks auf Events reagieren, aber leider scheint auch hier nicht die IP des Nodes verfügbar zu sein.
			## kea: hier kann man auch per Hooks auf Events reagieren, aber leider scheint auch hier nicht die IP des Nodes verfügbar zu sein.
	** dhcpy6d: Hier gibt es explizit eine Option, um die link-local Adresse des Nodes zu ermitteln (siehe "route_link_local" unter https://dhcpy6d.ifw-dresden.de/documentation/config/prefixes/ ). Leider lief der dhcp6yd nicht in meiner Debian10 Installation, weil es Python Abhängigkeitsprobleme gab. Es gibt auch kein original Debian Paket. Dieses muss per Hand gebaut werden.
			## dhcpy6d: Hier gibt es explizit eine Option, um die link-local Adresse des Nodes zu ermitteln (siehe "route_link_local" unter https://dhcpy6d.ifw-dresden.de/documentation/config/prefixes/ ). Leider lief der dhcp6yd nicht in meiner Debian10 Installation, weil es Python Abhängigkeitsprobleme gab. Es gibt auch kein original Debian Paket. Dieses muss per Hand gebaut werden.
			# statische Route auf dem Server setzen '''für den ganze IP Bereich der PD Netze'''.
			## hierfür wird ein NDP Proxy benötigt.
			# dynamisches Routing. Der Node könnte sein erhaltenes Netz auch per dynamischem Routingprotokoll dem Server mitteilen. Damit entstehen automatisch die richtigen Routingeinträge auf dem Server.
			## OLSRv2:
			### Nachteil: da link-state Protokoll wird im Netz überall propagiert, wer welche IPs gerade nutzt
			## RIPng:
			### Nachteil: zusätzliches Paket, http://www.makikiweb.com/ipv6/wireguard_on_openwrt.html , http://www.makikiweb.com/ipv6/ripng.html
			# was passiert, wenn Client wandert (später an anderem Server gleichen Adressbereich hat)?

			=====Graphische Darstellung=====
	* dynamisches Routing. Der Node könnte sein erhaltenes Netz auch per dynamischem Routingprotokoll dem Server mitteilen. Damit entstehen automatisch die richtigen Routingeinträge auf dem Server.
			1. statische Routen auf dem Server '''für jedes neu vergebene Netz''' setzen.
	** OLSRv2:

	*** Nachteil: da link-state Protokoll wird im Netz überall propagiert, wer welche IPs gerade nutzt
			+--------------------------------------------------------------------+
	** RIPng:
			\| gai (ISP) \|
	*** Nachteil: zusätzliches Paket, http://www.makikiweb.com/ipv6/wireguard_on_openwrt.html , http://www.makikiweb.com/ipv6/ripng.html
			\| -radvd announces 2a0a:4580:1010:0002::/64 \|
			\| -dhcpv6 announces via prefix delegation \|
			\| one /60 from within 2a0a:4580:1010:1000::/52, \|
			\| e.g. 2a0a:4580:1010:19b0::1/60 \|
			+---------+----------------------------------------------------------+
			\| tap-users-v6
			\| addr: 2a0a:4580:1010:2::1/64
			\| route: 2a0a:4580:1010:19b0::1/60 dev tap-users-v6 via fe80::bc86:3ff:fe94:6afc
			\| (route created by some hook-possibility in dhcp6 server!?!)
			\|
			\| tap-on-user-v6
			\| addr e.g. fe80::bc86:3ff:fe94:6afc/64
			\| addr e.g. 2a0a:4580:1010:2:bc86:3ff:fe94:6afc/64 (via radvd)
			\| default route via tap-on-user-v6
			\|
			+------+---------+
			\| Opennet Node \|
			+------+---------+
			\| br0
			\| radvd announces 2a0a:4580:1010:19b0::1/60
			\|
			\|
			\|
			+--+--+
			\| LAN \|
			+-----+

			2. statische Route auf dem Server setzen '''für den ganze IP Bereich der PD Netze'''.
	* was passiert, wenn Client wandert (später an anderem Server gleichen Adressbereich hat)?

			+--------------------------------------------------------------------+
			\| gai (ISP) \|
			\| -radvd announces 2a0a:4580:1010:0002::/64 \|
			\| -dhcpv6 announces via prefix delegation \|
			\| one /60 from within 2a0a:4580:1010:1000::/52, \|
			\| e.g. 2a0a:4580:1010:19b0::1/60 \|
			+---------+----------------------------------------------------------+
			\| tap-users-v6
			\| addr: 2a0a:4580:1010:2::1/64
			\| route: 2a0a:4580:1010:1000::/52 dev tap-users-v6
			\| (note: ISP assumes that network is directly connected)
			\|
			\| tap-on-user-v6
			\| addr e.g. 2a0a:4580:1010:2:bc86:3ff:fe94:6afc/64 (via radvd)
			\| default route via tap-on-user-v6
			\| ndppd answers to NDP solicitations for 2a0a:4580:1010:1000::/52,
			\|
			+------+---------+
			\| Opennet Node \|
			+------+---------+
			\| br0
			\| radvd announces 2a0a:4580:1010:19b0::1/60
			\|
			\|
			\|
			+--+--+
			\| LAN \|
			+-----+


			3. dynamisches Routing. Der Node könnte sein erhaltenes Netz auch per dynamischem Routingprotokoll dem Server mitteilen. Damit entstehen automatisch die richtigen Routingeinträge auf dem Server.

			+--------------------------------------------------------------------+
			\| gai (ISP) \|
			\| -radvd announces 2a0a:4580:1010:0002::/64 \|
			\| -dhcpv6 announces via prefix delegation \|
			\| one /60 from within 2a0a:4580:1010:1000::/52, \|
			\| e.g. 2a0a:4580:1010:19b0::1/60 \|
			+---------+----------------------------------------------------------+
			\| tap-users-v6
			\| addr: 2a0a:4580:1010:2::1/64
			\| route: 2a0a:4580:1010:19b0::1/60 dev tap-users-v6 via fe80::bc86:3ff:fe94:6afc
			\| (route created by dynamic routing protocol)
			\|
			\| tap-on-user-v6
			\| addr e.g. fe80::bc86:3ff:fe94:6afc/64
			\| addr e.g. 2a0a:4580:1010:2:bc86:3ff:fe94:6afc/64 (via radvd)
			\| default route via tap-on-user-v6
			\|
			+------+---------+
			\| Opennet Node \|
			+------+---------+
			\| br0
			\| radvd announces 2a0a:4580:1010:19b0::1/60
			\|
			\|
			\|
			+--+--+
			\| LAN \|
			+-----+

	==Bisherige Einigungen/Festlegungen==		==Bisherige Einigungen/Festlegungen==

Leo: /* Adressen/Adressbereiche */

2020-01-27T17:47:12Z

Adressen/Adressbereiche

← Nächstältere Version		Version vom 27. Januar 2020, 17:47 Uhr
Zeile 52:		Zeile 52:
	* Wie sollen Präfixe im Netz bekanntgemacht werden ('''Prefix Announcement''')?		* Wie sollen Präfixe im Netz bekanntgemacht werden ('''Prefix Announcement''')?
	** ''Idee'': das nameservice-Plugin-Äquivalent verteilt das Präfix.		** ''Idee'': das nameservice-Plugin-Äquivalent verteilt das Präfix.
	*** hnetd (Nutzung von HNCP) erfüllt einige unserer Anforderungen, schießt aber am Ende über das ~~Zil~~ hinaus.		*** hnetd (Nutzung von HNCP) erfüllt einige unserer Anforderungen, schießt aber am Ende über das Ziel hinaus.
	**** Möglich wäre hier ein Anpassung von ([https://github.com/sbyx/hnetd/ hnetd], [https://github.ecom/jech/shncpd shncpd], [https://github.com/fingon/pysyma/ pysyma]) an unsere Ansprüche.		**** Möglich wäre hier ein Anpassung von ([https://github.com/sbyx/hnetd/ hnetd], [https://github.ecom/jech/shncpd shncpd], [https://github.com/fingon/pysyma/ pysyma]) an unsere Ansprüche.
	*** Das junge BIER Protokoll (https://tools.ietf.org/html/draft-ietf-bier-architecture-07) würde unseren Ansprüchen auch genügen. Derzeit gibt es nur eine Anspassung für Babel. Prinzipiell ist das Protokoll jedoch Routingprotokollunabhängig gedacht. Einer müsste es mal so auch implementieren. Derzeit (Nov 2017) scheint es keine Implementation zu geben.		*** Das junge BIER Protokoll (https://tools.ietf.org/html/draft-ietf-bier-architecture-07) würde unseren Ansprüchen auch genügen. Derzeit gibt es nur eine Anspassung für Babel. Prinzipiell ist das Protokoll jedoch Routingprotokollunabhängig gedacht. Einer müsste es mal so auch implementieren. Derzeit (Nov 2017) scheint es keine Implementation zu geben.

Leo: /* Adressen/Adressbereiche */

2020-01-27T17:46:56Z

Adressen/Adressbereiche

← Nächstältere Version		Version vom 27. Januar 2020, 17:46 Uhr
Zeile 52:		Zeile 52:
	* Wie sollen Präfixe im Netz bekanntgemacht werden ('''Prefix Announcement''')?		* Wie sollen Präfixe im Netz bekanntgemacht werden ('''Prefix Announcement''')?
	** ''Idee'': das nameservice-Plugin-Äquivalent verteilt das Präfix.		** ''Idee'': das nameservice-Plugin-Äquivalent verteilt das Präfix.
	*** hnetd (Nutzung von HNCP) erfüllt einige unserer Anforderungen, schießt aber am Ende über das ~~Zeil~~ hinaus.		*** hnetd (Nutzung von HNCP) erfüllt einige unserer Anforderungen, schießt aber am Ende über das Zil hinaus.
	**** Möglich wäre hier ein Anpassung von ([https://github.com/sbyx/hnetd/ hnetd], [https://github.~~com~~/jech/shncpd shncpd], [https://github.com/fingon/pysyma/ pysyma]) an unsere Ansprüche.		**** Möglich wäre hier ein Anpassung von ([https://github.com/sbyx/hnetd/ hnetd], [https://github.ecom/jech/shncpd shncpd], [https://github.com/fingon/pysyma/ pysyma]) an unsere Ansprüche.
	*** Das junge BIER Protokoll (https://tools.ietf.org/html/draft-ietf-bier-architecture-07) würde unseren Ansprüchen auch genügen. Derzeit gibt es nur eine Anspassung für Babel. Prinzipiell ist das Protokoll jedoch Routingprotokollunabhängig gedacht. Einer müsste es mal so auch implementieren. Derzeit (Nov 2017) scheint es keine Implementation zu geben.		*** Das junge BIER Protokoll (https://tools.ietf.org/html/draft-ietf-bier-architecture-07) würde unseren Ansprüchen auch genügen. Derzeit gibt es nur eine Anspassung für Babel. Prinzipiell ist das Protokoll jedoch Routingprotokollunabhängig gedacht. Einer müsste es mal so auch implementieren. Derzeit (Nov 2017) scheint es keine Implementation zu geben.
	* '''Algo''' zur Ermittlung von '''IPs der APs'''?		* '''Algo''' zur Ermittlung von '''IPs der APs'''?

Leo: /* Möglich Lösungen */

2020-01-24T13:05:44Z

Möglich Lösungen

@@ Zeile 139: / Zeile 139: @@
 ====Möglich Lösungen====
 * was passiert, wenn Client wandert (später an anderem Server gleichen Adressbereich hat)?
 ==Bisherige Einigungen/Festlegungen==

Leo: /* Diskussionspunkte */ ===Möglichkeiten von DHCPv6-PD, wenn Layer2 Verbindung vorhanden===

2020-01-24T10:15:35Z

Diskussionspunkte: ===Möglichkeiten von DHCPv6-PD, wenn Layer2 Verbindung vorhanden===

@@ Zeile 106: / Zeile 106: @@
 ***** Performance von unverschlüsselten Tunneln (oder Optimierungsmöglichkeiten) ist zu prüfen.
 ***** MTU wird reduziert (zu klären!!!) (Sollte bei IPv6 aber keine negative Rolle spielen, da Behandlung für MTU Ermittlung in IPv6 besser integriert ist, als in IPv4.)
 ==Bisherige Einigungen/Festlegungen==

Leo: /* Adressen/Adressbereiche */

2020-01-05T19:44:39Z

Adressen/Adressbereiche

← Nächstältere Version		Version vom 5. Januar 2020, 19:44 Uhr
Zeile 45:		Zeile 45:
	*** DHCP Relay mit Unicast wäre hier ein mögliche Lösung		*** DHCP Relay mit Unicast wäre hier ein mögliche Lösung
	**** '''odhcp''' kann Relay, jedoch leider kein Unicast Relay (Stand Dez 2019). Es gibt hierzu ein [https://bugs.lede-project.org/index.php?do=details&task_id=406&string=odhcp&type%5B0%5D=&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto= Feature Request]		**** '''odhcp''' kann Relay, jedoch leider kein Unicast Relay (Stand Dez 2019). Es gibt hierzu ein [https://bugs.lede-project.org/index.php?do=details&task_id=406&string=odhcp&type%5B0%5D=&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto= Feature Request]
			*** Würde es immer einen Layer2-Tunnel vom Knotem zum DHCPv6 Server geben, könnte man darin DHCPv6 nutzen.
	** für DHCPv6-PD (Prefix Delegation) gelten die gleichen Einschränkungen		** für DHCPv6-PD (Prefix Delegation) gelten die gleichen Einschränkungen
	** Radvd (stateless autoconfiguration) arbeitet nur im link-local-Bereich - auch hier hätten wir also Schwierigkeiten, eine IP (oder Netze) zu ermitteln		** Radvd (stateless autoconfiguration) arbeitet nur im link-local-Bereich - auch hier hätten wir also Schwierigkeiten, eine IP (oder Netze) zu ermitteln

Leo: /* Adressen/Adressbereiche */

2020-01-05T19:40:44Z

Adressen/Adressbereiche

← Nächstältere Version		Version vom 5. Januar 2020, 19:40 Uhr
Zeile 44:		Zeile 44:
	*** DHCP-Anfragen lassen sich auf konventionellem Wege (Multicast) weder zum Server leiten, noch ist deren Antwortweg mit üblichen Mitteln definierbar		*** DHCP-Anfragen lassen sich auf konventionellem Wege (Multicast) weder zum Server leiten, noch ist deren Antwortweg mit üblichen Mitteln definierbar
	*** DHCP Relay mit Unicast wäre hier ein mögliche Lösung		*** DHCP Relay mit Unicast wäre hier ein mögliche Lösung
	**** '''odhcp''' kann Relay, jedoch leider kein Unicast Relay (Stand ~~Jan~~ ~~2017~~). Es gibt hierzu ein [https://bugs.lede-project.org/index.php?do=details&task_id=406&string=odhcp&type%5B0%5D=&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto= Feature Request]		**** '''odhcp''' kann Relay, jedoch leider kein Unicast Relay (Stand Dez 2019). Es gibt hierzu ein [https://bugs.lede-project.org/index.php?do=details&task_id=406&string=odhcp&type%5B0%5D=&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto= Feature Request]
	** für DHCPv6-PD (Prefix Delegation) gelten die gleichen Einschränkungen		** für DHCPv6-PD (Prefix Delegation) gelten die gleichen Einschränkungen
	** Radvd (stateless autoconfiguration) arbeitet nur im link-local-Bereich - auch hier hätten wir also Schwierigkeiten, eine IP (oder Netze) zu ermitteln		** Radvd (stateless autoconfiguration) arbeitet nur im link-local-Bereich - auch hier hätten wir also Schwierigkeiten, eine IP (oder Netze) zu ermitteln

Leo: /* OLSR-Version */

2020-01-05T19:38:45Z

OLSR-Version

← Nächstältere Version		Version vom 5. Januar 2020, 19:38 Uhr
Zeile 30:		Zeile 30:
	** Wie sieht eine Migrationsstrategie von v1 nach v2 aus?		** Wie sieht eine Migrationsstrategie von v1 nach v2 aus?
	*** Man kann beide parallel auf einem AP laufen lassen, aber dann müssen beide in unterschiedliche Routingtabellen schreiben		*** Man kann beide parallel auf einem AP laufen lassen, aber dann müssen beide in unterschiedliche Routingtabellen schreiben
	*** ~~Wenn~~ ~~man~~ OLSRv1/IPv4 und OLSRv2/IPv6 ~~macht,~~ gibt es keinerlei Besonderheiten zu berücksichtigen. ~~('''Dafür haben wir uns entschieden.''')~~		*** '''Entscheidung''': Wir nehmen OLSRv1 für IPv4 und OLSRv2 für IPv6. Dann gibt es keinerlei Besonderheiten zu berücksichtigen.

	Wir beginnen OLSRv2 im Opennet einzuführen. Mehr Infos sind unter [[OLSRv2]] zu finden.		Wir beginnen OLSRv2 im Opennet einzuführen. Mehr Infos sind unter [[OLSRv2]] zu finden.