https://docs.opennet-initiative.de/index.php?action=history&feed=atom&title=Benutzer%3ALars%2FBlog%3A2016_January_03_21%3A52%3A34_CET 2026-10-07T19:20:59Z Versionsgeschichte dieser Seite in Opennet MediaWiki 1.43.9 https://docs.opennet-initiative.de/index.php?title=Benutzer:Lars/Blog:2016_January_03_21:52:34_CET&diff=28117&oldid=prev 2016-01-03T20:53:21Z

<p>heute!</p> <p><b>Neue Seite</b></p><div>=== IPv6-Treffen (03.01.2016) ===<br /> <br /> ==== Opennet-IP-Bereich ====<br /> * wir möchten für die interne Adressierung der Opennet-Router eine dauerhafte IP verwenden<br /> * wir können entweder einen ULA-Adressbereich verwenden oder einen statischen providerunabhängigen IP-Bereich reservieren<br /> * wir versuchen einen provider-independant PI Adressbereich (/44) zu beantragen (https://www.ripe.net/publications/docs/ripe-589#IPv6_PI_Assignments)<br /> ** alternativ, kann man ein /44 bei freifunk.net beantragen - https://wiki.freifunk.net/IPv6:Prefixe. Vorher folgenden Satz im Detail klären: &quot;Das ermöglicht weiterhin, dass der Prefix nicht alleinig durch unser AS44194 angekündigt werden muss.&quot;<br /> ** ULA-Adressierung ist also wohl vermeidbar (falls beides für uns aus irgendwelchen Gründen nicht möglich/wünschenswert sein sollte)<br /> ** ob wir den providerunabhängigen IP-Bereich irgendwann auch öffentlich routing-fähig machen (Absprachen mit Providern usw.), ist erstmal nicht relevant<br /> <br /> ==== Adressevergabe der APs ====<br /> * DHCPv6 scheint nicht für unsere Zwecke geeignet zu sein, da wir kein Layer-2-Routing-Netz verwenden<br /> ** DHCP-Anfragen lassen sich also auf konventionellem Wege weder zum Server leiten, noch ist deren Antwortweg mit üblichen Mitteln definierbar<br /> * da die Prefix Delegation ebenfalls Teil eines DHCP-Setups wäre, ist auch diese nicht verwendbar<br /> * Radvd arbeitet nur im link-local-Bereich - auch hier hätten wir also Schwierigkeiten, eine IP (oder Netze) zu ermitteln<br /> * somit scheint es für uns keine Variante außer der statischen Festlegung aufgrund zu definierender Kriterien zu geben<br /> ** aktuell würden wir den jetzigen Zustand fortschreiben und die Adressvergabe basierend auf einer manuellen Reservierung vornehmen<br /> ** automatisierte Verfahren (Vergabe via API oder ähnlichem) lassen sich im Nachhinein umsetzen<br /> ** für den Nutzer bleibt somit freundlicherweise die Erreichbarkeit via fester IP bzw. festem Namen möglich<br /> * das Ergebnis der Adressvergabe ist der Einfachheit halber eine Ganzzahl (die AP-Nummer)<br /> <br /> ==== IP/Netze der APs ====<br /> * für die Ermittlung der IP des Routers und der IP-Bereiche der hinter ihm liegenden privaten Netze ist im Wiki eine Berechnungsvorschrift zu finden<br /> * daraus können wir auch (wie bisher) eine DNS-Zuordnung bilden (AP-Nummer -&gt; IPv6-Adresse)<br /> <br /> ==== Heimnetze ====<br /> * die /64-Netze erscheinen uns spontan als nicht (Homenet hätte wohl gern ein größeres)<br /> * /48 IP Adressbereiche bekommt man bei (nicht-Reseller) Hostern mit zusätzlicher Gebühr. Weniger kommerzielle Provider bieten /48 (oder größer) kostenlos an.<br /> ** Beispiel: Hetzner bietet /56 IPv6 Netz für 49 Euro einmalig + Flexi-Pack (12,-€/Monat) an (Stand: Oktober 2015).<br /> ** Todo: Bei Hetzner nachfragen wegen Preise für a) /44 Netz und b) PI Adressbereich routen. Weiterhin bei IN-Berlin wegen PI Adressbereich routen nachfragen.<br /> ** webtropia: /64 inbegriffen, keine Erweiterung möglich<br /> ** manitu: /64 drin, Erweiterung unklar<br /> ** ovh: /64<br /> ** contabo: /112<br /> * bei /48 verbleiben uns (bei einer angestrebten Anzahl von ca. 4000 Knoten) wohl nur /64er-Netze, wenn wir eine gewissen Unabhängigkeit von unüblichen Angeboten der Provider bewahren wollen<br /> ** prüfen, ob dies für Homenet und allgemeine heimische Anforderungen genügt</div>

Lars