IPv6-Adressen erneuern?

JeGr

a) Aus Webserver-/Verbindungslogs. Ich gehe einfach von einem interessierten Angreifer aus.

Da steht kein Hostname bzw. dein Provider wird wohl kaum für dein Prefix ohne Wissen von DUIDs oder spezifischen /128er Adressen für jeden Pieps einen extra Hostnamen definieren. Ich sehe also deine IP6 - sonst nichts.

b) natürlich

Genau, die gelten weiter. Irgendwie ist jeder im Kopf noch bei IP4 und NAT und wuuzaa da ist ja alles sicher (als ob NAT was mit Sicherheit zu tun hätte), aber sobald plötzlich IP6 Adressen im Spiel sind - weil zumeist von GUAs die Rede ist - ist man panisch weil das ja öffentliche Adressen sind (Panikmodus). Dass man genau dafür ja Firewall Regeln schreibt scheint irgendwie vergessen worden sein, weil man sich damit ja "dank NAT" nie auseinandergesetzt hat. Darum die Erinnerung - egal was für Adressen, die werden genauso gefiltert wie v4 jetzt auch. :)

c) Mittlerweile auch gemerkt, auch wenn mein Handy nun schon länger dieselbe hat

Sollte sich in einem gewissen Zeitraum ständig ändern, dafür ist SLAAC und die PEs zuständig.

d) Die Telekom vergibt zu jeder IP einen t-online.de-Hostnamen

IP4. Vielleicht. Aber nicht IP6. Du kannst und willst nicht 64bit Adressen einfach mal so durch-vernamen. Ist quatsch und macht keinen Sinn. Wenn wird da ein Generikum vergeben und das ist auch nicht aussagekräftiger als die ersten 64bit der Adresse (ergo dein Prefix).

e) Es tut es. Auch von außen, wenn ICMP reingelassen wird.

Tut es - weil PE - nicht. Denn bis man 2 Tage später aus dem Log eine IP6 fischt ist diese weil es allermeistens eine PE Adresse ist bereits wieder abgelaufen und nicht mehr vergeben -> Ping6 schlägt fehl. Aussagekraft von solchen Adressen tendiert gegen 0, der Prefix ist was anderes und das ist wieder recht gleichzusetzen mit ner v4 Adresse. Jedes Cookie, Canvas, Fingerprinting etc. tut mehr zur Identifikation als das.

Wie ist denn der eigentliche Wunschzustand?

Meiner wäre "Assisted" allerdings scheitert das an DHCP6-Losigkeit von Mobile Geräten. Für dich wahrscheinlich eher "Stateless DHCP" - dann sollen sich die Geräte per SLAAC IP6 vergeben und bekommen zusätlich Details (DNS, NTP) vom DHCP6. Das ist eigentlich der beste Start zum Testen weil dann keine Adressen per fixer DUID und DHCP6 vergeben werden und der dann nicht dazwischengrätscht.

tpf

Also ich bekomme zu jeder Adresse einen zur IP passenden Hostnamen. Natürlich nicht die Geräte-Hostnamen. Redeten wir da aneinander vorbei?

![Bild Text]( Bild Link)

JeGr

@tpf said in IPv6-Adressen erneuern?:

Also ich bekomme zu jeder Adresse einen zur IP passenden Hostnamen. Natürlich nicht die Geräte-Hostnamen. Redeten wir da aneinander vorbei?

Ja guuut, das ist auch nix anderes als die tumben "p37958756917.dip.blah" Adressen nur in dem Fall, dass die IP6 drin steckt. Oder lese ich das falsch? Sieht eher wie ne stupide (und nicht empfohlene) "wir-packen-IP6-in-Namen" Resolving aus. DAS bekomm ich auch mit jedem isc-dhcpd und Regex hin ;) Aber der Namen sagt eben genauso wenig aus wie ne IP6. shrug
Dein Gerät wird dadurch aber nicht mehr oder weniger identifizierbar ;)

junicast

@JeGr said in IPv6-Adressen erneuern?:

WTF? Darf ich tauschen? Ums genau zu sagen: Es kotzt mich übelst an, dass ich ein beschissenes dynamisches Prefix egal wie groß (/56) zugewiesen bekomme und nicht ordentlich mit meinen v6 Adressen/Prefixen arbeiten kann! Daher musste ich mir extra ein statisches Netz von HE.net dazu holen.

Ja, das glaub ich. Hierzu gibt es einen Feature Request im Bugtracker. Leider passiert da nicht sehr viel. Schade, AVM bekommts ja auch hin ^^

JeGr

@pmisch said in IPv6-Adressen erneuern?:

Ja, das glaub ich. Hierzu gibt es einen Feature Request im Bugtracker.

Ich verstehe aber auch warum da nicht viel passiert, denn a) muss das Upstream bei den Projekten selbst passieren, nicht eine pfSense Sonderlocke werden und b) ist das bescheuerter §(/&$"/%$(%!= weil man auf ISP Seite versucht alte und unpassende Strukturen über neue/andere Technik zu stülpen damit man den gleichen Murks der vorherigen Jahre noch beliebig lange weitermurksen kann.

Ich möchte statische IPs ohne vermurksten Dual-Stack oder IP-Light-CGN Mist. Und solange mein Flat-Tarif besteht gibt es auch keinen Grund auf Zwangstrennung, Abschaltung, Prefix-Wechsel etc. Man versucht einfach nur Geld damit rauszuschlagen. Mehr nicht. Siehe die ganzen IPv6 Topics im en-Teil des Forums. Was man da liest, wie ISPs ihre IP Vergabe vergewaltigen und mal eben auf Standards verzichten und dann dem Kunden sagen, er soll doch SEIN Gerät fixen ist an Dreistigkeit nicht zu überbieten. Und die Lösung ist dann das vermurkste ISP Gerät zu kaufen? Danke nein, erschießt mich!

junicast

@JeGr said in IPv6-Adressen erneuern?:

a) muss das Upstream bei den Projekten selbst passieren

Es gibt hier aber kein Upstream. pfpSense muss da etwas dran ändern. Es ist ja nicht pf was damit nicht zurecht käme, oder etwa doch?

@JeGr said in IPv6-Adressen erneuern?:

b) ist das bescheuerter §(/&$"/%$(%!= weil man auf ISP Seite versucht alte und unpassende Strukturen über neue/andere Technik zu stülpen

Was wird denn hier versucht zu stülpen? Ich kann die Provider schon verstehen, dass die nicht jedem Privatkunden einen statischen Präfix geben wollen. Wie soll man sonst Geschäftskundenanschlüsse vermarkten im Zeitalter von IPv6? Irgendjemand muss den Aufbau und die Pflege der Infrastruktur bezahlen. Die Privatkunden tun das mit Ihren 19,99 € Anschlüssen sicherlich nicht.

JeGr

@pmisch said in IPv6-Adressen erneuern?:

Es ist ja nicht pf was damit nicht zurecht käme, oder etwa doch?

Du weißt, was mit Upstream gemeint ist? pfSense besteht nicht aus "PF" und ein bisschen OS, sondern aus FreeBSD, den entsprechenden Userland Applikationen etc. Und in dem Fall muss das ein Zusammenspiel werden aus dem pf-FreeBSD Port, dem DHCP6, der auf dem WAN das neue Prefix bekommt und per Tracking dann an das LAN oder mehrere gibt wo Clients hängen. Dazu müssten für Firewall Regeln die Clients auch noch statische IP6 Adressen haben. Also müsste der DHCP6 ihnen Adressen auf Grund ihrer DUID bzw. des konfigurierten Client-Teils geben und soll dann vornedran dann vom RA und dem DHCP6 auf dem WAN noch ggf. ein anderes Prefix einsetzen.

Sind also mindestens zwei wenn nicht drei Komponenten / Daemon beteiligt plus das ganze noch in pfSense, UI etc. selbst zu integrieren und zu testen, damit es vorhandenes nicht zerschlägt. Und sowas baut man sicherlich nicht selbst um dann ständig den Upstream Projekten wie DHCP6 und PF hinterher zu laufen und ständig bei neuen Versionen wieder manuell patchen zu müssen. Darum arbeitet man ja u.a. bei bspw. IPSEC direkt am FreeBSD Kernel und an der Basis um Sachen gleich Upstream zu implementieren, damit sie da sind, wo alle von profitieren, und nicht wo man selbst immer und immer wieder stundenlang selbst den gleichen Kram reinpatchen muss. :)

Sorry @tpf - kleiner Rant incoming ;)

Ich kann die Provider schon verstehen, dass die nicht jedem Privatkunden einen statischen Präfix geben wollen.

Achja? Warum?

Wie soll man sonst Geschäftskundenanschlüsse vermarkten im Zeitalter von IPv6?

Tolles Argument. Wir halten deine IP4/IP6 Prefixe unter Verschluß weil wir sonst kein Geld bekommen. Cooles Modell. Komisch dass das andere Anbieter schaffen.

Irgendjemand muss den Aufbau und die Pflege der Infrastruktur bezahlen. Die Privatkunden tun das mit Ihren 19,99 € Anschlüssen sicherlich nicht.

Ja genau. Das ewig alte Kostenargument. Deshalb gibt es bei denen, die das "verbrechen" ja auch so günstige Angebote... oh wait, nein, da kostet es meist das doppelte und ich bekomme immer noch keine statische IP. Nasowas. Die günstigen Angebote kommen von Drittanbietern die nichts von der Infrastruktur bezahlen, sondern sie benutzen. Und anscheinend ist das trotzdem noch für die Netzanbieter profitabel, sonst könnten sie es ja nicht billig weiterverkaufen. Sowas aber auch.

Es ist quatsch. Firmenkunden haben ein ganz anderes Bedürfnis, nämlich SLAs und Support. Die brauchen fixe Entstörzeiten etc. Die IP ist ein nettes Gimmick aber kein Grund warum ne Firma ihren Anschluß als Geschäftskundenanschluß kauft. Firmen kaufen den Anschluß so, wenn er definitiv laufen muss und sie sich keinen langen Ausfall erlauben können. Und ansonsten ist denen ihre IP meist wurscht - gibt viele die sich Endkundenanschlüsse ranholen weil man a) höhere Datenraten überhaupt nicht bekommt (was ein Schwachsinn) und b) sie keine fixe IP(4) zwingend brauchen.
Und wenn bspw. die arme Telekom ihren Netzausbau nicht mehr bezahlen könnte weil die Preise zu billig sind würden sie den Preis erhöhen. Ob ich fixe oder dymaische IPs bekomme erzeugt in der Technik minimalen Aufwand und diesen lediglich einmalig. Hier ein "das kostet" Argument zu bringen ist Nonsense, da haben schon diverse Telekom Techniker und Insider nur müde abgewinkt.

Die Privatkunden tun das mit Ihren 19,99 € Anschlüssen sicherlich nicht.

Genau und dann will der Privatkunde einen Firmenanschluß wegen fixen Daten - und bekommt ihn nicht. Jap. Wird nicht verkauft. Oder man bekommt ihn aber er ist bei wesentlich niedrigerer Rate 3x so teuer -> ist ja logisch, weil ... äh warum genau? Nein ist es nicht. Privatanschluß bekomme ich dazu als Bestandskunde mit Dual-Stack v4/v6. Glück gehabt. Neue Privatkunden nur noch DS-light mit v6 und Murks-V4 hinter CGN. Firmen? NUR IPv4. SUPER! Warum? Nachfrage: Ja da gabs immer Probleme mit dem IP6 Zeugs.

Solang man jahrelang Bullshit erzählt und nichts technisch erneuert - sorry, kein Mitleid.

Was wird denn hier versucht zu stülpen?

Wo willst du anfangen? PPPoE war von Anfang an eine Murks-Idee, weil man alte PPP Einwahl- und Abrechnungstechnik nicht ersetzen wollte. Hätte von Angang an PPPoA oder simples IP sein können. Aber nee, dann hätte man was ändern müssen. Zwangstrennung bei Analog/ISDN hatte noch Gründe. Bei IP Anschlüssen wars von Anfang an unsinnig. Privacy wurde da immer vorgeschoben, ist aber quatsch, da man früher Logs eh für Jahre aufbewahrt hat. Und man musste keinen Telefonkanal in der Vermittlungsstelle mehr "freimachen" wie bei alten Telefonsignalen. Spätestens mit Beginn der Flatrates war der ganze Kram kompletter Quatsch. Es gab keinen technischen Grund mehr für Trennung noch für IP-Wechsel außer den Kunden davon abzuhalten seine Leitung dauerhaft zu nutzen und ggf. sogar selbst kleinere Dienste bei sich zu erreichen. War hinter den Kulissen bekannt und in diversen Memos zu lesen.

Wenn du mir jetzt Mitleid für das Geschäftsmodell machen möchtest - sorry dazu habe ich mit zu vielen Leuten aus den Firmen/Providern etc. gesprochen und gehört was da intern läuft als dass ich da nur 1g Mitleid haben könnte für die Beteiligten (egal welcher großen ISPs). Vor allem wenn ich gerade live miterleben kann wie hier im Landkreis die Telekom mit allen Mitteln den Ausbau und die Abdeckung von Breitband eines lokalen Anbieters mit eigenem Backbone massivst boykottiert und sabotiert - wo jetzt schon über Klagen nachgedacht wird. Nope, Sorry.

junicast

Ich kann Deine Aufregung gut verstehen.

Ich arbeite bei einem kleinen Provider (20 Mitarbeiter). Unser Glasfasernetz ist aber schon relativ groß und wir agieren sicherlich nicht mit Praktiken wie die Telekom Statische IPv6 werden aber auch wir Privatkunden nicht anbieten. Zwangstrennung machen wir zwar nicht, aber bringt dem Kunden auch nix, wenn erst nach 2 Monaten der Präfix wechselt.

Wenn es nach mir ginge, würde man als Kommune den Ausbau des Internets selber in die Hand nehmen und ein Ethernet-basiertes MAN mit dynamischen Routing und Glasfaser von Haus zu Haus (Maschentopologie) aufbauen. Dann kann man die IP Vergabe und andere Details selber bestimmen. Kein PPPoE. Ein vernünftiges Netz, wo man mit Gigabit+ ein Backup auf das NAS bei den Eltern in der gleichen Stadt schieben kann ohne die Daten über die angezapften IX zu schicken.
As a matter of fact arbeite ich bereits an einem Konzept, schreibe dazu einiges auf und arbeite an einer möglichen Lösung allerdings basiert die bisher eher auf Linux/OpenWrt da es dort Wireguard gibt und andere dynamische Routingalgorithmen wie babel, bmx oder batman-adv. Vielleicht hat ja sogar jemand Lust da mitzuwirken

JeGr

@pmisch said in IPv6-Adressen erneuern?:

Statische IPv6 werden aber auch wir Privatkunden nicht anbieten. Zwangstrennung machen wir zwar nicht, aber bringt dem Kunden auch nix, wenn erst nach 2 Monaten der Präfix wechselt.

Verstehe zwar den Grund nicht warum man sich selbst das Leben damit schwer macht um überhaupt Mechanismen zu bauen, die dann den Prefix/die Prefixe neu vergeben. Wofür überhaupt erst den ganzen Aufriß nur um zwischen "normal" und "corporate" zu trennen? Ist nicht umsonst so, dass RIPE vorschlägt/vorgibt: Vergebt euren Kunden ein /56 und gut ist. Warum machen es alle so unnötig schwer?

Wenn es nach mir ginge, würde man als Kommune den Ausbau des Internets selber in die Hand nehmen und ein Ethernet-basiertes MAN mit dynamischen Routing und Glasfaser von Haus zu Haus (Maschentopologie) aufbauen

Interessanter Ansatz aber warum überhaupt was neues machen, anstatt einfach an normale Glasring-Backbones anzudocken? Wozu brauche ich im kommunalen Ansatz ein Mesh? Wegen Crypto direkt im Backbone (Wireguard)? Bin ich extrem skeptisch zudem ein Haupt-Gegenargument von Wireguard u.a. immer noch ist, dass das ganze Ding komplett auf einem einzigen Crypto aufbaut und nicht wählbar wie bei OVPN/IPsec. Egal welche Implementierung auf welchem OS - wenn da was broken wäre, müsste man komplett überall alles auf neue Versionen hochziehen um das zu fixen. Einfach mal die Werte ändern wie bei anderen Lösungen geht nicht. Sowas dann noch dazu direkt ins Netz auf Backbone Level zu integrieren bin ich hochgradig skeptisch und wäre mir unangenehm, weil mir dann quasi schon direkt die maximale PPS und Ethernet Parameter gedrückt werden. Gegenüber normalen Ethernet mit MTU von 1500 und Layer 2 würde ich quasi ein Layer2,5/3 Konstrukt bekommen... da wäre mir FTTH doch lieber. Ich mache on demand gern eigene Crypto ohne Overhead.

Aber interessante Idee.

junicast

@JeGr said in IPv6-Adressen erneuern?:

Interessanter Ansatz aber warum überhaupt was neues machen, anstatt einfach an normale Glasring-Backbones anzudocken?

Weil die Provider immer das machen, was wir nicht wollen und wenn doch nur zu Konditionen, die wir nicht wollen oder können.
Warum nicht mal ein Netz aufbauen, so wie wir das gerne hätten...
Wireguard ist nur mein erster Ansatz. Was ich im Endeffekt nehme wird sich zeigen, aber derzeit gibt es wohl keine bessere / performantere Variante.

JeGr

@pmisch OK dann wäre ich (aber ggf. OT in einem anderen Thread ;)) neugierig, was die machen was ihr nicht wollt bzw. viel Geld dafür wollen und was ihr eigentlich gern hättet Weil klingt interessant. :)

aber um für @tpf den Bogen wieder zum Thema zu schlagen: ich denke nicht, dass Regeln für den v6-Adressteil da die Lösung wären, eher ein Workaround fürs Problem wenn man dynamische Prefixe hat.

Allerdings bin ich gespannt, ob seine Clients jetzt so funktionieren (normale v6+PE Adressen) wie er es wollte :)

hec

Also ich bekomme einfach ein /48 übergeben und davon ist das 1. /64 das Transportnetz. Mein Provider hat da einfach die pfSense IP als Next Hop eingetragen und gut is.

Mit dieser Lösung habe ich noch nie Probleme gehabt.

tpf

@JeGr said in IPv6-Adressen erneuern?:

Allerdings bin ich gespannt, ob seine Clients jetzt so funktionieren (normale v6+PE Adressen) wie er es wollte :)

Joar, schaut derweil net so schlecht aus. Danke der Nachfrage!

Dass das WAN seine v6 IP auf Basis seiner MAC erhählt, also keine PE, ist gewünscht, nehme ich an. Was ich interessant finde: Ohne den Haken: "Only request an IPv6 prefix, do not request an IPv6 address" habe ich dauernd Probleme. Es soll wohl also nicht so sein, dass das WAN versucht eine andere IP zu bekommen.

Korrekt?

JeGr

@tpf said in IPv6-Adressen erneuern?:

Korrekt

Das ist immer Providerabhängig, bei mir "darf" es wohl dran bzw. habe keine Probleme damit, manche wollen aber nur das Prefix weitergeben und machen das Routing über die fe80 LinkLocal Adressen, das ist dann auch nicht außergewöhnlich :)

Dass das WAN seine v6 IP auf Basis seiner MAC erhählt, also keine PE, ist gewünscht, nehme ich an

Das ist m.W. die normale/alte Implementation vom RFC dass an Hand der MAC Adresse die ID auswürfelt. Inzwischen gibts aber noch ein neueres RFC was das Generieren anders ohne MAC implementiert, das ist aber IMHO in FreeBSD noch nicht enthalten wenn ich mich recht erinnere.

Somit: Ja ist (noch) normal so, sollte sich ggf. zukünftig ändern um Rückschlüsse via MAC zu minimieren.

Gruß