[IPv6-wien] Offene Fragen zum IPv6-Papier

Mon Apr 8 00:00:33 CEST 2013

Hallo,
danke für Eure Arbeit zum Thema IPv6. Ich hatte erst jetzt Zeit das fertige Konzept zu analysieren. Dabei sind einige Fragen offen geblieben, die ich hier mal auflisten will. 
Das Konzept wirkt sehr stimmig nach innen, d.h. man kann sicherlich damit arbeiten. Allerdings will ich trotzdem ein paar vergleichende Fragen stellen, mit denen ich das Konzept neben andere Konzepte mit ähnlichen Lösungen einordnen will.

Ich hoffe das hilft uns allen, die Unterschiede der verschiedenen Ansätze zur Lösung zu verstehen.
Wer das alles nicht lesen will, der kann nach unten zu meinem persönlichen Fazit springen.

Als Analysemittel wähle ich das definierte Anforderungsprofil, hier mein Verständnis in der gleichen Auflistung (bitte um Korrektur, wenn ich es falsch verstehe)
	• Die Vergabe von IPv6 Adressen soll RFC6177 konform sein.
RFC6177 ist sehr umfangreich, ich will in der Folge (s.u.) auf einige Teilaspekte eingehen.

	• Gemäß IPv6 Design Guidelines, sollen Prefixe standortorientiert vergeben werden.
Ich verstehe das als die Grundlage von Wiener und Grazer Prefixen, allerdings nicht als die zwingende Bindung an z.B. eine Postadresse. Dies würde ja dem Konzept der Linknetze, und dem Mesh als ultimativem Linknetz widersprechen.

	• Der Einsatz von “stateless modified EUI64” Adressierung soll möglich sein.
Also Maximumprefixgröße von /64. Keine Fragen hier.

	• Der für das Mesh-Netz vergebene Adressbereich soll nach außen aggregierbar sein.
Heisst für mich, dass es durchaus wie bei v4 mehrere, aber nicht viele Prefixe sein könnten, da man ja nur vermeiden soll jedes /48 getrennt anzukündigen (am Border Gateway). Richtig?

	• Im verwendeten IPv6 Adressraum sollen die alten IPv4-Adressen mittels eines “Mapping Mechanismus” abgebildet bzw. “gemappt” werden können.
Bestehende IPv4 Adressen sollen automatisch adressiert werden. Das benötigt minimal ein /96, wenn allerdings jede IP auch noch eine "ordentliche" Prefix-Größe haben soll, durchaus bis rauf zu einem /16.

	• IPv4-Adressen sollen im Host-Teil des IPv6 Adressraums gemappt sein.
D.h. NICHT im Prefix? sollen auch nicht das Prefix sein? Dieser Punkt ist sehr schwer zu verstehen, kann man das so verstehen, dass v4 Adressen nur reservierte v6 Adressen innerhalb des Host-Teiles haben sollen? Hierzu keine weiteren Erläuterungen, sondern nur meine Frage.

	• Durch vorausschauende Wahl geeigneter Boundaries soll die Möglichkeit zur Delegation von DNS Reverse Zonen beachtet werden.
Hierbei sollen die vergebenen Prefixe also statisch delegiert werden, sonst macht ja reverse-DNS keinen Sinn.

	• Das Design soll skalierbar sein, sodass andere Communities (z.B. 0xFF Graz) sich dem Konzept anschließen können.
Skalieren nach unten oder nach oben? Keine Community in .AT ist so groß, und weltweit nur ein paar (von denen wir wissen) größer.
Hierbei stellt sich die Frage, ob der individual-Teil, das Netz des Nutzers skalieren soll, oder die Teilnehmerzahl. 65535 eindeutige Nodes sind dann sicherlich zu wenig. Warum? Siehe unten.

Hier nun die Details, warum ich entweder Dinge nicht verstehe, oder warum da noch Widersprüche sind. Dazu liefere ich hier mal ein paar Hintergründe zu meinen Fragen oben:

RFC6177 1. Abs. 1:
" This document focuses on
  the (more narrow) question of what is an appropriate IPv6 address
  assignment size for end sites.  That is, when end sites request IPv6
  address space from ISPs, what is an appropriate assignment size."

Das sagt mir zwei Dinge: Erstens hier soll die richtige Größe für eine 'End Site' definiert werden, und zweitens dass diese Regel zum Tragen kommen soll, wenn eine 'End Site' Adressraum von einem ISP (LIR?) anfordert.
Ist RFC6177 damit anwendbar? Die Adressen werden nicht angefordert, sie werden "allocated/reserviert, weil sie an die Node-ID gebunden sind", und sind Mesh Teilnehmer wirklich 'End-Sites'? Oder nicht vielleicht doch Teilnehmer in einer gemeinschaftlichen 'End-Site', dem 0xFF-Mesh?

IPv4 Mapping:
Warum einen neuen Mapping Standard erfinden? Warum für diese Zwecke nicht einfach 6to4 (Prefix: 2002::/16) verwenden? Hierbei gäbe es sofort genügend Adressen zum ausprobieren, und man kann einen eigenen Anycast-Server im Housing betreiben, muss aber nicht sein. Weiterer Vorteil es ist soweit bekannt, dass man es quasi als IPv6 in voller Autokonfiguration betrachten kann, solange man eine v4 Adresse hat. Ich verwende es sehr gerne, weil es in fast allen OS ohne extra Software funktioniert. Eine Anleitung wie das geht steht seit ein paar Jahren in unserem Wiki:
https://wiki.funkfeuer.at/wiki/Arbeitsgruppe_IPv6_im_Mesh
Das Argument der Aggregation wird hier übrigens nicht schlagend, da im Mesh nicht die Anzahl der Prefixe, sondern der tatsächlichen Announcements zählt, und nach außen ja IPv4 sowieso mit unseren Adressen angekündigt werden muss.

Reverse-Delegation:
Reversedelegation an Prefixgrenzen setzt eine 'echte' statische Vergabe von Adressen an im WHOIS (db.ripe.net) vermerkte Kontakte voraus. Eine echte statische Vergabe kann dann aber von den tatsächlichen Node-IDs abweichen, da eine statische Vergabe sich ja nicht ändert, falls bei den IDs ein Fehler passiert. Dann müsste die Redeemer-DB der Realität nachgezogen werden.

Zum Standortprinzip:
Die Node-ID ist vermutlich (alter redeemer doku -> source) eine MySQL ID die ein autoinkrement-Integer ist. Da diese IDs nur bei manuellem Löschen wiederverwendbar sind, aber trotzdem niemals wiederverwendet werden solange der Wert nicht überläuft (was er bei LongInt nicht bei 65535 tun würde) kann es gut sein, dass ein großer Teil des im Konzept vorgeschlagenen Adressraumes nicht genutzt wird, oder genutzt werden sollte, weil der Status des ID-Wertes unbekannt ist. Hier passiert keine klare Statusabklärung. Es gibt angelegte, gelöschte, verwendete, und reservierte Nodes. Nur die freien IDs, die stehen nicht in der DB, alle anderen sind einfach so, unkommentiert in der DB drin. Kein sehr zuverlässiger Identifikator. Hier wäre eine Mitgliedernummer, Teilnehmernummer, oder im anderen Extrem die MAC des Nodes ein besserer Bezug. Alle haben mehr Eindeutigkeit, und sind leichter vorherzusehen. Die Node-ID ist etwas sehr fragiles.

Ad Skalierung:
2. RFC6177 nimmt deutlich Stellung auf die Position der RIRs, in unserem Fall die RIPE NCC. Ich habe unten mal den Link eingefügt, vom letzten Update der IPv6 Vergaberichtlinie der RIPE NCC (ripe-552), im besonderen den Teil der auch auf das Thema der Anwendbarkeit von RFC6177 abzielt (und hier gleich mal zitiert):

"2.9. End Site
An End Site is defined as an End User (subscriber) who has a business or legal relationship (same or associated entities) with a service provider that involves:

	• that service provider assigning address space to the End User
	• that service provider providing transit service for the End User to other sites
	• that service provider carrying the End User's traffic
	• that service provider advertising an aggregate prefix route that contains the End User's assignment"

Ich vermute wenn bei uns alles nicht anwendbar ist, dann ist es der letzte Satz. Da Funkfeuer das Prefix 2a02:60::/32 ankündigt, ist es der service provider für das Netz. Kombiniert mit den Punkten 2.6 Assign, 2.7  Utilisation kann man davon ausgehen, das Funkfeuer zu einem gesunden Haushalten nach 2.8 HD-ratio angehalten ist. An dieser Stelle jetzt die Links zum zwischenlesen:

http://www.ripe.net/ripe/docs/ripe-552#hd_ratio
http://www.afrinic.net/index.php/en/library/policy-documents/133-policy-to-change-the-ipv6-hd-ratio-from-08-to-094-

Das bedeutet für mich, dass es viel sinnvoller wäre, den Redeemer, oder die neue Node-DB als IPv6 Selbstbedienungsladen zu betreiben, als jedem Node, auch wenn er nur einen Router als Repeater hat, gleich ein vergleichsweise großes Prefix umzuhängen. Es treibt nur die "Leervergabe" und der Benutzer hat nur den einzigen Nutzen, weniger mit der Node-DB zu interagieren. Aber Interaktion ist hier gut! Weil so kann man den Nutzer über Änderungen informieren, oder auch Adressen zurückfordern, bzw. fehlende Daten wie Adressen nachfordern. Die Node-ID darf kein Selbstbedienungsladen für abhängige IPs sein, weil man diese auch "auf Vorrat" anlegen kann, das aber dem "documented purpose" eines Assignments  widerspricht.

Weiters ist mit der reinen Anlage einer Node-ID weder ripe-552 Pkt. 3.3 "Registration" und Pkt. 3.5 Conservation beachtet.
Man kann einfach leere Nodes anlegen, und man kann auf Vorrat anlegen. Bitte kurz anlesen: Pkt. 5.5 Registration und 5.6 Reverse Lookup. 
Wer mit dem darin enthaltenden Status "AGGREGATED-BY-LIR" nichts anfangen kann, der bekommt die Kurzübersicht hier: 
http://www.ripe.net/data-tools/support/documentation/documenting-ipv6-assignments-in-the-ripe-database 

Mein persönliches Fazit:

Aus dem heraus würde ich die /40 Route auf den Tunnelserver als eine Allocation an eine lokale v6 Internet Registry sehen, und diese sollte auch dokumentiert sein, wenn die IR sich dieser Rolle bewusst ist, und diese Rolle auch wahrnimmt.
<WICHTIG>
Ich will niemandem sein Hobby hier vermiesen, aber ich glaube dass das vorgestellte Konzept auf das Dokument ripe-552 keine Rücksicht nimmt, wir aber durch unsere Mitgliedschaft bei RIPE NCC daran gebunden sind.
</WICHTIG>
Ich würde vorschlagen, z.B. mit dem 6to4 Prefix zu arbeiten, da dies "weich" in ein dezidiertes Prefix ohne Mapping, und ohne Dual Stack übergehen kann. Neben 6to4 kann auch 6rd oder eine der anderen jüngeren "transition technologies" sehr vielversprechend sein, ich verwende aus anderen Gründen NAT64, und kann den Zugriff auf einen DNS64 Server gerne bereitstellen, da ich den sowieso benötige. Die notwendige Route für NAT64 lässt sich ja leicht auf jedem Dual-Stack Host mit entsprechend Platz für die Tabellen errichten (Mesh/Housing/etc.).

Jeder kann meine Meinung widerlegen, ich bin nur eine Stimme von vielen im Verein. Ich bin keine Entscheidungsstelle. Allerdings will ich anmerken, dass durch meine Teilnahme am LIR-IPv6 Course der RIPE mir hier eine Unschärfe auffällt:
Das Konzept spricht von "Der Verein Funkfeuer Wien verfügt über den IPv6 Global Unicast Adressraum 2a02:60/32", was nur unscharf den Status als "ALLOCATED-BY-RIR" wiedergibt, weil eigentlich der LIR von Funkfeuer der Organisation Funkfeuer je nach Bedarf ein "Assignment" machen müsste. Das ist die Rolle eines LIR. 
Im Konzept wird von RFC6177 gesprochen, das ist die Grundlage des Verteilschlüssels für ISP/LIRs/IRs, aber in den Folien ist das "Preparing an IPv6 Addressing Plan Manual" angesprochen, dass sich dezidiert an Organisationen wendet, die *innerhalb* einer 'End Site' planen.

Wir als Verein müssen zwischen unserer Rolle als LIR und unserem Vereinsbedarf unterscheiden. Ich hoffe ich konnte die Gründe gut darlegen, und die wurden nicht von allen übersprungen ;) .

Beste Grüße
Matthias

-- 
Mag. Matthias Šubik
Penzinger Str. 20/2/9
1140 Wien
Mobil: +43 660 6856805

-- 
A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?