1und1-Glasfaser - IPv6 Prefix-Delegation nur /64?!

Easy, es sind die Endpunkte die die IIDs auswaehlen, die koennen einfach bnach anderen Prinzipien waehlen aks bisher und z.B. nur einen Teil der Bits verwenden. Oder denk an NPTv6, das beherzt die IID ummappt um dadurch die Berechnung neuer Checksummen zu vermeiden. Die Idee die 64bit IID sei in Stein gemeisselt teile ich nicht. So wie das tclass/TOS Bitfeld in DSCP und ECN gespalten wurde* sehe ich auch Raum fuer alternative Nutzungen fuer die 64 IID Bits, aber, da stimme ich Dir zu, eher nicht schon moergen oder uebermorgen.

*) Das waere auch ein Kandidat, tclass/tos werden 8bit ECN+**, und DSCPs wandern in die ersten oder letzen 8 bit der IID...

**) Fuer Congestioninformation ist das eine ECN Bit etwas duerftig, da gibt es Untersuchungen, dass >= 4 Bit signifikant besser waeren.

***) Nichts davon ist aktuell auch nur ansatzweise realistisch verdeutlicht aber, dass es durchaus berechtige Interessen fuer IP-Header Bits gibt.

Zitat von pufferueberlauf

Easy, es sind die Endpunkte die die IIDs auswaehlen, die koennen einfach bnach anderen Prinzipien waehlen aks bisher und z.B. nur einen Teil der Bits verwenden.

Veto:

Die Zahl der Bits, die als IID gelten soll, kann ein Host nicht für sich alleine entscheiden. Die Prefix-Länge wäre dann für diesen Host die Differenz seiner gewählten Anzahl von IID-Bits zu 128. Nun ist aber die Prefix-Länge eine netzbezogene Größe, die für alle Hosts und Router in einem LAN/VLAN gleichermaßen gelten muss, und die bei dynamischer IPv6-Adresskonfiguration (SLAAC/DHCPv6) durch die PIO-Option innerhalb von Router-Advertisements announced wird (auch im Falle von dynamischer Konfiguration per DHCPv6 - DHCPv6 kennt im Gegensatz zu DHCPv4 keine Option für die "Subnet Mask").

Man müsste also für alle Hosts und Router für dynamische Adress-Konfigurationen gleichzeitig geänderte Standards implementieren, die Prefix-Längen > 64 zulassen und zusätzlich Verfahren definieren, wie in solchen Fällen sich die Hosts ihre IID generieren - könnte schwierig werden (die zeitliche Koordination der Software-Updates betreffend - die Unmöglichkeit globaler Stichtagsumstellungen sind der größte Hemmschuh der IPv6-Migration).

Prefix-Längen > 64 lassen sich derzeit ausschließlich statisch konfigurieren, wie man das z.B. in Szenarien mit "stateless NAT64" braucht.

Nun wie ich die IID Bits auf meiner Seite zuweise ist meine Sache, da kann ich verschiedenste Dinge kodieren, wie z.B. Prioritaet oder DSCPs wenn ich will, und nur mein eigenes Netz muss darueber Bescheid wissen. Ich sage nicht, dass es leicht oder komfortabel waere, sondern nur, dass es moegklich ist, und dass ich erwarte, dass das frueher oder spaeter angezapft werden wird, eben weil diese 64 bit header mMn. aktuell weit unter Wert genutzt werden.

Es wäre ja nur eine Gegenmaßnahme, wenn der Provider nur /64 zuweist.

Da kann mir kein ISP erzählen, dass die das aus Adressmangel machen.

Wie groß sind die Netze von ISPs? /20 oder so?

Das kann nicht der Grund sein.

Die Motivation ist unklar, aber eine Motivation muss existieren, weil irgend jemand die IETF bearbeitet hat ihre Empfehlungen zu verwaessern, so, dass 1/64 keine offensichtliche RFC-Verletzung mehr ist.

Bleibt ihr in Kontakt mit 1&1 diesbezüglich? Ich maile aktuell mit einem. Die 30 Tage Testzeitraum laufen bei mir noch. Mal sehen, wie es weitergeht. Aktuell habe ich noch zuwätzlich DSL über die Telekom, welche mir ein /56 Präfix zuweist. Wäre halt wesentlich langsamer. Ich weiß auch nicht, ob das 1&1 TV über die Telekom-Leitung funktioniert, falls ich das TV-Netzwerk auf deren Präfix umhänge.

Zitat von pufferueberlauf

und dass ich erwarte, dass das frueher oder spaeter angezapft werden wird, eben weil diese 64 bit header mMn. aktuell weit unter Wert genutzt werden.

Wenn du unter "angezapft werden" verstehst, führende IID-Bits als Netzwerk-Bits zu verwenden (Prefix Length >64), würde mich interessieren, wenn du bezügliche IETF-Quellen oder auch andere (z.B. RIPE) anführen könntest, die das thematisieren. Weil, deine Erwartungen in allen Ehren, aber mich interessieren nachvollziehbare Sachargumente, die so einen Move begründen würden. Ich kann aus dem Diskussionsverlauf jedenfalls keine erkennen.

Du vermischst in deiner Argumentation auch verschiedene Sachverhalte, z.B. eine Semantik bzgl. DSCP dort hinein zu kodieren, was aber ein ganz anderes Thema ist (also nichts mit Prefix-Längen >64 zu tun, was hier doch eigentlich der Diskussionsgegenstand ist), und. m.E. dort auch so gar nichts verloren hat.

Zitat von ::1

Wenn du unter "angezapft werden" verstehst, führende IID-Bits als Netzwerk-Bits zu verwenden (Prefix Length >64), würde mich interessieren, wenn du bezügliche IETF-Quellen oder auch andere (z.B. RIPE) anführen könntest, die das thematisieren.

Klar:

IPv6 prefix lengths - how long?

Zitat von ::1

Weil, deine Erwartungen in allen Ehren, aber mich interessieren nachvollziehbare Sachargumente, die so einen Move begründen würden. Ich kann aus dem Diskussionsverlauf jedenfalls keine erkennen.

Dabei werden wir es wohl belassen muessen.

Zitat von ::1

Du vermischst in deiner Argumentation auch verschiedene Sachverhalte, z.B. eine Semantik bzgl. DSCP dort hinein zu kodieren, was aber ein ganz anderes Thema ist (also nichts mit Prefix-Längen >64 zu tun, was hier doch eigentlich der Diskussionsgegenstand ist), und. m.E. dort auch so gar nichts verloren hat.

Dein gutes Recht das so zu sehen. Und in der Tat ist dieser Teil nicht zwingend on-topic hier im Thread, daher gebe ich Dir Recht (hoffe ich) und lasse diesen Teil ruhen.

Zitat von pufferueberlauf

Dabei werden wir es wohl belassen muessen.

Das ist aber schwach. Wenn man hier Erwartungen oder Meinung äußert, sollte man sie auch valide mit Essenz unterfüttern können.

Zitat von ::1

Das ist aber schwach. Wenn man hier Erwartungen oder Meinung äußert, sollte man sie auch valide mit Essenz unterfüttern können.

Nun mal halb lang, ich habe schon Deine IETF Hausaufgaben fuer Dich gemacht. Ich achte Dich als lokalen IPv6 Experten, aber in der 6man Mailing-Liste bist Du mir noch nicht aufgefallen. Meinungen, muss man auch nicht mit validen Essenzen unterfuettern koennen, im Gegensatz zu Faktenaussagen. Und ich habe das hier versucht immer klar als Meinung/subjektive Bewertung zu foermulieren. Dein gutes Recht diese Meinung nicht zu teilen, und mein gutes Recht mir das nicht weiter zu Herzen zu nehmen.

Zitat von pufferueberlauf

Meinungen, muss man auch nicht mit validen Essenzen unterfuettern koennen, im Gegensatz zu Faktenaussagen.

Naja, was soll man denn von Meinungen halten, die nicht begründet werden? Dann habe ich doch keinen Ansatzpunkt für eine Reflexion, sei dies nun als bestätigende oder widersprechende Aussage. Aber vielleicht erwarte ich hier zu viel. Nichts für ungut.

Zitat von pufferueberlauf

Nun mal halb lang, ich habe schon Deine IETF Hausaufgaben fuer Dich gemacht.

Habe den Inhalt deiner verlinkten Quelle gelesen. Da geht es aber primär um die völlig andere Fragestellung, wie viele IPv6-Adressen ein Host aus einem gegebenen Präfix ableiten können soll. Der Autor fordert da ~1k (warum auch immer), woraus dann folgt, dass für die dafür erforderlichen 10 Bits eine Präfixlänge maximal 128-10=118 betragen darf, sofern man mal Prefix-Längen >64 zulassen wollte. Warum man letzteres aber tun sollte, geht aus der Quelle nicht hervor. Insofern ist sie keine valide Referenz zu dieser Fragestellung.

Zitat von pufferueberlauf

aber in der 6man Mailing-Liste bist Du mir noch nicht aufgefallen.

Muss man deiner Meinung nach gleich in dieser Liga spielen, um fundierte IPv6-Sachkenntnisse zu besitzen?

Leute, ihr weicht etwas vom Kern des Themas ab.

Ja, hast du recht. Sollten wir beenden. Die IETF-Position dieser Nebendiskussion ist wohl in RFC7421 nachzulesen.

Zitat von ::1

Ja, hast du recht. Sollten wir beenden. Die IETF-Position dieser Nebendiskussion ist wohl in RFC7421 nachzulesen.

Letztendlich ist man bei NAT66 rausgekommen, womit sich der Endnutzer den ganzen Quatsch schenken kann, weil NAT44 (oder NAT444 und NAT4444) es am Ende genauso tut.

Zitat von Funker

womit sich der Endnutzer den ganzen Quatsch schenken kann, weil NAT44 (oder NAT444 und NAT4444) es am Ende genauso tut.

Weiss nicht, ist das ernst gemeint oder das uebliche milde Getrolle? NAT66 (einer /64 oder kleiner also /(<64)) ist mMn. klar ueberlegen zu NAT44 mit der ueblichen /32. Warum? Weil man sich das Port-Remapping sparen kann und auf einmal Dinge wie IPSEC keine zusaetzlichen Knueppel zwischen die Beine geworfen bekommen. Der Hauptgrund fuer NAT66 ist allerdings aktuell eher Multihoming mit IPv6, fuer das /64 Problem reicht es schlicht intern auf Prefix-Delegation zu verzichten (google IPv6 Hybrid Neighbor Discovery (ND) Proxy).

Zitat von ::1

Die IETF-Position dieser Nebendiskussion ist wohl in RFC7421 nachzulesen.

Als letztes Wort, das ist orthogonal zu dem was ich schrieb, ich sagte nicht, dass es RFCs gaebe die hier relevant waeren, sondern, dass das Thema (Nutzung der IPv6 Adress-Bits, einschliesslich des Splits in Netzwerk und Interface-Teil) in der IETF immer wieder mal hoch kommt und diskutiert wird. Dafuer reicht es es allerdings nicht die publizierten Standards zu lesen, daher mein Verweis auf die 6man Mailinglist in der solche Diskussionen immer mal wieder auftauchen, mal intensiver, mal nur in Nebensaetzen.

So damit bin ich dann wirklich raus aus dem Nebenthread.

Zitat von peterfido

Bleibt ihr in Kontakt mit 1&1 diesbezüglich? Ich maile aktuell mit einem.

Ich hatte Kontakt. Aber der war nicht sehr "flexibel". Es wurde wenig Verständnis für den Bedarf an <64 gezeigt. Und die letzte Aussage war zudem sinngemäß "Da können wir nichts machen."

Ich glaube das zwar nicht so ganz. Aber wieder und wieder und ohne relevante neue Erkenntnisse ein neues Ticket zu eröffnen scheint mir wenig zielführend.
Neue Tickets zum gleichen Thema von anderen Kunden bringen uns aber vielleicht alle weiter.

Also, bleib(t) hartnäckig! So lange deines noch nicht geschlossen ist

Ich bin noch dran. Mal schauen, ob meine E-Mail von gestern beantwortet wird, bevor ich wieder Kontakt aufnehme.